[Bese-devel] single-threaded

[Henrik Hjelte]

Tagging something as controversial is a good way to get immediate feedback :-)

First, big congratulations to Attila and friends to the success with
your company, it was great to see the posting on comp.lang.lisp !

About the list of recent patches, I see that you are dropping the
single-threaded httpd backend.

First reflection, don't ucw need a backend that works with all lisps,
not only sbcl?
Or are all lisps are threaded nowadays..

Second, we like to have a single-threaded version around for safety reasons.
If you are suspicious of errors connected to threading, it is good to
have a simple implementation around as a fallback option.

Also, we have a setup that makes it possible to use a single threaded
version in a production environment. It currently looks like this:

One server only, at http://stix.to, dual core. We are poor right now
but we hope it can grow.

First, a nginx on port 80 that can proxy requests to either a test
environment or production.

Then another nginx process that serves static files, offloading ucw.
But the most important thing is that it adds gzip compression on the
fly to all requests (except graphics). That really improves the client
performance a lot! You can do this with apache as well of course. This
nginx process sends ucw requests further to
a real proxy server: the haProxy.

Nginx can't handle sticky sessions, but the haProxy can, we use cookie
based sticky sessions. Then we have four instances of ucw running.
They are currently running a multithreaded version of ucw, but we
don't think it should be necessary.

To further complicate the setup, also we have json-rpc servers that
are stateless but running in ucw, so we have a stateless proxy in
front of two instances of these as well.

Using this setup, we think we can utilize the two cores on the server
almost as good or good enough with a single threaded ucw. The queing
of requests will be handled by the haProxy, so we don't need multiple
threads for that purpose. And since there is a lock on most things in
ucw, at most times there will be one thread running the application
code anyway.

Since we had some troubles, possibly related to threading, I just
tried to revive the single threaded httpd backend. I did some simple
performance tests using the ab program for some json-rpc requests,
throught the proxy. And it seemed like the single threaded httpd
backend had a higher throughput than the multithreaded httpd backend.
I wouldn't want to say that this is a perfectly done performance test,
but there are some theoretical reasons a single-threaded version may
perform better: more threads means more context switches and CPU cache
pollution.

So, is it ok if I revive the single-threaded httpd, or make a
single-threaded iolib based backend? Or do you have any plans that
conflict with this?

Is anyone interested in example files for configuring haProxy, nginx,
apache and pound? I have been through them all by now. I can't say
firmly which one is best, but I see it like this:

apache. Well tested, lots of features.

nginx. "They say" it is faster than apache.

pound. Ok proxy with sticky sessions. Easy to set up.

haProxy. Seems very trustworthy and stable from reading the docs.
Configurable, easier to set up than expected. Better logging than
pound. "They say" it has the best performance. Has sticky sessions
through cookies.

/Henrik Hjelte