[clisp-list] TCP-based Network Server in CLISP: read-char vs. buf fering

[Hoehle, Joerg-C. <Joe...@t-...>]

Hi,

> > Using READ-CHAR-NO-HANG for i/o instead of sequence/array 
>functions is 
> > going to keep your program a _toy prototype_ with extremely poor 
>I think this conclusion is unjustified.  What do you consider to be
>extremely poor performance?  Do you have any useful data?

E.g. 3KB/sec or less instead of 300KB/sec, IIRC - see C) below

A) Reading articles on high-performance (e.g. HP-Apache) suggest the use of buffering at all levels.

B) Past experience with hard disk strongly suggest the use of buffering. The typical UNIX OS will read/write in chunks of 4 or 8 KB, which is fine. It's also my experimental lower limit below which disk i/o performance will seriously degrade.

It's not trivial to measure this at application level, since the OS will buffer disks no matter what you do there.

C) Old experience with CLISP's inspector strongly suggested buffering.
I used line-buffered output IIRC. The effect I observed without it was the following: CLISP would output one (or a few) character of HTML. The OS would then dispatch the browser, which would read these few chars, display a little bit or discover that it needs more, the OS then would switch back to CLISP. etc. etc. That was unusably slow: IIRC more than two seconds to finish displaying the output!

Moving the inspector from WRITE-CHAR to (line?) buffered output made the CLISP inspector + browser usable.

With sockets and without buffering, your application is indeed free to degrade i/o performance, unlike disk i/o.


>- How much slower is it to read one char at a time?
Orders of magnitude in my chosen examples. There were also a couple of qualitative threads on the topics of buffering and READ-CHAR vs READ-SEQUENCE in comp.lang.lisp during the last years.

>I expect you can get a large factor if you only compare something like
>cpu usage for a single read that returns, say, 1K bytes to 1K tests
Exactly.
>and reads on single bytes.  However I don't think that reflects the
>true cost of most services.
I'd say: Thank the frameworks which surround the services, not the service.

> If your
>server works well in that environment I think it deserves credit for
>that regardless of how it might fare in some other environment.

My experience is: the environment deserves credit for managing to make badly written applications/servers still perform at viable performance.

The servers ought to do buffering before throwing their stuff out. Remember one of the HP-Apache papers.

With sockets, it's IMHO the application's job to deal with buffering. Setting the TCP options "favour_throuput" or "favour_responsiveness" (name/sp?) is not enough for that.
The read() and write() the application does have a direct impact on how packets go to the fibre, and are controlled by the application, while MTU etc. are global values.

Regards,
	Jorg Hohle.