[Lispweb] x86 cmucl & web
craig at red-bean.com
Thu Mar 14 23:05:33 CST 2002
Andrew Wolven <awolven at redfernlane.org> writes:
> Hi everyone,
> I was wondering how well the multithreading performs on x86 cmucl for
> application servers like imho and portable allegroserve. Is it good
> enough to use for a production web server? Certainly imho is used in
> production somewhere, but does it use the multithreading or does it
> spawn a new cmucl instance? (it meaning the frontend server)
It is "multi-processing" meaning cooperative threads. I am not
intimate with the details of it's multi-processing sufficient to
summarize what a search of cmucl-help and cmucl-imp will reveal.
CMUCL on x86 boxes running Debian or RH Linux is our production
platform and devel platform for IMHO. These typically have a series
of workstations running against them across a campus network, ranging
in number from 1 to 10 simultaneously at peak usage. The choke point
has consistently been the browsers and JVM implementations on the
clients (since there are significant interface elements in Java that
communicate with the CL backend via IMHO). There are times when large
return sets or costly queries can cause a lag in the application.
Our strategy has been to optimize it for serial request handling,
since for the most part it ends up being serialized. It has scaled
for us so far. IMHO creates a new process (not a unix proces mind
you) for each request so there is no need to add MP support into your
So far our real bottlenecks have been CPU and DB as opposed to IO
blocking or other issues that MP would really help with. Data storage
and querying are our key problems with scaling the application built
on top of IMHO. And those problems mostly have to do with maintaining
sufficiently dynamic storage models that perform across a wide range
of access types, that's the type of stuff the perculates into USQL
(the metadata subsystem and schema versioning for instance).
Really our concentration on IMHO has not been performance increases,
and when it has they came in places seldom discussed, not in better MP
support or clever process models like you read about in "web
programming" magazines. It comes from stuff like avoiding format when
it's not needed and reducing heavy consing and string tomfoolery. The
bulk of IMHO work we are doing is in abstraction building for putting
together the UI.
I say all of this not too change the topic, but to point out that in
my experience CMUCL on x86 is a good platform and that
multi-processing performance is not an issue.
We do run into some issues in development that rarely touch our
production servers, and that is the interaction of the FFI and the MP
subsystems in combination not behaving well in all situations when
interrupted. I have not had a chance to investigate closely but when
I have had the Oracle USQL driver loaded and I send a interrupt to the
process thru ILISP it will thro a floating point exception and
depending on the error it will continue or drop dead. I beleive this
has been discussed on cmucl-imp/help, which is prolly your best
reosurce for this topic. I am not aware of this happening in one of
our production instances without being triggered by a developer
getting jiggy with it.
A toast to the CMUCL haxors. <clink clink>
Craig Brozefsky <craig at red-bean.com>
Ask me about Common Lisp Enterprise Eggplants at Red Bean!
More information about the lispweb