Hi!
I usually earn my money by programming database-backed web
applications in Perl, C or (even worse) PHP as a free-lancer. But in
my spare time, I've re-animated my university knowledge of Lisp, and
I'm now playing with different CL implementations, reading the books
of Graham and Norvig and others, writing small applications for fun -
you get the idea.
As a result of these studies, I'm asking myself if there could be a
connection between the fun that I have with Lisp and my daily work. I
wonder what people are using CL-based web servers like CL-HTTP or
AllegroServe for and if there could be a situation where I could
convince one of my customers to use CL-HTTP instead of, say, Apache
and mod_perl. To be more specific:
1. I understand that an application like CL-HTTP makes sense if you
need a web frontend to an already existing CL application. But does
anybody here actually use CL-HTTP or AllegroServe for plain standard
Websites (where the rest of the world would use Apache, IIS, or
Netscape)?
2. Are there significant differences between CL-HTTP and AllegroServe?
Or: Why did Franz, Inc. write AllegroServe when CL-HTTP already
existed?
3. What about the performance (where I mean things like speed, size of
the executables, robustness, etc.) of the CL-based servers compared to
the usual suspects? If someone has some real-word experiences he or
she would like to share, please do so.
4. Or what about stuff like mod_lisp? Wouldn't it make sense to leave
the tedious work of serving the pages and handling the connections to
a proven work-horse like Apache?
(OK, maybe that wasn't very specific. Nevertheless, I'd love to read
some replies from the comp.lang.lisp community to clarify my cloudy
vision of Lisp-based web-serving.)
Thanks in advance for your time and your answers. Any input is
appreciated.
Edi Weitz
--
Dr. Edmund Weitz
Hamburg
Germany
Hi,
AllegroServe is pretty cool. I had it working, and felt in command of
it in no time (hour or two total). That was months ago, though, and I
havn't kept up with it. On the other hand, I found the code in
CL-HTTP to be nightmarish, and will stay away from it as long as it is
humanly possible.
I believe that AllegroServe is open-source in a way that makes it
available for people to use, modify, etc. for commercial applications.
AllegroServe has been ported, for sure, to CormanLisp (from Chris
Double). You might read about it at:
http://www.double.co.nz/cl/
I don't think it would be too hard to get it working on another
implementation, e.g. LispWorks or CMUCL, if it hasn't been done
already.
dave
···@agharta.de (Dr. Edmund Weitz) writes:
> 1. I understand that an application like CL-HTTP makes sense if you
> need a web frontend to an already existing CL application. But does
> anybody here actually use CL-HTTP or AllegroServe for plain standard
> Websites (where the rest of the world would use Apache, IIS, or
> Netscape)?
If you have an application that can be implemented by a few lines of
perl, tcl, or VB talking to an oracle, sybase, or ms sql database,
then Apache, IIS, or Netscape seem to do the trick.
We explicitly *don't* use Apache, IIS, or Netscape for our web
interface because they *don't* easily interface to CL. Our CL
application isn't quite `already existing', but the decision to not
use a `standard' webserver was made very early on because a standard
web server would be far too limiting.
> 2. Are there significant differences between CL-HTTP and AllegroServe?
> Or: Why did Franz, Inc. write AllegroServe when CL-HTTP already
> existed?
The licensing of CL-HTTP for commercial use is quite murky.
> 3. What about the performance (where I mean things like speed, size of
> the executables, robustness, etc.) of the CL-based servers compared to
> the usual suspects? If someone has some real-word experiences he or
> she would like to share, please do so.
Apache and IIS perform very poorly as a lisp interpreter. In fact,
they don't produce output at all.
> 4. Or what about stuff like mod_lisp? Wouldn't it make sense to leave
> the tedious work of serving the pages and handling the connections to
> a proven work-horse like Apache?
It depends on the application. If you have nothing static to serve,
and if Apache is simply forwarding requests to lisp and returning
results to the client, then your Apache server is doing nothing more
than acting as a bloated proxy.
On the other hand, if you are primarily serving up static html from a
unix file system, or trying to run perl scripts to generate html, then
the functionality of CL-HTTP seems wasted.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Joe Marshall wrote:
> ···@agharta.de (Dr. Edmund Weitz) writes:
>
> > 1. I understand that an application like CL-HTTP makes sense if you
> > need a web frontend to an already existing CL application. But does
> > anybody here actually use CL-HTTP or AllegroServe for plain standard
> > Websites (where the rest of the world would use Apache, IIS, or
> > Netscape)?
>
> If you have an application that can be implemented by a few lines of
> perl, tcl, or VB talking to an oracle, sybase, or ms sql database,
> then Apache, IIS, or Netscape seem to do the trick.
>
> We explicitly *don't* use Apache, IIS, or Netscape for our web
> interface because they *don't* easily interface to CL. Our CL
> application isn't quite `already existing', but the decision to not
> use a `standard' webserver was made very early on because a standard
> web server would be far too limiting.
>
> > 2. Are there significant differences between CL-HTTP and AllegroServe?
> > Or: Why did Franz, Inc. write AllegroServe when CL-HTTP already
> > existed?
>
> The licensing of CL-HTTP for commercial use is quite murky.
I seem to remember JCMA speaking in support of CMUCL. I can't recall
exactly what he said, but it sounded something along the lines of _worth_
_your_ _time_.
I am sure he would write up a less vague license, but he's probably thinking
more about that symbolics.com thing.
>
>
> > 3. What about the performance (where I mean things like speed, size of
> > the executables, robustness, etc.) of the CL-based servers compared to
> > the usual suspects? If someone has some real-word experiences he or
> > she would like to share, please do so.
>
> Apache and IIS perform very poorly as a lisp interpreter. In fact,
> they don't produce output at all.
>
> > 4. Or what about stuff like mod_lisp? Wouldn't it make sense to leave
> > the tedious work of serving the pages and handling the connections to
> > a proven work-horse like Apache?
>
> It depends on the application. If you have nothing static to serve,
> and if Apache is simply forwarding requests to lisp and returning
> results to the client, then your Apache server is doing nothing more
> than acting as a bloated proxy.
>
> On the other hand, if you are primarily serving up static html from a
> unix file system, or trying to run perl scripts to generate html, then
> the functionality of CL-HTTP seems wasted.
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
On Fri, 23 Feb 2001 09:48:49 GMT, ···@agharta.de (Dr. Edmund Weitz) wrote:
> I usually earn my money by programming database-backed web
> applications in Perl, C or (even worse) PHP as a free-lancer. But in
[...]
> As a result of these studies, I'm asking myself if there could be a
> connection between the fun that I have with Lisp and my daily work. I
You may be interested in the Lispweb mailing list:
http://www.red-bean.com/mailman/listinfo/lispweb
> 4. Or what about stuff like mod_lisp? Wouldn't it make sense to leave
I seem to remember that something similar has already been done. Check the
Web section of CLiki:
http://ww.telent.net/cliki/
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
"Dr. Edmund Weitz" <···@agharta.de> wrote
>
> I usually earn my money by programming database-backed web
> applications in Perl, C or (even worse) PHP as a free-lancer. But in
> my spare time, I've re-animated my university knowledge of Lisp, and
> I'm now playing with different CL implementations, reading the books
> of Graham and Norvig and others, writing small applications for fun -
> you get the idea.
>
> As a result of these studies, I'm asking myself if there could be a
> connection between the fun that I have with Lisp and my daily work. I
> wonder what people are using CL-based web servers like CL-HTTP or
> AllegroServe for and if there could be a situation where I could
> convince one of my customers to use CL-HTTP instead of, say, Apache
> and mod_perl. To be more specific:
>
> 4. Or what about stuff like mod_lisp? Wouldn't it make sense to leave
> the tedious work of serving the pages and handling the connections to
> a proven work-horse like Apache?
I'm a little biased toward mod_lisp (www.fractalconcept.com/asp/mod_lisp1)
for these reasons:
The Lisp servers are application servers. I don't want to bother the Lisp
application with thing like serving gif or jpeg files or even static pages
in some cases. Using mod_lisp I can separate the HTTP server from the
application servers.
Time is the scarcest resource so I don't want to waste it to implement
things like SSL, keeping up to date with HTTP protocols etc. The Apache
people do this with a sufficient quality, I don't see any interest to do it
myself.
I can benefit from the Apache modules if I need them (mod_gzip for instance)
The market acceptance is quite better. It's really easier to sell an Apache
+ FreeBSD + (Postgresql or Oracle) + Lisp solution than a Lisp + FreeBSD +
(Postgresql or Oracle) solution. In the first case Lisp is perceived as yet
another web language like Perl, Python and others. In the second case you
have to advocate the use of Lisp.
It's easier to work on a project where the Lisp web application is only a
part of a web site.
Marc
I think mod_lisp is a solution whose time has come and gone.
The problem it solves is still important however. There will
always be cases where a request will need to go through
another web server first. It could be due to firewalls,
or for political reasons, or just because you're in a hurry
and want to add some dynamic content to an
existing site as fast as possible.
mod_lisp is just a proxy module, it takes a request in HTTP
and forwards it to Lisp using a protocol which is very close
to (but isn't exactly) HTTP.
In Lisp we look for a general solution to a problem and
the general proxy solution is a module that
accepts a request via HTTP and sends that request on using
HTTP. The major web servers support this kind of
proxying. Thus this isn't an Apache-only solution and
it's one that web sysadmins will understand (they may
be reluctant to install mod_lisp on the corporate
web server).
By using an HTTP proxy rather than a specialized
mod_lisp proxy the lisp application can be tested
directly using a web server. In fact you could
allow people on the internal network to access
the lisp application server directly and only
outsiders would have to go through the proxy
module to access it.
In the Lisp application can run one of the lisp
web servers or you can write your own special
purpose HTTP server. HTTP is a simple protocol
and unlike what it says on the mod_lisp site you
are not required to always keep up with how
the HTTP spec is changing. Instead the server declares
which version of HTTP it has implemented
and it's then up the client (or proxy) to
adjust itself to use no more of HTTP than
the server understands.
-john foderaro
franz inc
On Sun, 25 Feb 2001 13:56:16 -0800, John Foderaro <···@unspamx.franz.com>
wrote:
> I think mod_lisp is a solution whose time has come and gone.
>The problem it solves is still important however. There will
>always be cases where a request will need to go through
>another web server first. It could be due to firewalls,
>or for political reasons, or just because you're in a hurry
>and want to add some dynamic content to an
>existing site as fast as possible.
Or when you're not sure how AllegroServe or CL-HTTP will behave under heavy
load. Are there any benchmarks comparing them with AOLServer or Apache?
TIA
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
I've done some benchmarking and I'll give you my results below
but there are so many different ways to measure the performance
of a web server that my test is probably not the one that interests you.
What I wanted to know was whether AllegroServe's best case
hit rate was comparable to Apache's. This would also be a measure
of the speed of Allegro CL's home-built multithreading
system (I was running on Linux where we don't use Operating System
supplied threading libraries).
I wrote a tiny C program to blast 10,000 requests at the web server as
fast as it could.
What I found was limiting AllegroServe's hit rate was the logging
by AllegroServe of every request that came in. The logging was slow
for two reasons: it was doing a decode-universal-time for each
request and it was doing a force-output after each log line was
written. This is fine for most systems but if you're expecting
a very high hit rate then you would want to log differently (and
that's work yet to be done).
So I ran the benchmarks with logging turned off as well so that I could
the discover the max hit rate for AllegroServe.
The machine used for testing is a 400mhz Pentium II
running Linux (Redhat 6.2). The web requests came from a process running
on the same machine (thus using the loopback network).
I ran tests of dynamic and static content. The dynamic response
is one line, the static page is 2000 characters.
I've listed the results from worst to best:
-- a naive but common way to get dynamic content in Apache: run a cgi-bin
script.
I know that there is a mod_perl to speed up perl in Apache, I didn't
run it.
apache sh: 97.430319 accesses/sec
apache perl: 97.581454 accesses/sec
-- AllegroServe static page with logging being done. Here we read the static
page from the disk on each access.
acl6 aserve 1.1.21 278.014716 accesses/sec
--- AllegroServe static page with no logging. Here we read the static
page from the disk on each access
acl6 aserve 1.1.21 335.383713 accesses/sec
-- AllegroServe static page with logging being done. Here we use the ability
of AllegroServe to cache static pages in Lisp memory.
acl6 aserve 1.1.21 368.273232 accesses/sec
-- AllegroServe dynamic page with logging being done:
acl6 aserve 1.1.21 398.395518 accesses/sec
--- AllegroServe static page with no logging. Here we use the ability
of AllegroServe to cache static pages in Lisp memory.
acl6 aserve 1.1.21 not logged: 462.928072 accesses/sec
-- Apache static page, with logging.
apache: 474.344576 accesses/sec
-- AllegroServe dynamic page with no logging
acl6 aserve 1.1.21 521.654994 accesses/sec
===================
conclusions? well there are some apples and oranges in the above table.
It is ironic that the naive way of doing dynamic content is
Apache in the slowest in the table and in AllegroServe is the fastest.
However what I concluded is that a lisp written web server is definitely
in the same ballpark of Apache. AllegroServe's connection response speed
is at least as fast as Apache in this test environment.
I would not feel bad about serving static content with AllegroServe
and I would be happy to serve dynamic content from AllegroServe.
A lot of people have looked over Apache for performance but I really
haven't done an extensive performance analysis of AllegroServe
so there's still some more speed to get out of it.
I again caution people to not form broad conclusions based on
these numbers which only test a very specific aspect of a web server
running in a particular environment.
-john foderaro
franz inc.
John Foderaro <···@unspamx.franz.com> writes:
> I think mod_lisp is a solution whose time has come and gone. The
> problem it solves is still important however. There will always be
> cases where a request will need to go through another web server
> first. It could be due to firewalls, or for political reasons, or
> just because you're in a hurry and want to add some dynamic content
> to an existing site as fast as possible.
I agree, but with one caveat, that is that one advantage of something
like mod_lisp, a proxyng module with a specialized backend protocol,
is that it can do things like multiplex requests over the same socket.
Socket creation/destruction overhead is not inconsiderable, so things
like mod_webapp (which the IMHO webapp toolkit now uses instead of
mod_jserv) multiplexes requests over a single socket connection, and
gives a noticeable performance increase.
HTTP proxies could do the same multiplexing, but I'm not sure that the
existing ones do.
--
Craig Brozefsky <·····@red-bean.com>
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
In article <··············@piracy.red-bean.com>, ·····@red-bean.com says...
> I agree, but with one caveat, that is that one advantage of something
> like mod_lisp, a proxyng module with a specialized backend protocol,
> is that it can do things like multiplex requests over the same socket.
If by multiplex you mean have one connection simultaneously handle more
than one request, then it's true that an HTTP proxy won't do that.
However HTTP/1.1 permits (and even encourages) a single socket connection
to be used for a series of requests in order to reduce the connection overhead.
Extensions to HTTP/1.0 can also be used to specify connection reuse.
As an example AllegroServe has the ability to act as a proxy and it
reuses connections for multiple requests to the same destination through
the proxy. I believe that CL-HTTP does as well.
- John Foderaro
Franz Inc.
Marc Battyani wrote:
> The market acceptance is quite better. It's really easier to sell an
> Apache + FreeBSD + (Postgresql or Oracle) + Lisp solution than a Lisp +
> FreeBSD + (Postgresql or Oracle) solution. In the first case Lisp is
> perceived as yet another web language like Perl, Python and others. In the
> second case you have to advocate the use of Lisp.
IMHO this "weblanguages" are the real problem nowadays...
> It's easier to work on a project where the Lisp web application is only a
> part of a web site.
Maybe if what is offered is not more than a web site with some little
dynamic elements. I think we have enough of such pseudo-applications. I
find it much more preferable to see the "web site" part of an application
only as a specific kind of GUI module. My experience showed that it is
better to distinguish between application and user-interface code as much
as possible. Think of the term "model-view-controller".
But the worse part of this all is that rather no web sites that offer some
kind of service like "Webmail", "WebSMS", "Searchengines"... offer _only_
the "User-Interface" but no directly usable "Programmers Interface".
Regards,
Jochen
"Jochen Schmidt" <···@dataheaven.de> wrote
> Marc Battyani wrote:
> > The market acceptance is quite better. It's really easier to sell an
> > Apache + FreeBSD + (Postgresql or Oracle) + Lisp solution than a Lisp +
> > FreeBSD + (Postgresql or Oracle) solution. In the first case Lisp is
> > perceived as yet another web language like Perl, Python and others. In
the
> > second case you have to advocate the use of Lisp.
>
> IMHO this "weblanguages" are the real problem nowadays...
>
> > It's easier to work on a project where the Lisp web application is only
a
> > part of a web site.
>
> Maybe if what is offered is not more than a web site with some little
> dynamic elements. I think we have enough of such pseudo-applications. I
I don't think so. Lisp is always better for complex applications.
When I say application, I don't mean eCommerce where the functionnal part is
very reduced, but real applications like payroll for instance.
I say payroll because I'm just finishing to adapt the payroll of a big
French accounting software editor to the web. They already have a web site
under Win2K+IIS+SQL Sever for eCommerce, product information etc. They
wanted to add a web version of their payroll application to their site but,
as they have already invested a lot of time (and money) in their web site
(using ASP), it would have been impossible to make them drop it (and it's
not useful anyway as they are happy with it). It's just a case but I think
we will see such cases more often. A lot of big companies already have web
sites but now they want to integrate real applications/services in them.
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
...
> It's just a case but I think
> we will see such cases more often. A lot of big companies already have web
> sites but now they want to integrate real applications/services in them.
>
I believe what you just said and what wrote apropos 'mod_lisp' (maybe
a change in name to `mod_common-lisp' is in order) to be very sensible
things.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
"Dr. Edmund Weitz" wrote:
> Hi!
>
> I usually earn my money by programming database-backed web
> applications in Perl, C or (even worse) PHP as a free-lancer. But in
> my spare time, I've re-animated my university knowledge of Lisp, and
> I'm now playing with different CL implementations, reading the books
> of Graham and Norvig and others, writing small applications for fun -
> you get the idea.
>
> As a result of these studies, I'm asking myself if there could be a
> connection between the fun that I have with Lisp and my daily work. I
> wonder what people are using CL-based web servers like CL-HTTP or
> AllegroServe for and if there could be a situation where I could
> convince one of my customers to use CL-HTTP instead of, say, Apache
> and mod_perl. To be more specific:
>
> 1. I understand that an application like CL-HTTP makes sense if you
> need a web frontend to an already existing CL application. But does
> anybody here actually use CL-HTTP or AllegroServe for plain standard
> Websites (where the rest of the world would use Apache, IIS, or
> Netscape)?
I do websites with htmlgen. I am working on a real peice for my Dad:
http://styx.managed-disability.com:8000/
(yes franz, I stole button ideas from you)
(I need to make them smaller still!)
You can edit sites faster using paren-matching mode and lisp indentation
with htmlgen inside emacs.
It has a few bugs right now. (DHTML & GWL) Dave Cooper does sites too.
I am trying to keep up with the dreamweaver & cold fusion people but I
keep on rewriting my tools, so it is expensive and timeconsuming.
If you already know all the browser tricks and http jumpropes you will be
way ahead.
>
>
> 2. Are there significant differences between CL-HTTP and AllegroServe?
> Or: Why did Franz, Inc. write AllegroServe when CL-HTTP already
> existed?
You can do anything with either. CL-HTTP comes as big, allegroserve comes
as small. CL-HTTP multithreading probably still has port issues on
Allegro. Allegroserve is because JKF felt like writing a web server for
fun.
>
>
> 3. What about the performance (where I mean things like speed, size of
> the executables, robustness, etc.) of the CL-based servers compared to
> the usual suspects? If someone has some real-word experiences he or
> she would like to share, please do so.
I am attempting to work into details of that level. Remind me later.
>
>
> 4. Or what about stuff like mod_lisp? Wouldn't it make sense to leave
> the tedious work of serving the pages and handling the connections to
> a proven work-horse like Apache?
then you need an extra interface between the webserver and the application
server. you need an extra IT person to run your apache. lisp does
tedious just fine.
>
>
> (OK, maybe that wasn't very specific. Nevertheless, I'd love to read
> some replies from the comp.lang.lisp community to clarify my cloudy
> vision of Lisp-based web-serving.)
>
the only thing cloudy is http/html and the browser in general.
>
> Thanks in advance for your time and your answers. Any input is
> appreciated.
>
> Edi Weitz
>
> --
> Dr. Edmund Weitz
> Hamburg
> Germany