On 3/21/07, Edi Weitz edi@agharta.de wrote:
On Wed, 21 Mar 2007 20:57:12 +0000, "Robert Synnott" rsynnott@gmail.com wrote:
The function which just sent back a big file was simply:
(defun speedtest () *big-string*)
where *big-string* contained the contents of a 700kb text file.
OK, I see. The culprit /is/ FLEXI-STREAMS, but there's not much to do about it in the general case. Its WRITE-SEQUENCE function gets a string and loops through it element by element calling WRITE-CHAR for each one in turn. This is necessary because a) the sequences you can output with FLEXI-STREAMS can be almost anything, even lists or vectors containing a mixture of octets and characters and b) you can't know in advance whether you'll have encoding errors further down the string.
I have a crude optimization for some special cases which I'll release one of these days, but it is just that - a crude optimization for special cases.
To solve your problem there are at least two ways, though:
To output a static file you shouldn't keep the file in memory anyway - use CREATE-STATIC-FILE-DISPATCHER-AND-HANDLER instead (or see HANDLE-STATIC-FILE).
If you insist on using a variable like above and you know its contents in advance, convert it to an array of element type FLEX:OCTET, i.e. (UNSIGNED-BYTE 8), and let the handler return this array. (This is the only "optimization" that'll always work with FLEXI-STREAMS.)
In both cases, the transfer rate should be in the ballpark of Apache handling static files. Let us know if it's not.
HTH, Edi. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
I was really just using the big static file to demonstrate the problem; it's visible when sending dynamically generated pages as well, but just not by so huge a margin (because the pages aren't as big, I think; the bigger the page, the more the speed difference between tbnl and hunchentoot seems to be). Rob