[hunchentoot-devel] tbnl-worker threads

[Edi Weitz]

On Thu, 07 Dec 2006 14:25:03 +0530, quasi <quasilists at gmail.com> wrote:

> We are using Apache+mod_lisp2+TBNL for our website.  The load has
> sorta spiked of late, we serve approx 4-5 concurrent pages (which
> are heavy, computationally and in size).  We are using Allegro CL.
>
> The thing observed is that there are about 70-100 tbnl-worker
> threads which I dont think are doing anything much.  There is a
> limit of 230 threads on the Allegro CL and this 100 threads becomes
> worrysome. I think they have a timeout and the die eventually, but I
> wonder at their existance and if they could be made to die an early
> death (I could give them some cig's but ...). :)

In Hunchentoot, you should be able to use the READ-TIMEOUT parameter
of START-SERVER to control how long worker threads are supposed to
live if they're idle.  In TBNL, things are a bit muddled due to the
usage of KMRCL - you have to find out yourself depending on your
implementation.

> BTW is it good time to move from TBNL -> Hunchentoot ?  Because it's
> a live system and 'if it aint broke dont fix it' comes to me mind.

If you have a live system that's working fine with TBNL, then don't
switch.  I think in that case it's better to be safe than sorry... :)

But note that there won't be any improvements or bugfixes for TBNL in
the future.

> Any ideas about the performance etc. ?  I did some initial
> benchmarks and seems to be a tad slower than apache+mod_lisp2+TBNL
> ... but the benchmarks were not serious. I will do them again.

ATM, Hunchentoot is definitely slower than TBNL, see recent postings
(last month?) to this list.  I have patched FLEXI-STREAMS to improve
Hunchentoot performance, but I haven't yet found the time to test and
commit these changes.

I doubt that the performance differences really matter for you with
five concurrent pages, though.

Cheers,
Edi.