[Openmcl-devel] http servers and threads under heavy load; was: Good Video
danielp at sonic.net
Sat Oct 17 16:45:22 EDT 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
first name at last name dot com
More information about the Openmcl-devel