Jim Wilcoxson wrote:
IMO it is not scalable to use connection servicing threads to spool
output when the size of the output exceeds the socket buffer capacity.
Doing I/O with non-blocking, event-driven threads also helps prevent
DOS attacks. The trade-off is in memory usage: when a connection
service thread does an ns_return, and the output exceeds the socket
buffer size, you need to hang onto the buffer in memory somewhere
while it is spooled by the HTTP I/O driver. The advantage is that the
connection service thread can be off handling another request, but
there is also a new resource to manage: spooled output buffers.
For returning files, you can always work the way [fcopy] does - leave
the fp open and when the socket is writable, read some more and send it.
This wouldn't be too resource consuming. I've never seen too many HTML
files above 100K (20s on a 57k6 modem anyone? :), usually the largest
ones are static files. On average, my dynamic HTML code is usually
20-30K at most.
The problem could be with people storing files as BLOBs, but then again
they have to be read into memory and sent back to the client now as
well... So this doesn't change much.
--
WK
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of
your email blank.
