Hi there. I have just started with Hunchentoot. Being also a lisp newcomer i started out with reading tutorials and docs and this one mailing list, where I found some upload problems mentioned and getting interested in testing them out. After installation of hunchentoot (as a standalone server) on sbcl and trying to upload some files I got almost 100% cpu load on the host machine with just one file being uploaded. Then I tested it, hacking the rfc2388 module to only read from stream without processing or writing anything. I got a 50%+ cpu cload. The upload on apache/php is getting 5%. I saw that the lisp is equally heating the cpu just with stream reading-writing by making a separate file read-write test. It's an sbcl stream problem as i see it, nothing can be done here, I guess. It's acceptable for apache being held on this system, but i don't really want to run php alongside with lisp just for file uploads. So, do you think it would be possible to write some foreign module for just the multipart form-data processing and use it with Hunchentoot? Any way to make upload performance reasonable?
On Fri, Mar 25, 2011 at 10:11 AM, valgusk lalala valgusk@inbox.lv wrote:
So, do you think it would be possible to write some foreign module for just the multipart form-data processing and use it with Hunchentoot? Any way to make upload performance reasonable?
First of all, we always meant to rewrite the RFC 2388 module anyway, but we haven't found the time for it so far, and obviously this stuff wasn't important enough that someone threatened to pay for it... :)
If someone finds a way to make file uploads significantly more efficient in a portable way, I'm all for it and would happily accept patches adhering to the usual rules. However, I'm not interested in solutions based on foreign code. The idea of Hunchentoot is to have a stand-alone Lisp solution and if I had infinite time I'd even rewrite the SSL layer in CL... :)
BTW, as you're saying that it's an SBCL problem, have you tried with other Lisps? If this is a real problem for you, alternative solutions might be to switch to another Lisp (if that helps) or to improve SBCL's stream code (if that's the culprit).
Cheers, Edi.