client-server

[Derek Atkins]

<linas@linas.org> writes:

> 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...)

I'm not worried about server load.  I'm worrying about transaction
setup latency.  How long does it take to setup a transaction, make the
request, and get the response?  This has very little to do with the
load on the server (although a loaded server will slow it down as
well).  But it does have a lot to do with general overhead.

For example, it took me about 3 seconds to load www.gnucash.org.  And
I'm sitting behind a fairly empty T-1.  If gnucash supported SSL, you
would see that it was much slower.

> 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.

Yes, but it's unclear how easily that would fit into a CGI model.

> > 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.

Again, it's not a question of server load or #pages/sec; it's a
question of setup latency.  How long does it take to setup the
connection?

> 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.

LOL.  I don't like it either; I was just point it out ;)

> > 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. 

But what about cache coherency issues?  How do you do a callback via
HTTP when data changes?  Or are you expecting the client will poll the
server for coherency every time it wants to use a piece of data?

> 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.

This is a red herring.  How fast it would be is something that can
only be measured after you're doing it.  It's very hard to model this.
It also depends on the congestion on the LAN, the load on the server,
the load on the client, how much data is being sent, etc.

Also, you're making guesses about what approach will be faster without
any proof.  Having done tests in the past, sending fewer bytes of data
over an existing TCP connection is faster than sending more bytes of
data over a new TCP connection :)  Maybe that's not what we're doing
here.  

I should also point out that the Applications Area Directors of the
Internet Engineering Task Force believe that no new protocols should
be built on top of HTTP.  They're the ones that are in charge of
protocol standardization, so they know they're stuff.  Ask yourself
why you think they don't want protocols based on HTTP?

> --linas

-derek

> Oh, and Merry Christmas!!

And Happy Channukah (and a wonderful New Year ;)

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available