[Openmcl-devel] http servers and threads under heavy load; was: Good Video

Daniel Pezely danielp at sonic.net
Sat Oct 17 13:45:22 PDT 2009


On Oct 16, 2009, at 11:28 PM, Hans Hübner wrote:

> On Sat, Oct 17, 2009 at 04:57, Steve Núñez <steve.nunez at illation.com.sg 
> > wrote:
>> Weinreb refers to 'the two http servers' implementation when he  
>> talks about
>> LAIR (I can't remember what it stands for). Does anyone know which  
>> two he's
>> referring to?
>
> He is referring to Araneida and Hunchentoot.

> ... but I would in general try to avoid threading in environments  
> that require high levels of reliability.


About six months ago on the SBCL dev list, there was a fair amount of  
discussion regarding pre-1.0 Hunchentoot under extremely heavy load of  
an Ad network.  Gory details of threading issues  on various CL  
implementations are there.

Where I work now, we currently have moderate sustained traffic with an  
even older release of Hunchentoot on LispWorks without issue.

Be sure to also examine 'antiweb' which in future will be my first  
pick as a single replacement for both Hunchentoot and Nginx.  http://hoytech.com/antiweb/



I agree with Hans: when possible, eliminate threads under heavy,  
sustained loads.  You can accomplish a lot within a single thread  
using only message queues/lists and by breaking-up your tasks into  
discrete pipeline steps.

Sometimes, however, OS-native threads are required for your particular  
needs.  In those cases, try lock-free, spin-free message lists within  
the pipeline.  It's no magic bullet, of course...  You'll want atomic- 
push and -pop operations (and ideally, atomic-rotatef-1), which in  
SBCL can be built upon #'sb-ext:compare-and-swap function.  Since CCL  
internally has #'ccl::atomic-incf and -decf, I'm sure that the other  
functions will follow soon or already exist by some other name.  I  
couldn't find any with a quick check of latest source in svn; anyone  
know?

-Daniel
--
first name at last name dot com









More information about the Openmcl-devel mailing list