that once you cross it, the characteristics of the problem set changes
and the optimal (and sometimes only) solutions become very
specialized.
It's at this end of the spectrum where AOLserver truly shines, but
it's
a very small set.
In general, my experience is that the simplest tool for the job is
likely the most scalable, if for no other reason that it's easy to
swap out well-understood low-functionality components. AOLServer's
easy escalation from Tcl to C for web pages makes for fast initial
development, and a straightforward development path to very high
performance. My full text index for tile.net (which I sold to
internet.com back in 1999) was STL-based C++ wrapped in an AOLServer
module, and a memmap-based read-only dbm file sitting mostly in
memory. The sort of architecture just isn't possible in most web
servers. And, I was able to develop the whole thing in Tcl
initially, with less performance critical parts (such as the indexing
engine) left in Tcl.
AOLServer's internal model is very simple, basically being a C Engine
-> C modules -> Embedded Tcl interpreter, with none of the fancy
"process watcher" and "shared memory" stuff that Apache has.
John, it's fantastic to see you're actively looking at and working
with
AOLserver.
I used to actively use it in the closed-source days of AOLServer.
From the list archives, it looks like your first message
came through around 15 Apr 2006. I'm hoping that your interest in
AOLserver might mean that the upcoming version of Lyris may replace
tclhttpd with AOLserver?
Sadly, Lyris definitely not being moving to AOLServer, as I sold
Lyris a year ago and no longer run the software development dept. The
Lyris web interface is all based on tclhttpd. It'd probably just be a
week's worth of work to port everything from tclhttpd to aolserver,
but they'd need to learn a lot about AOLserver, and list server
performance isn't really the hot-button it was in the dot-com era.
Way back when Lyris was moving from a mod_perl interface to a tcl-
backed one, I wanted to use AOLServer, but the closed-source license
was unclear about bundling in a for profit product, and then when
things went open source windows server support was not available, so
we couldn't use it then.
An odd side-note: in my benchmarking of "hello world", tclhttpd gave
terrible results vs AOLServer, but a simple all-tcl web server gave
amazing results, almost 2x what AOLServer gave:
"Hello world" dynamic page on a slow mac-mini:
lighttpd-cgi: 15/second
tclhttpd: 32/s
aolserver: between 640/s and 750/s
trivial all-tcl-web-server http://wiki.tcl.tk/15244 : 1162/s
Or are you working with AOLserver for
something different (i.e., Magnatune)?
Magnatune is sadly, all mostly PHP, with back-end Tcl code. I have a
new project (www.bookmooch.com) -- a community for used book
exchange, which is all AOLServer.
And once that launches (in a week or two), I plan on making the
german/french versions of the Magnatune web site in AOLServer.
One of the reasons I want to use Berkeley DB is that I'd like every
web page string to be a BDB database lookup, allowing wiki-style
correcting of strings on a web page (ie, anyone can correct, on the
spot, any translated text on any page). SQL just wouldn't work with
that design, with a dozen or so db lookups per page.
-john
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
