Why wouldn't this be particularly slow? You're running a potentially inefficient web server with a proxy webserver in front of it. Doing this with Python's built in webserver (as seen in Django and such) with Apache proxying is very inefficient and performs poorly compared to Apache with mod_python or cgi. Even replacing Apache with something LigHTTPd only marginally makes things faster, since the bottleneck is Python's webserver.
I don't understand why this wouldn't also occur with Hutchentoot. I would think a CGI interface, or a mod_lisp written much like mod_python or mod_php, would be significantly faster.
I'm not sure about performance but I did try Hunchentoot with mod_lisp2 and apache and I encountered a number of strange errors (I'm guessing this is because of mod_lisp2's quality) so much so I had to use Hunchentoot's built-in server which gave me no problems at all.
On Hunchentoot's page the author does talk about performance issues (for dynamic not static content) if you care to look. So you're probably right but it's better to get your system running first and deal with performance second.
However, as I guess apache is faster than most of the homebrew lisp servers (although this is pure conjecture) I would like to see a more stable mod_lisp.
Older versions of hunchentoot (named TBNL) used mod_lisp and mod_lisp2 to communicate requests to the Lisp side in a simplified form (similar to FastCGI). Since Hunchentoot can speak HTTP directly now, mod_proxy is effectively the same as mod_lisp for hunchentoot's purposes. mod_lisp is not an embedded interpreter in Apache.
Zero fuss way to get started with Common Lisp on Mac OS X. Aquamacs bundled with SBCL, launches immediately into REPL at startup. I will recommend this to anyone who wants to learn Lisp on the Mac.
I don't understand why this wouldn't also occur with Hutchentoot. I would think a CGI interface, or a mod_lisp written much like mod_python or mod_php, would be significantly faster.
So, all that said, is Hutchentoot a bottleneck?