[hunchentoot-devel] hunchentoot file upload performance

Mac Chan emailmac at gmail.com
Thu Nov 16 03:04:10 UTC 2006


On 11/15/06, Edi Weitz <edi at agharta.de> wrote:
> Actually, the more I think about it the more I'm sure that
> FLEXI-STREAMS is the culprit.  I also have an idea how to make it
> faster, but I'm not sure if I'll find the time to do it in the next
> days.

No hurry, Edi. As long as we know there's a solution I'm at ease :-)

> > Again, my guess is that rfc2388 repeatedly call read-char instead of
> > grabbing a buffer with read-sequence and decode it as a chunk.
>
> Because of the way the streams are layered now, you probably wouldn't
> win much (if anything at all) if you used READ-SEQUENCE instead.

So I just did some profiling earlier using the tip from

http://thread.gmane.org/gmane.lisp.lispworks.general/5563/focus=5573

and found that most time are spent in tons of calls to read-char.

I then tried something like reading the whole buffer into a string and
use the (parse-mime string) method instead of (parse-mime stream)
(this is not a fix because if you upload 100mb file, it will allocate
a 100mb buffer).

The result is worse... will investigate later. Also I plan do similar
test with allegro-serve and see if it uses 100% cpu performing the
same task.



More information about the Tbnl-devel mailing list