Hi all,
I've been using tbnl behind mod_lisp2 for quite a while.
After Edi merged tbnl with hunchentoot I wanted to get rid of apache and run hunchentoot in standalone mode for easier deployment (not to mention the coolness factor of running everything in lisp).
However, I've found that the file upload performance of hunchentoot is 4-10 times slower than tbnl (standalone or behind mod_lisp). I tested this by uploading a 30mb file in the test upload page.
I'm guessing that Chunga might be the reason, since this is the only new component introduced.
[ Chunga is currently not optimized towards performance - it is rather intended to be easy to use and (if possible) to behave correctly.]
On a side note, while the file is being uploaded the cpu will go up to 90-100% (This happens to both tbnl and hunchentoot).
This is not the case when I upload the same file to a php script w/ apache.
Again, my guess is that rfc2388 repeatedly call read-char instead of grabbing a buffer with read-sequence and decode it as a chunk.
These two issues make migrating to hunchentoot particular painful because if one of the users uploads a huge file the whole site will become very unresponsive (in tbnl the cpu spike goes away a lot faster, but improving the i/o routine is still a big win).
I don't want to blindly guess, but I don't know how to use lispworks' profiler to profile a multi-threaded server app.
The lispworks profiler requires you to run (profile <forms>) and it will return the profiling data after running the <form>.
Is there a way to profile hunchentoot without writing individual test case that simulates uploading a 30 mb file?
What about people using sbcl? How do you go about profiling apps like hunchentoot?
Thanks.