It's been rumoured that Derek Atkins said:
>
> This is an interesting approach, but HTTP is _SLOW_. You have to
ahh, what are you envisioning? a thousand hits a second?
www.linas.org serves up 20K pages a day, and serves up
cvs.gnucash.org, and its a 7 year old 486 whose load average
stays under 0.1 (and uptime would be years, if our power company
were reliable...)
> setup and teardown a TCP connection for each request, and you have to
http/1.1 uses sopcket keepalive aka persistant connections by
default. netscape 3.0 and i.e. 2.0 and newer ask for keepalive by
default.
> build an SSL association for each request.
ssl *is* slow. But a pentium-166 can still push out several hundred
ssl encrypted web pages a second, I beleive.
> only that, but forking off a CGI is also very expensive.
again, on an old pentium, you can fork off thousands of cgi-bins a
second. This stuff starts to matter only when you start hosting
at exodus communications.
> Having all of the network connection setup cached through a whole
> session (rather than per request) will save a lot of time, but I don't
Socket keepalive is inside of apache (in fact, any modern webserver).
There are also SSL sessions, which are used to avoid public-key
renegotiations. I beleive SSLv3 sessions last an twenty minutes
by default, and after that, a secret-key renegotiation is forced
(to avoid snooping & replay attacks). The timeout is configurable.
I've never used apache's mod_ssl, but I would guess all the config
paramters for ssl sessions timeouts are there.
> build Java Servlets to solve the cgi forking problem, but then we'd
Hah!
If you think cgi-bins are slow, then you've never used java servlets.
Servlets are about an order of magnitude slower than cgi-bins, and it
pretty much goes downhill from there. Java and perl have similar
performance, and as often as not, perl is faster. Remeber. perl has
JIT bytecode too.
Never mind that Java can't deal with 24x7 environments. Having
personal scars from debugging jvm mem leaks crashes & hangs in a
netscape enterprise & websphere environment, I conclude Java is for
chumps.
> I think this is a wonderful approach for report generation, but I'm
> not convinced it's the best approach for day-to-day data entry.
No, but that's the whole point: because most of the data is cached
locally in the gnucash client, responsiveness is excellent.
Furthermore, if you are running your gnucash server/cgi-bins on
a local, ether-net connected web server, the perceived
responsiveness (as perceived by user) should be around a tenth of
a second, about the same as it would be for a raw socket, corba,
or sql or other client-server desing. The most likely slowest
part of the system will be the display and graphical layout on
the client side.
--linas
Oh, and Merry Christmas!!
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
