I'm working toward using mod_lisp under Apache to run a web site. I
fall under the mod_lisp presumptions that Apache is better at serving
up static content and tracks standards and innovations in that area
better, so I should leave it to Apache for that.
Anyhow, I'm thinking about how to actually serve up content from
mod_lisp. lml, some kind of PHP-like parser, or whatever else is
available.
The other thing I want, though, is to take advantage of the
performance I can get from Lisp. What I'm envisioning right now is
the web data area containing *.lisp and the process talking to
mod_lisp keeping a cache of compiled files. That would speed up
performance once it loads the files, but I'd like to keep them cached
in a compiled *and* loaded state. But what if the files on the web
contain conflicting definitions? What if I don't trust them all?
Loading even a compiled file isn't as fast as having it already
loaded. Has anyone come up with any kind of solution that would allow
partitioning like this?
Ari Johnson wrote:
> I'm working toward using mod_lisp under Apache to run a web site. I
> fall under the mod_lisp presumptions that Apache is better at serving
> up static content and tracks standards and innovations in that area
> better, so I should leave it to Apache for that.
>
This is probably true; unfortunately, mod_lisp doesn't seem to work with
Apache 2. (Contradict me, someone?)
> The other thing I want, though, is to take advantage of the
> performance I can get from Lisp. What I'm envisioning right now is
> the web data area containing *.lisp and the process talking to
> mod_lisp keeping a cache of compiled files. That would speed up
> performance once it loads the files, but I'd like to keep them cached
> in a compiled *and* loaded state. But what if the files on the web
> contain conflicting definitions? What if I don't trust them all?
>
> Loading even a compiled file isn't as fast as having it already
> loaded. Has anyone come up with any kind of solution that would allow
> partitioning like this?
>
I've given some thought to this problem, but as of yet I'm stumbling over
two problems - first, I much prefer orthogonal persistence.
Second, I don't *understand* Lisp's filesystem interface, and haven't really
tried to do so. Mea culpa.
My own solution is to put everything that can change - and I do mean
*everything* - in a MySQL database. Functions are stored as strings and
compiled at startup, after which it leaves them alone. Image data is
retrieved at every access. Duplicate data is impossible, because the
functions are keyed on their name.
No, it isn't very fast, but it doesn't need to be; the site averages fifty
visits a day. Doing everything the same way results in simpler code, and
also makes changes easier.
Alternately, you could do it the traditional way (with files), which means
using asdf or mk-defsystem. I only have experience with the former, but I
can say with some certainty that source files are only compiled when
changed. This, most likely, is the *simple* path; I'm just a sucker for
punishment.
Svein Ove Aas <·········@aas.no> writes:
> This is probably true; unfortunately, mod_lisp doesn't seem to work with
> Apache 2. (Contradict me, someone?)
There are several ports floating around. There is one in Marc's
subversion repo, at least:
http://www.fractalconcept.com:8000/public/open-source/mod_lisp/contrib/
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
On Thu, 07 Oct 2004 20:57:52 +0200, <·········@aas.no> wrote:
> Ari Johnson wrote:
>
>> I'm working toward using mod_lisp under Apache to run a web site. I
>> fall under the mod_lisp presumptions that Apache is better at serving
>> up static content and tracks standards and innovations in that area
>> better, so I should leave it to Apache for that.
>>
> This is probably true; unfortunately, mod_lisp doesn't seem to work with
> Apache 2. (Contradict me, someone?)
Apache1 API (not equal) Apache2 API
> My own solution is to put everything that can change - and I do mean
> *everything* - in a MySQL database. Functions are stored as strings and
> compiled at startup, after which it leaves them alone. Image data is
> retrieved at every access. Duplicate data is impossible, because the
> functions are keyed on their name.
Interesting. How about some more details?
TIA
Ari Johnson wrote:
> I'm working toward using mod_lisp under Apache to run a web site. I
> fall under the mod_lisp presumptions that Apache is better at serving
> up static content and tracks standards and innovations in that area
> better, so I should leave it to Apache for that.
I've been doing all my web-dev in lisp for about 6 months now, and i
personally thing mod_lisp is a bad idea. I've had a number of problems
with it (which i wont get into here).
The better solution IMHO is to use a lisp-based http server (i'm using
portable aserve with sbcl under linux), and, should you still need
apache (i have some projects that i use apache for, but i'm slowly
weaning myself off it), you can use mod_proxy to connect to your lisp
process.
I find this provides the best of both worlds. I haven't done any serious
performance testing, as all the apps i'm developing are fairly small in
scale, but having full control over the http server in your lisp image
probably outweighs the (possibly mythical) performance hit.
>
> Anyhow, I'm thinking about how to actually serve up content from
> mod_lisp. lml, some kind of PHP-like parser, or whatever else is
> available.
There are a lot of options here. Personally, I use UncommonWeb and its
TAL implementation, and i also like aserves html macros.
PHP/ASP type stuff hints of code smell to me, as i like to separate any
logic from the html templates. If you are disciplined enough to keep
your logic and presentation seperate, then mixing your lisp and your
html in the same file is fine. personally, i am not quite that
disciplined. i avoid that approach to remove the temptation ;)
>
> The other thing I want, though, is to take advantage of the
> performance I can get from Lisp.
I've noticed a large increase in performance compared to php and
mod_perl, even with the extra overhead of aserve and mod_proxy. Again, i
haven't done any real tests, but it feels faster on my development
workstation, which is good enough for me.
> What I'm envisioning right now is
> the web data area containing *.lisp and the process talking to
> mod_lisp keeping a cache of compiled files. That would speed up
> performance once it loads the files, but I'd like to keep them cached
> in a compiled *and* loaded state. But what if the files on the web
> contain conflicting definitions? What if I don't trust them all?
>
> Loading even a compiled file isn't as fast as having it already
> loaded. Has anyone come up with any kind of solution that would allow
> partitioning like this?
I simply have a "site.lisp" which is loaded into a core containing all
the libs i need. I connect to the process via slime to do any live
changes (having your http errors pop up a debugger is very cool).
I'm not quite sure what you are trying to do here, but i'd be more then
happy to give you any advice/help i can muster. I'm a relative rookie,
but i'll never write another line of php again if i can help it :)
drewc
On Fri, 08 Oct 2004 05:07:06 GMT, <·····@rift.com> wrote:
> Ari Johnson wrote:
>> I'm working toward using mod_lisp under Apache to run a web site. I
>
> I've been doing all my web-dev in lisp for about 6 months now, and i
> personally thing mod_lisp is a bad idea. I've had a number of problems
> with it (which i wont get into here).
Well, you probably should, or else myself (and others) will wonder
which approach is better for them. I'm just killing off my webserver
setup (just a little perl) to switch to lisp as a learning project.
Just installed the latest mod_lisp and about to recreate the old site.
Save me from the error of my ways...or something like that ;-)
> The better solution IMHO is to use a lisp-based http server (i'm using
> portable aserve with sbcl under linux), and, should you still need
> apache (i have some projects that i use apache for, but i'm slowly
> weaning myself off it), you can use mod_proxy to connect to your lisp
> process.
While lisp should be faster than PHP or perl, it would seem that
apache's native sockets ability and codespeed would be better than a
lisp based server.
1) What's the big advantage you see in lisp-httpd?
2) Can you expand on the mod_proxy comment? Seems like that would be
a way to get back to Apache2.
TIA
Time Waster wrote:
> On Fri, 08 Oct 2004 05:07:06 GMT, <·····@rift.com> wrote:
>
>>Ari Johnson wrote:
>>
>>>I'm working toward using mod_lisp under Apache to run a web site. I
>>
>>I've been doing all my web-dev in lisp for about 6 months now, and i
>>personally thing mod_lisp is a bad idea. I've had a number of problems
>>with it (which i wont get into here).
>
>
> Well, you probably should, or else myself (and others) will wonder
> which approach is better for them. I'm just killing off my webserver
> setup (just a little perl) to switch to lisp as a learning project.
> Just installed the latest mod_lisp and about to recreate the old site.
> Save me from the error of my ways...or something like that ;-)
I had some problems with mod_lisp hanging the entire lisp process,
effectively shutting down the site.. I wouldn't take my word on faith,
you should certainly give mod_lisp a try _if_ you really need it.
Also, i found the entire setup felt a little sketchy. Purely subjective,
i admit, but i need to have faith an my software. I believe my problems
had to do with threads and mod_lisp not interacting as they should.
>>The better solution IMHO is to use a lisp-based http server (i'm using
>>portable aserve with sbcl under linux), and, should you still need
>>apache (i have some projects that i use apache for, but i'm slowly
>>weaning myself off it), you can use mod_proxy to connect to your lisp
>>process.
>
>
> While lisp should be faster than PHP or perl, it would seem that
> apache's native sockets ability and codespeed would be better than a
> lisp based server.
Until you have to delegate to lisp for any reason, be it via mod_lisp
(which uses sockets to connect to apache) or mod_proxy. at which point
you are in lisp-land.
mod_lisp works by communicating with apache via a custom protocol over a
socket. (and is infact not lisp specific. one could write an interface
to mod_lisp for any language). So while apache alone would likely be
faster then a lisp based server for serving static pages (although i
have no data to support that), unless you plan on writing your
application as a module in C, you lose that speed advantage when the
overhead of the socket communication comes into play. Apache is a great
server, don't get me wrong, but it is a complex beast.
> 1) What's the big advantage you see in lisp-httpd?
Well, i don't need apache for one ;). That is a bigger advantage then it
may seem. If performance is an issue, a pure lisp http is going to be
faster then an apache interface for serving your dynamic content.
Remember that lisp is a compiled language as well, and in many cases is
on-par with C performance-wise. I suspect your desire to use apache here
may be a case of premature optimization.
Having the httpd in lisp gives you an extra level of control, and really
simplifies the setup. Your httpd can have a repl, and http errors can
bring up a debugger in slime. you can't do that with apache.
Since you are new to lisp, you may not be able to see the advantages in
keeping everything in your lisp image, but believe me, once you've
connected to a running web server and dynamically changed the
configuration, no restart needed, you'll look sideways at a seperate
httpd. There is no /etc/lisp-httpd.conf. it's all in the code. beautiful!
>
> 2) Can you expand on the mod_proxy comment? Seems like that would be
> a way to get back to Apache2.
mod_proxy can be configured as a reverse proxy, so your users connect to
apache, which connects to the lisp httpd. the setup is similar to
mod_lisp, only instead of speaking mod_lisp's protocol, apache and lisp
communicate using http. You get all the control and speed of your lisp
httpd, with all the (????) that you need apache for.
But i have to stress, you probably do not need Apache for most lisp
projects. I know how much we love apache, and i really strung it along
for a while, but now i'm using pure portable aserve for most projects,
as apache was just getting in the way. As long as your lisp supports
threading (sbcl linux is great here), it's going to be faster, simpler,
and, dare i say it, lispy-er.
Apache is like an ex-girlfriend. you miss her at first, but after a
while you begin to wonder what you ever saw in her. We still get
together for a coffee now and then, but all i want to do is talk about
my latest aserve hack... she hates that. Jealous.
Yesterday i removed apache from my workstation... first time in 10 years
i've not had apache installed. Feels great. If only i could remove perl
and gcc, my heresy would be complete.
drewc - yet another former perl hacker turned SmugLispWeenie(tm).
drewc <·····@rift.com> wrote in message news:<·······················@pd7tw1no>...
> But i have to stress, you probably do not need Apache for most lisp
> projects. I know how much we love apache, and i really strung it along
> for a while, but now i'm using pure portable aserve for most projects,
> as apache was just getting in the way. As long as your lisp supports
> threading (sbcl linux is great here), it's going to be faster, simpler,
> and, dare i say it, lispy-er.
Now is probably an appropriate time to add that I have more than just
Lisp projects going on. Let's say that I did either forego Apache or
use a reverse proxy between it and a Lisp HTTP server. Here are the
outstanding issues that I'd like to solve:
1. XHTML templating - I haven't yet found a Lisp-based template engine
that strikes me as being good, although drewc has e-mailed me an idea
or two that I need to research.
2. Partitioning of projects - I will not have just one project, and I
would really prefer it if they were separated along very well-defined
lines. Not all code needs to talk to its neighbors. Independence of
each wheel is important so that the wheels still function when put on
other cars.
3. Partitioning of users - if I decide to allow other users than
myself to write Lisp code for the web, a securely partitioned Lisp
image would be nice.
There may be others that I'm missing, but those are key right now
(particularly #1 and #2).
"drewc" <·····@rift.com> wrote
> Time Waster wrote:
> >
> > While lisp should be faster than PHP or perl, it would seem that
> > apache's native sockets ability and codespeed would be better than a
> > lisp based server.
>
> Until you have to delegate to lisp for any reason, be it via mod_lisp
> (which uses sockets to connect to apache) or mod_proxy. at which point
> you are in lisp-land.
>
> mod_lisp works by communicating with apache via a custom protocol over a
> socket. (and is infact not lisp specific. one could write an interface
> to mod_lisp for any language). So while apache alone would likely be
> faster then a lisp based server for serving static pages (although i
> have no data to support that), unless you plan on writing your
> application as a module in C, you lose that speed advantage when the
> overhead of the socket communication comes into play. Apache is a great
> server, don't get me wrong, but it is a complex beast.
Here is some data with the paserve home page as HTML data:
Tested with: ab -n 1000 -c 20 http://<the server tested>
(ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3)
Run several times on a small dual proc Dell server (PowerEdge 1600Sc) (I
take the best run).
The Lisp used is Lispworks Linux.
A mod_lisp server:
Time taken for tests: 0.678 seconds
Requests per second: 1474.93 [#/sec] (mean)
Time per request: 13.56 [ms] (mean)
Time per request: 0.68 [ms] (mean, across all concurrent requests)
Transfer rate: 2159.29 [Kbytes/sec] received
paserve server:
Time taken for tests: 3.161 seconds
Requests per second: 316.36 [#/sec] (mean)
Time per request: 63.22 [ms] (mean)
Time per request: 3.16 [ms] (mean, across all concurrent requests)
Transfer rate: 417.27 [Kbytes/sec] received
paserve behind apache mod_proxy:
Time taken for tests: 3.627 seconds
Requests per second: 275.71 [#/sec] (mean)
Time per request: 72.54 [ms] (mean)
Time per request: 3.63 [ms] (mean, across all concurrent requests)
Transfer rate: 381.03 [Kbytes/sec] received
So you go from 1474 pages/s to 275 pages/s
> > 1) What's the big advantage you see in lisp-httpd?
>
> Well, i don't need apache for one ;). That is a bigger advantage then it
> may seem. If performance is an issue, a pure lisp http is going to be
> faster then an apache interface for serving your dynamic content.
The real life seems to contradict this. And no it's not because C is better
than Lisp.
> Remember that lisp is a compiled language as well, and in many cases is
> on-par with C performance-wise. I suspect your desire to use apache here
> may be a case of premature optimization.
[...]
> Apache is like an ex-girlfriend. you miss her at first, but after a
> while you begin to wonder what you ever saw in her. We still get
> together for a coffee now and then, but all i want to do is talk about
> my latest aserve hack... she hates that. Jealous.
I think you are completely missing the point.
The major interest of mod_lisp is not technical it's a marketting/political
one. (though mod_lisp is also pretty fast anyway)
When you want to make web applications for clients, and get paid for that,
the fact that there is a mod_lisp that runs with Apache is often the easiest
way and sometimes the only way to be accepted in a corporate environment.
For instance lots of big corps (the ones which have money) have developped
secured linux distribution where you are not allowed to install anything
else than Apache. The fact that the application write things in the Apache
logs through mod_lisp make their sys admin teams (and all their scripts)
happy.
Telling them that no, you are not going to use Java because life is too
short, is already hard enough that you don't want to add the handicap of not
using Apache.
Those who do not understand that deserve to write web applications in
PHP/Java/zope/etc. ;-)
Of course if it's just to play it's entirely different.
> drewc - yet another former perl hacker turned SmugLispWeenie(tm).
At least that is a good point ;-)
Marc
Marc Battyani wrote:
> "drewc" <·····@rift.com> wrote
>
>>Time Waster wrote:
>>
>>>While lisp should be faster than PHP or perl, it would seem that
>>>apache's native sockets ability and codespeed would be better than a
>>>lisp based server.
>>
< snipped my 'foot in mouth' assumptions >
>
>
> Here is some data with the paserve home page as HTML data:
> Tested with: ab -n 1000 -c 20 http://<the server tested>
> (ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3)
> Run several times on a small dual proc Dell server (PowerEdge 1600Sc) (I
> take the best run).
> The Lisp used is Lispworks Linux.
>
> A mod_lisp server:
> Time taken for tests: 0.678 seconds
> Requests per second: 1474.93 [#/sec] (mean)
> Time per request: 13.56 [ms] (mean)
> Time per request: 0.68 [ms] (mean, across all concurrent requests)
> Transfer rate: 2159.29 [Kbytes/sec] received
>
> paserve server:
> Time taken for tests: 3.161 seconds
> Requests per second: 316.36 [#/sec] (mean)
> Time per request: 63.22 [ms] (mean)
> Time per request: 3.16 [ms] (mean, across all concurrent requests)
> Transfer rate: 417.27 [Kbytes/sec] received
>
> paserve behind apache mod_proxy:
> Time taken for tests: 3.627 seconds
> Requests per second: 275.71 [#/sec] (mean)
> Time per request: 72.54 [ms] (mean)
> Time per request: 3.63 [ms] (mean, across all concurrent requests)
> Transfer rate: 381.03 [Kbytes/sec] received
>
> So you go from 1474 pages/s to 275 pages/s
Thanks for the data, it's good to know. I'll probably run some similar
tests with SBCL tonight. What type of threading does LispWorks use under
linux?
It is _quite_ a performance hit, and if i'm ever lucky enough to have a
site that needs to serve 1474 pages/s, i'll certainly give mod_lisp
another look :)
>
>
>>>1) What's the big advantage you see in lisp-httpd?
>>
>>Well, i don't need apache for one ;). That is a bigger advantage then it
>>may seem. If performance is an issue, a pure lisp http is going to be
>>faster then an apache interface for serving your dynamic content.
>
>
> The real life seems to contradict this. And no it's not because C is better
> than Lisp.
That it does! thanks for running those tests. It still feels faster on
my workstation, so perhaps it's a CPU thing.. i'll have to investigate a
little further.
>
>>Apache is like an ex-girlfriend. you miss her at first, but after a
>>while you begin to wonder what you ever saw in her. We still get
>>together for a coffee now and then, but all i want to do is talk about
>>my latest aserve hack... she hates that. Jealous.
>
>
> I think you are completely missing the point.
> The major interest of mod_lisp is not technical it's a marketting/political
> one. (though mod_lisp is also pretty fast anyway)
> When you want to make web applications for clients, and get paid for that,
> the fact that there is a mod_lisp that runs with Apache is often the easiest
> way and sometimes the only way to be accepted in a corporate environment.
> For instance lots of big corps (the ones which have money) have developped
> secured linux distribution where you are not allowed to install anything
> else than Apache. The fact that the application write things in the Apache
> logs through mod_lisp make their sys admin teams (and all their scripts)
> happy.
>
> Telling them that no, you are not going to use Java because life is too
> short, is already hard enough that you don't want to add the handicap of not
> using Apache.
If you need apache, then mod_lisp is great i admit. the OP mentioned
that it was for a learning experience, so i suggested using a lisp
httpd. I then rambled on about performance... something i know nothing
about :)
I have used mod_lisp for those clients that require apache, and have
only recently started using aserve full time whenever possible. I still
prefer aserve, performance be damned! but often, it's not my choice.
Heck, if they are letting me use lisp, i'll serve it though IIS if i
have to make the PHB's happy.
>
> Those who do not understand that deserve to write web applications in
> PHP/Java/zope/etc. ;-)
poor bastards.
>
> Of course if it's just to play it's entirely different.
>
Most of my contracts are for small businesses. Intranets, Databases etc.
(I replace a lot of access with a web based solution). In these cases a
lisp httpd simplifies things greatly, and since the chances of getting
more then one hit/sec are minimal, the performance degredation is not an
issue.
Even for most web sites i build, the chances of getting 200h/s + are
minimal.. should they begin to see that kind of traffic, they can afford
to have me come back and profile/tune. Infact, they'd be happy to have
me back, as my site has generated such business for them! This was why i
mentioned i though mod_lisp was premature optimization, before my
uninformed digression on performance.
While hardly 'play', most of the apps i build in lisp are not hardened
enterprise applications. I usually serve as the sysadmin, developer, and
support staff... so pleasing myself technically, and making it simple to
administer/support far outweighs the performance benefits of using
apache/mod_lisp.
Different strokes for different folks i guess. ;)
Thanks again for the benchmark data .. cleared a few things up.
drewc
"drewc" <·····@rift.com> wrote
> Marc Battyani wrote:
> >
> > Here is some data with the paserve home page as HTML data:
> > Tested with: ab -n 1000 -c 20 http://<the server tested>
> > (ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3)
> > Run several times on a small dual proc Dell server (PowerEdge 1600Sc) (I
> > take the best run).
> > The Lisp used is Lispworks Linux.
> >
> > A mod_lisp server:
> > Time taken for tests: 0.678 seconds
> > Requests per second: 1474.93 [#/sec] (mean)
> > Time per request: 13.56 [ms] (mean)
> > Time per request: 0.68 [ms] (mean, across all concurrent requests)
> > Transfer rate: 2159.29 [Kbytes/sec] received
> >
> > paserve server:
> > Time taken for tests: 3.161 seconds
> > Requests per second: 316.36 [#/sec] (mean)
> > Time per request: 63.22 [ms] (mean)
> > Time per request: 3.16 [ms] (mean, across all concurrent requests)
> > Transfer rate: 417.27 [Kbytes/sec] received
> >
> > paserve behind apache mod_proxy:
> > Time taken for tests: 3.627 seconds
> > Requests per second: 275.71 [#/sec] (mean)
> > Time per request: 72.54 [ms] (mean)
> > Time per request: 3.63 [ms] (mean, across all concurrent requests)
> > Transfer rate: 381.03 [Kbytes/sec] received
> >
> > So you go from 1474 pages/s to 275 pages/s
>
> Thanks for the data, it's good to know. I'll probably run some similar
> tests with SBCL tonight. What type of threading does LispWorks use under
> linux?
Not real ones unfortunately.
> It is _quite_ a performance hit, and if i'm ever lucky enough to have a
> site that needs to serve 1474 pages/s, i'll certainly give mod_lisp
> another look :)
Well as I told you, performance is not really the point. Even 300 req/s is
plenty enough.
The performance gap will be lower with a single processor server.
[...]
> > I think you are completely missing the point.
> > The major interest of mod_lisp is not technical it's a
marketting/political
> > one. (though mod_lisp is also pretty fast anyway)
> > When you want to make web applications for clients, and get paid for
that,
> > the fact that there is a mod_lisp that runs with Apache is often the
easiest
> > way and sometimes the only way to be accepted in a corporate
environment.
> > For instance lots of big corps (the ones which have money) have
developped
> > secured linux distribution where you are not allowed to install anything
> > else than Apache. The fact that the application write things in the
Apache
> > logs through mod_lisp make their sys admin teams (and all their scripts)
> > happy.
> >
> > Telling them that no, you are not going to use Java because life is too
> > short, is already hard enough that you don't want to add the handicap of
not
> > using Apache.
>
> If you need apache, then mod_lisp is great i admit. the OP mentioned
> that it was for a learning experience, so i suggested using a lisp
> httpd. I then rambled on about performance... something i know nothing
> about :)
>
> I have used mod_lisp for those clients that require apache, and have
> only recently started using aserve full time whenever possible. I still
> prefer aserve, performance be damned! but often, it's not my choice.
You are comparing different things. mod_lisp is a just low level connector
between Apache and Lisp.It does not provide any service beside this. If you
want something more high level have a look at TBNL from Edi Weitz or
cl-modlisp for something intermediate.You could use mod_lisp with aserve if
you wanted. You would just have to change the low level layer of paserve but
keep all the above layers.
> Heck, if they are letting me use lisp, i'll serve it though IIS if i
> have to make the PHB's happy.
I thought about a making an ISAPI_Lisp module when I wrote mod_lisp but it
has no interest as nobody sane would run a web server on windows.
> > Those who do not understand that deserve to write web applications in
> > PHP/Java/zope/etc. ;-)
>
> poor bastards.
;-)
> > Of course if it's just to play it's entirely different.
>
> Most of my contracts are for small businesses. Intranets, Databases etc.
> (I replace a lot of access with a web based solution). In these cases a
> lisp httpd simplifies things greatly, and since the chances of getting
> more then one hit/sec are minimal, the performance degredation is not an
> issue.
>
> Even for most web sites i build, the chances of getting 200h/s + are
> minimal.. should they begin to see that kind of traffic, they can afford
> to have me come back and profile/tune. Infact, they'd be happy to have
> me back, as my site has generated such business for them! This was why i
> mentioned i though mod_lisp was premature optimization, before my
> uninformed digression on performance.
>
> While hardly 'play', most of the apps i build in lisp are not hardened
> enterprise applications. I usually serve as the sysadmin, developer, and
> support staff... so pleasing myself technically, and making it simple to
> administer/support far outweighs the performance benefits of using
> apache/mod_lisp.
??? Apache/mod_lisp installation is really simple.
As I wrote before, just have a look at TBNL and cl-modlisp if you want
something more high level.
> Different strokes for different folks i guess. ;)
Sure. Lisp is multi-paradigms ;-)
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> "drewc" <·····@rift.com> wrote
>> Marc Battyani wrote:
>> >
>> > Here is some data with the paserve home page as HTML data:
>> > Tested with: ab -n 1000 -c 20 http://<the server tested>
>> > (ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3)
>> > Run several times on a small dual proc Dell server (PowerEdge 1600Sc) (I
>> > take the best run).
>> > The Lisp used is Lispworks Linux.
>> >
>> > A mod_lisp server:
>> > Time taken for tests: 0.678 seconds
>> > Requests per second: 1474.93 [#/sec] (mean)
>> > Time per request: 13.56 [ms] (mean)
>> > Time per request: 0.68 [ms] (mean, across all concurrent requests)
>> > Transfer rate: 2159.29 [Kbytes/sec] received
>> >
>> > paserve server:
>> > Time taken for tests: 3.161 seconds
>> > Requests per second: 316.36 [#/sec] (mean)
>> > Time per request: 63.22 [ms] (mean)
>> > Time per request: 3.16 [ms] (mean, across all concurrent requests)
>> > Transfer rate: 417.27 [Kbytes/sec] received
>> >
>> > paserve behind apache mod_proxy:
>> > Time taken for tests: 3.627 seconds
>> > Requests per second: 275.71 [#/sec] (mean)
>> > Time per request: 72.54 [ms] (mean)
>> > Time per request: 3.63 [ms] (mean, across all concurrent requests)
>> > Transfer rate: 381.03 [Kbytes/sec] received
>> >
>> > So you go from 1474 pages/s to 275 pages/s
>>
>> Thanks for the data, it's good to know. I'll probably run some similar
>> tests with SBCL tonight. What type of threading does LispWorks use under
>> linux?
>
> Not real ones unfortunately.
>
>> It is _quite_ a performance hit, and if i'm ever lucky enough to have a
>> site that needs to serve 1474 pages/s, i'll certainly give mod_lisp
>> another look :)
>
> Well as I told you, performance is not really the point. Even 300 req/s is
> plenty enough.
> The performance gap will be lower with a single processor server.
,----[ specs ]
| 2.6.7-gentoo-r11 #3 Mon Jul 26 12:36:10 CEST 2004 i686 Intel(R)
| Pentium(R) M processor 1600MHz GenuineIntel GNU/Linux
`----
Static html content from http://portableaserve.sourceforge.net/index.htm
Tested with: ab -n 1000 -c 20
Apache: apache2 -v Server version: Apache/2.0.51
Requests per second: 925.84 [#/sec] (mean)
Time per request: 21.602 [ms] (mean)
Time per request: 1.080 [ms] (mean, across all concurrent requests)
Transfer rate: 4619.01 [Kbytes/sec] received
Aserve: Allegro 6.2
Requests per second: 773.50 [#/sec] (mean)
Time per request: 25.856 [ms] (mean)
Time per request: 1.293 [ms] (mean, across all concurrent requests)
Transfer rate: 3825.74 [Kbytes/sec] receive
Portableaserve(CVS): SBCL 0.8.14 #+sb-threads
Requests per second: 211.99 [#/sec] (mean)
Time per request: 94.346 [ms] (mean)
Time per request: 4.717 [ms] (mean, across all concurrent requests)
Transfer rate: 1043.18 [Kbytes/sec] received
Not too bad with Allegro
--
Torkel Holm
Torkel Holm <······@ii.uib.no> writes:
> ,----[ specs ]
> | 2.6.7-gentoo-r11 #3 Mon Jul 26 12:36:10 CEST 2004 i686 Intel(R)
> | Pentium(R) M processor 1600MHz GenuineIntel GNU/Linux
> `----
>
> Static html content from http://portableaserve.sourceforge.net/index.htm
> Tested with: ab -n 1000 -c 20
>
> Apache: apache2 -v Server version: Apache/2.0.51
>
> Requests per second: 925.84 [#/sec] (mean)
> Time per request: 21.602 [ms] (mean)
> Time per request: 1.080 [ms] (mean, across all concurrent requests)
> Transfer rate: 4619.01 [Kbytes/sec] received
I forgot to turn off the rewrite engine. Its a real performance killer.
Requests per second: 1717.52 [#/sec] (mean)
> Aserve: Allegro 6.2
> Requests per second: 773.50 [#/sec] (mean)
After some experimentation with numbers of listeners I got
an average of 830 rps.
Lispworks was a close race.
--
Torkel Holm
"Marc Battyani" <·············@fractalconcept.com> writes:
>
> I thought about a making an ISAPI_Lisp module when I wrote mod_lisp but it
> has no interest as nobody sane would run a web server on windows.
While I agree with you, there *are* lots of crazy people out there.
marc
"Marc Spitzer" <········@optonline.net> wrote
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> > I thought about a making an ISAPI_Lisp module when I wrote mod_lisp but
it
> > has no interest as nobody sane would run a web server on windows.
>
> While I agree with you, there *are* lots of crazy people out there.
Here are the latest news for them ;-)
"A security flaw in Microsoft's ASP.NET technology could allow intruders to
enter password-protected areas of a web site by altering a URL. A fix is not
yet available, but Microsoft is offfering guidelines to help ASP.NET users
secure their sites against intrusion attempts. The flaw exists only in
ASP.NET, not ASP (Active Server Pages)."
ROTFL :)
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> cl-modlisp for something intermediate.You could use mod_lisp with aserve if
> you wanted. You would just have to change the low level layer of paserve but
> keep all the above layers.
You could, but it wouldn't make much sense, would it? Or am I missing
something?
Andras
"Andras Simon" <······@math.bme.hu> wrote
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> > cl-modlisp for something intermediate.You could use mod_lisp with aserve
if
> > you wanted. You would just have to change the low level layer of paserve
but
> > keep all the above layers.
>
> You could, but it wouldn't make much sense, would it? Or am I missing
> something?
[from another post]
>And if you want static pages to be served by Apache, you can put
>aserve behind Apache via mod_proxy or mod_rewrite (or whatever it's
>called) and do that. I have a site with this setup (no clp though),
>and it has gathered a few million hits in the past 18 month or so with
>no problems. My only (minor) gripe with it is that aserve doesn't see
>where a request is really coming from.
Of course it would make sense. mod_lisp would only replace the a small
percentage of aserve: The part that deals with HTTP requests. Instead of
decoding those requests, you get them pre-decoded by Apache from mod_lisp.
And then you go on with the rest of the aserve code. (session stuff,
webactions, etc.). It's much better than mod_proxy because you are
considered as inside Apache. That is you can write in Apache logs, get
Apache information like the IP address of the requester, etc.
As I wrote several times, mod_lisp is not a server. It's just a way to get
the pre-decoded requests from Apache. So It could be used with any Lisp
server like (paserve, cl-http, Araneida, etc.) by just replacing the HTTP
processing layer. Or you can use TBNL which is a web framework that already
uses mod_lisp for its HTTP layer.
Marc
Marc Battyani wrote:
>
> The real life seems to contradict this. And no it's not because C is
better
> than Lisp.
>
I think it's always dangerous to underestimate how good a system which
has had the amount of battle testing that apache has can be.
On the other hand, it can also be fairly dangerous to go for some
heavily layered system where you have, say, a couple of layers of
apaches (caches and then actual front-end servers) forwarding stuff to
application servers which in turn may have several layers, and will
probably themselves talk to some backend database. And each of these
layers will have some replication for redundancy, of course. This is
pretty much what the classic modern e-commerce system looks like as
far as I can see. Each of these layers adds latency; each of them can
independently go wrong; logging and debugging is exciting in a fairly
bad way; deployment is *very* exciting unless you have a really solid
system, which almost no-one does. I've fairly seriously suggested the
single-huge-server approach: it costs a lot but it might actually
work...
--tim
According to Tim Bradshaw <··········@tfeb.org>:
> On the other hand, it can also be fairly dangerous to go for some
> heavily layered system where you have, say, a couple of layers of
> apaches (caches and then actual front-end servers) forwarding stuff to
> application servers which in turn may have several layers, and will
> probably themselves talk to some backend database.
http://meet-the-makers.com/conversations/witchel/4/
"Back then we planned to be huge from the outset. So we built this monster
platform on BEA, Sun and Oracle. We had huge dedicated connectivity pipes.
We had two full racks clustered and fully redundant. We had E450\u2019s
with RAID-5 and all 4 CPU slots filled, E250s, F5 load balancers...the cost
of keeping that system on was enormous. The headcount to keep it humming
was enormous too.
"The truth is, we could have run the whole company on my laptop using a
cable modem connection."
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
[Sorry for the late response... --rpw3]
Marc Battyani <·············@fractalconcept.com> wrote:
+---------------
| "drewc" <·····@rift.com> wrote
| > Remember that lisp is a compiled language as well, and in many cases is
| > on-par with C performance-wise. I suspect your desire to use apache here
| > may be a case of premature optimization.
...
| I think you are completely missing the point.
| The major interest of mod_lisp is not technical it's a marketting/political
| one. (though mod_lisp is also pretty fast anyway)
| When you want to make web applications for clients, and get paid for that,
| the fact that there is a mod_lisp that runs with Apache is often the easiest
| way and sometimes the only way to be accepted in a corporate environment.
+---------------
I completely agree! And not just in "corporate" environments. Using
Lisp for a non-profit project was made *much* easier for me by the
ability to co-exist with the already-deployed Apache server at that site.
I actually went even further in the "leave Apache alone" direction[1],
namely, I didn't run real "mod_lisp" per se, but rather wrote a *tiny*
C program that runs as an ordinary CGI program under Apache but then
connects to the persistent Lisp server [CMUCL, in my case] via a Unix-
domain socket... and speaks "mod_lisp" protocol to it! ;-}
Because I didn't even need to restart Apache to add my app, the sysadmins
of the existing web site had *no* problems with my using Lisp...
But if performance of the Lisp server ever becomes an issue[2], all I
have to do is remove my C program and drop in *real* "mod_lisp" and the
Lisp server won't even notice the change [except for performance].
-Rob
[1] Something that Marc has teased me about several times, actually!
[2] Yes, a CGI fork/exec per request is slow, but I get >75 req/sec
through Apache + "cgi_sock" + CMUCL server. On the same system,
I get ~145 req/sec for simple Perl-based CGI, and ~1300 req/sec
for a small static page. FOR THE CURRENT LOAD, even 75 req/sec
is overkill. But if that changes, I have "real" mod_lisp to use.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> [Sorry for the late response... --rpw3]
np! i was sad when this thread died, as i learned quite a bit from it.
>
> I actually went even further in the "leave Apache alone" direction[1],
> namely, I didn't run real "mod_lisp" per se, but rather wrote a *tiny*
> C program that runs as an ordinary CGI program under Apache but then
> connects to the persistent Lisp server [CMUCL, in my case] via a Unix-
> domain socket... and speaks "mod_lisp" protocol to it! ;-}
Genius! This could allow lisp to work in a virtual hosted env, where
mod_lisp is not available. Infact, i could probably use this in a number
of projects right now! Any source available? I'd love to play with this.
I've been looking for a similar solution, ie: keep the site hosted on a
cheap virtual host, but pass the lisp stuff off to our expensive VPS.
The main advantage of lisp is it's flexibility. I'm constantly amazed by
the ingenuity of the lisp community! This is another great example.
Thanks for the thought-food.
drewc
On Fri, 08 Oct 2004 17:35:47 GMT, <·····@rift.com> wrote:
>> Time Waster wrote:
>>
>> Save me from the error of my ways...or something like that ;-)
>
> I had some problems with mod_lisp hanging the entire lisp process,
> effectively shutting down the site.. I wouldn't take my word on faith,
> you should certainly give mod_lisp a try _if_ you really need it.
It seems that you might be creating closed servers, but it that 'hang'
was on a internet pipe, I would wonder about the content of the http
request.
>> 1) What's the big advantage you see in lisp-httpd?
>
> Well, i don't need apache for one ;). That is a bigger advantage then it
Perhaps you haven't spent much time scanning apache logs. Why should
I dump some software that has been Internet battle-tested for
something new? The current apaches have had most (if not all) of the
real exploits debugged. I doubt that a lisp-httpd can make that
claim...although it's clear that apache will not be a full shield to a
'mod_lisp'.
Time Waster <········@CloudDancer.com> writes:
> While lisp should be faster than PHP or perl, it would seem that
> apache's native sockets ability and codespeed would be better than a
> lisp based server.
I haven't seen any benchmarks to prove this, but to me Allegroserve
appears to be very fast.
In AllegroServe there is no overhead in calling Common Lisp and hence
dynamic generation of HTML is very fast.
The "externsion langauge" is *compiled* Common Lisp, not some
interpreted language.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
drewc <·····@rift.com> writes:
> The better solution IMHO is to use a lisp-based http server (i'm using
> portable aserve with sbcl under linux), and, should you still need
> apache (i have some projects that i use apache for, but i'm slowly
> weaning myself off it), you can use mod_proxy to connect to your lisp
> process.
I hear nice things about (but haven't yet tried) Pound: "a reverse
proxy, load balancer and HTTPS front-end for Web server(s)". I think
there's a recipe for using it with Araneida on the latter's CLiki page.
http://www.apsis.ch/pound/
It doesn't quite do all of what Apache mod_proxy does for me; it
doesn't cache. I go to reasonable lengths (at least on complicat4red
pages) to set correct Last-Modified and Expires times on my pages,
and so get free caching from mod_proxy
-dan
--
"please make sure that the person is your friend before you confirm"
On Fri, 08 Oct 2004 05:07:06 GMT, drewc <·····@rift.com> wrote:
> Ari Johnson wrote:
>> I'm working toward using mod_lisp under Apache to run a web site. I
>> fall under the mod_lisp presumptions that Apache is better at serving
>> up static content and tracks standards and innovations in that area
>> better, so I should leave it to Apache for that.
>
Have you tried fastCGI? It works under Apache 2 and on all Apache systems.
(Supported by Apache.)
It requires some glue code to connect to Lisp but I might be able to help
yo on that.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
·········@gmail.com (Ari Johnson) writes:
> The other thing I want, though, is to take advantage of the
> performance I can get from Lisp. What I'm envisioning right now is
> the web data area containing *.lisp and the process talking to
> mod_lisp keeping a cache of compiled files. That would speed up
> performance once it loads the files, but I'd like to keep them cached
> in a compiled *and* loaded state. But what if the files on the web
> contain conflicting definitions? What if I don't trust them all?
>
> Loading even a compiled file isn't as fast as having it already
> loaded. Has anyone come up with any kind of solution that would allow
> partitioning like this?
Do you want a CGI-style website? If so, why? If not, then I don't
understand your problem.
Andras
Andras Simon <······@math.bme.hu> wrote in message news:<···············@csusza.math.bme.hu>...
> Do you want a CGI-style website? If so, why? If not, then I don't
> understand your problem.
What do you mean by "CGI-style"? What I want is a web server that
excels at serving up everything I could ask it to. Right now, I can't
get away from PHP for varying reasons, and even if I could, I feel
Apache is probably better-tuned to serving up static content and also
to dealing with SSL requests.
What I want is to fit Lisp into my site as seamlessly as possible
without incurring lots of performance overhead (like running lisp as a
shebang-style CGI).
·········@gmail.com (Ari Johnson) writes:
> Andras Simon <······@math.bme.hu> wrote in message news:<···············@csusza.math.bme.hu>...
> > Do you want a CGI-style website? If so, why? If not, then I don't
> > understand your problem.
>
> What do you mean by "CGI-style"? What I want is a web server that
Probably the same as you do (shebang-style CGI). The reason I
suspected you were planning to do this is that you wrote
| What I'm envisioning right now is
| the web data area containing *.lisp and the process talking to
| mod_lisp keeping a cache of compiled files. That would speed up
| performance once it loads the files, but I'd like to keep them cached
| in a compiled *and* loaded state.
But now I see that you meant PHP/JSP-like templates. In that case, you
could give aserve/webaction's clp a try. From the doc:
A clp file is parsed when it's first referenced in an http request
and the results of the parse are cached The clp file is not parsed
again unless the file is updated on disk.
And if you want static pages to be served by Apache, you can put
aserve behind Apache via mod_proxy or mod_rewrite (or whatever it's
called) and do that. I have a site with this setup (no clp though),
and it has gathered a few million hits in the past 18 month or so with
no problems. My only (minor) gripe with it is that aserve doesn't see
where a request is really coming from.
Andras
Andras Simon <······@math.bme.hu> wrote in message news:<···············@csusza.math.bme.hu>...
> ·········@gmail.com (Ari Johnson) writes:
>
> > Andras Simon <······@math.bme.hu> wrote in message news:<···············@csusza.math.bme.hu>...
> But now I see that you meant PHP/JSP-like templates. In that case, you
> could give aserve/webaction's clp a try. From the doc:
That's one idea I'm pursuing. The idea there is that the majority of
content is large blobs of text with occasional formatting. Wikis
operate under this principle (by concentrating on the text and
simplifying the formatting instructions) along with the principle that
there is a direct relationship between the number of monkeys at the
keyboard and the probability of recreating Shakespeare.
What I really want is:
1. Partitioning between projects - with PHP I just write
directory-portable code and put each project in its own directory
2. Partitioning between users - although less important since I will
most likely be the only user writing Lisp-powered web pages on my
server, it'd be nice to create separate users from my own account and
use them to separate projects (this is not essential, just a
nice-to-have thing)
3. Seamless integration with rest of site - I still have PHP
applications, and my resume is still an XSLT application; being able
to run parts of my site with Lisp without having a crazy URL scheme in
which all Lisp is relegated to a particular URL namespace
(http://server/lisp/...) is essential
4. Good template language - I've seen some pretty bad template
languages; also, writing templates in HTML and then inserting active
template code makes more sense to me, as it is far easier to prototype
HTML with a static file than it is if you have to recompile and reload
after every change before you can see the changes
> And if you want static pages to be served by Apache, you can put
> aserve behind Apache via mod_proxy or mod_rewrite (or whatever it's
> called) and do that. I have a site with this setup (no clp though),
> and it has gathered a few million hits in the past 18 month or so with
> no problems. My only (minor) gripe with it is that aserve doesn't see
> where a request is really coming from.
It's mod_proxy, which I haven't used before. See requirement 3 above
for my reasoning against this approach.
On a side note: Man, do I wish I still had access to a good Usenet
server so I could post with less delay.
·········@gmail.com (Ari Johnson) writes:
> Andras Simon <······@math.bme.hu> wrote in message news:<···············@csusza.math.bme.hu>...
> > ·········@gmail.com (Ari Johnson) writes:
> >
> > > Andras Simon <······@math.bme.hu> wrote in message news:<···············@csusza.math.bme.hu>...
> > But now I see that you meant PHP/JSP-like templates. In that case, you
> > could give aserve/webaction's clp a try. From the doc:
>
> That's one idea I'm pursuing. The idea there is that the majority of
> content is large blobs of text with occasional formatting. Wikis
> operate under this principle (by concentrating on the text and
> simplifying the formatting instructions) along with the principle that
> there is a direct relationship between the number of monkeys at the
> keyboard and the probability of recreating Shakespeare.
>
> What I really want is:
> 1. Partitioning between projects - with PHP I just write
> directory-portable code and put each project in its own directory
See the destination argument of webaction-project.
> 2. Partitioning between users - although less important since I will
> most likely be the only user writing Lisp-powered web pages on my
> server, it'd be nice to create separate users from my own account and
> use them to separate projects (this is not essential, just a
> nice-to-have thing)
If you really want this, I'm sure you'll be able to come up with a
scheme that works for you, no matter what approach (mod_lisp or
aserve) you use.
> 3. Seamless integration with rest of site - I still have PHP
> applications, and my resume is still an XSLT application; being able
> to run parts of my site with Lisp without having a crazy URL scheme in
> which all Lisp is relegated to a particular URL namespace
> (http://server/lisp/...) is essential
I'm afraid you'll have to deal with this problem even if you use
mod_lisp. I'm no apache guru (far from it!) but I think mod_rewrite is
your friend.
> 4. Good template language - I've seen some pretty bad template
> languages; also, writing templates in HTML and then inserting active
> template code makes more sense to me, as it is far easier to prototype
> HTML with a static file than it is if you have to recompile and reload
> after every change before you can see the changes
This is a very respectable opinion which I happen not to share. M-C-x is
just as easy as C-x C-s, and I find writing lhtml easier than writing
html. (Designers may not agree; but there's always phtml which will
parse their pages to lhtml. Though I must admit I've never tried this
approach.) But have a look at clp and see if you like it.
>
> > And if you want static pages to be served by Apache, you can put
> > aserve behind Apache via mod_proxy or mod_rewrite (or whatever it's
> > called) and do that. I have a site with this setup (no clp though),
> > and it has gathered a few million hits in the past 18 month or so with
> > no problems. My only (minor) gripe with it is that aserve doesn't see
> > where a request is really coming from.
>
> It's mod_proxy, which I haven't used before. See requirement 3 above
> for my reasoning against this approach.
See my reply to it.
>
> On a side note: Man, do I wish I still had access to a good Usenet
> server so I could post with less delay.
:-(
Andras
According to Ari Johnson <·········@gmail.com>:
> 1. Partitioning between projects - with PHP I just write
> directory-portable code and put each project in its own directory
Each "project" is presumably accessible via a different URL "root" and is
thus handled by different Lisp code. You can partition your code using Lisp
"packages". Once loaded, all your code lives in the Lisp process.
Each package is usually kept in its own set of files, but there is no rule
in Lisp that says the files containing the code for package
"com.netmemetic.lisp.webutils" must live in a directory structure mirroring
the package name.
> 2. Partitioning between users - although less important since I will
> most likely be the only user writing Lisp-powered web pages on my
> server, it'd be nice to create separate users from my own account and
> use them to separate projects (this is not essential, just a
> nice-to-have thing)
The simplest way is to run multiple Lisp processes. FreeBSD jails! FreeBSD
jails! ;-) Or User Mode Linux, vmware, qemu, etc., if you must.
> 3. Seamless integration with rest of site - I still have PHP
> applications, and my resume is still an XSLT application; being able
> to run parts of my site with Lisp without having a crazy URL scheme in
> which all Lisp is relegated to a particular URL namespace
> (http://server/lisp/...) is essential
mod_rewrite is probably the best reason why you want Apache to front
your web applications. You may also want to look into Pound.
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
····@netmemetic.com (Ng Pheng Siong) wrote in message news:<············@reader01.singnet.com.sg>...
> According to Ari Johnson <·········@gmail.com>:
> > 1. Partitioning between projects - with PHP I just write
> > directory-portable code and put each project in its own directory
>
> Each "project" is presumably accessible via a different URL "root" and is
> thus handled by different Lisp code. You can partition your code using Lisp
> "packages". Once loaded, all your code lives in the Lisp process.
That should be sufficient.
> > 2. Partitioning between users - although less important since I will
> > most likely be the only user writing Lisp-powered web pages on my
> > server, it'd be nice to create separate users from my own account and
> > use them to separate projects (this is not essential, just a
> > nice-to-have thing)
>
> The simplest way is to run multiple Lisp processes. FreeBSD jails! FreeBSD
> jails! ;-) Or User Mode Linux, vmware, qemu, etc., if you must.
I used to use FreeBSD, then switched to Debian when I got angry with
the ports system's deteriorating quality control after being a BSD
person for about 5 years. Now I am leasing a FreeBSD server (as they
don't offer Debian and I refuse to touch RedHat), but I don't know
much about FreeBSD jails. I'll look into that, should I actually have
any user besides myself wanting to use Lisp.
> > 3. Seamless integration with rest of site - I still have PHP
> > applications, and my resume is still an XSLT application; being able
> > to run parts of my site with Lisp without having a crazy URL scheme in
> > which all Lisp is relegated to a particular URL namespace
> > (http://server/lisp/...) is essential
>
> mod_rewrite is probably the best reason why you want Apache to front
> your web applications. You may also want to look into Pound.
mod_proxy and mod_rewrite together should be sufficient. It seems
that Apache2 on FreeBSD doesn't give me a way through the ports system
to install mod_proxy, though. Did you have to install it on your own?
I'm not opposed to that, and in fact started out in Unix doing
everything the hard way, but I really prefer package systems that can
upgrade packages for me - I wear enough hats without being a full-time
system administrator.
Right now, my problems are that sldb fails to pop up on my FreeBSD
machine (it works fine on my Arch Linux workstation; same versions of
emacs, sbcl, and slime; the FreeBSD machine also isn't doing
asdf-install properly) and that I get compile errors when I
asdf-install the aserve system. It's hard to get started when you
can't get the infrastructure installed. :(
According to Ari Johnson <·········@gmail.com>:
> I used to use FreeBSD, then switched to Debian when I got angry with
> the ports system's deteriorating quality control after being a BSD
> person for about 5 years.
I've found that, whenever I run into a problem with a port, blowing away
the files/ subdirectory of patches for that port, then re-cvsupping, is
sufficient to get the port to work.
> Now I am leasing a FreeBSD server (as they don't offer Debian and I
> refuse to touch RedHat), but I don't know much about FreeBSD jails. I'll
> look into that, should I actually have any user besides myself wanting to
> use Lisp.
If you're leasing a real, physical boxen, you can play with jails on it. If
you're getting a "virtual server", then you are most likely getting a jail.
> mod_proxy and mod_rewrite together should be sufficient. It seems
> that Apache2 on FreeBSD doesn't give me a way through the ports system
> to install mod_proxy, though. Did you have to install it on your own?
I was a multi-platform sysadmin for many years so I'm accustomed to
arranging stuff my way. Right now, for software that is strategic to my
purposes, I build and install myself. For other software, I use the ports.
One exception is CMUCL, because installing the binary from ports is much
easier than building it from source. ;-)
Apache I build install myself, because every now and then I play with stuff
like mod_lisp, mod_python, etc., which I do in a jail.
> Right now, my problems are that sldb fails to pop up on my FreeBSD
> machine (it works fine on my Arch Linux workstation; same versions of
> emacs, sbcl, and slime; the FreeBSD machine also isn't doing
> asdf-install properly) and that I get compile errors when I
> asdf-install the aserve system. It's hard to get started when you
> can't get the infrastructure installed. :(
When I started out with Lisp, the packaging was similarly mysterious to me.
I put on my sysadmin hat and evolved a simple system to manage Lisp
software. E.g., my .cmucl-init.lisp has this:
(defun go-aserve ()
(load "/usr/local/pkg/lisp/portableaserve/acl-compat/acl-compat.asd")
(asdf:oos 'asdf:load-op :acl-compat)
(load "/usr/local/pkg/lisp/portableaserve/aserve/htmlgen/htmlgen.asd")
(asdf:oos 'asdf:load-op :htmlgen)
(load "/usr/local/pkg/lisp/portableaserve/aserve/aserve.asd")
(asdf:oos 'asdf:load-op :aserve)
(load "/usr/local/pkg/lisp/portableaserve/aserve/webactions/webactions.asd")
(asdf:oos 'asdf:load-op :webactions))
;(go-aserve)
(defun go-araneida ()
(push "/usr/local/pkg/lisp/araneida/" asdf:*central-registry*)
(asdf:oos 'asdf:load-op :araneida))
;(go-araneida)
(I put add-on software under /usr/local/pkg, e.g., /usr/local/pkg/lisp,
/usr/local/pkg/prolog, etc. so I can just make tarballs and deploy to other
machines easily.)
The important thing to me is to write Lisp software, not play sysadmin to a
Lisp software infrastructure, so I didn't spend time trying to figure out
asdf-install. Indeed, I've never looked at it. Maybe the above defuns might
work for you too.
Cheers.
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
> 4. Good template language - I've seen some pretty bad template
> languages; also, writing templates in HTML and then inserting active
> template code makes more sense to me, as it is far easier to prototype
> HTML with a static file than it is if you have to recompile and reload
> after every change before you can see the changes
Try http://www.sanctuary.org/~azimuth/code/btl.html - it might be
about what you're looking for.
This is copied from an e-mail i sent to the OP, i thought it should be
archived. i wish there was a post like this when i was google hunting
for 'lisp template languages' :).
---------------------------------------------------------------------
There are many options when it comes to template toolkits. It's trivial
to implement your own as well. I've written many template languages over
the years, but the available solutions in all languages are usually
quite sufficient. It was partially my experience in writing template
languages that prompted my move to lisp, mixed with my desire to never
have to do it again.
Here are a few that i've tried, and my observations and opinions.
cl-emb:
http://common-lisp.net/project/cl-emb/examples.html
Similar to smarty or HTML::Mason. This is what i think of when i want a
template toolkit. Like most lisp template engines, can embed either lisp
forms or a mini-language.
HTML-TEMPLATE:
http://www.cliki.net/HTML-TEMPLATE
Similar to the perl module of the same name. Uses tags embedded in HTML
comments (although is not HTML specific). Its available with debian
(which is a plus), so it was the first one i tried.
TAL: (part of yaclml)
http://common-lisp.net/project/bese/yaclml.html
TAL was created as part of the zope project, and has been implemented is
serveral language. it uses XML attributes to manipulate the templates.
the advantage of this approach is that your templates are valid XML, and
can be used by your designers using their tools. I've been using TAL
lately as part of UncommonWeb, a Web application framework. It's really
easy to extend, and your extensions can manipulate the XML source of the
template, which allows for some really neat solutions to common web
programming problems.
LSP:
http://lemonodor.com/archives/000128.html
I've never used this, as it's a jsp/php type approach, which i
personally disdain. But, it offers a great example of how to get started
writing your own template language in lisp.
I personally use cl-emb, but i have been playing with TAL a lot lately.
Whichever you choose depends mostly on your needs.
CLP
http://opensource.franz.com/aserve/aserve-dist/webactions/doc/webactions.html
There is also CLP, which comes as part of allegros webactions package.
I've not had much experience with this either, but it's another option.
Daniel Lowe wrote:
>> 4. Good template language - I've seen some pretty bad template
>>languages; also, writing templates in HTML and then inserting active
>>template code makes more sense to me, as it is far easier to prototype
>>HTML with a static file than it is if you have to recompile and reload
>>after every change before you can see the changes
>
>
> Try http://www.sanctuary.org/~azimuth/code/btl.html - it might be
> about what you're looking for.
I've never tried BTL either, but it looks interesting, and just as
capable as any Template Toolkit.
Happy Hacking,
drewc
When reading this thread I saw some people mentioning (or so it seemed) as
desire to use Apache2 with mod_lisp.
Someone offered FastCGI as a solution.
I do not currently know Lisp. But a possible solution would be to write the Lisp
server portion for SCGI.
"""
SCGI: A Simple Common Gateway Interface alternative
Neil Schemenauer <···@python.ca>
2001/10/30
1. Introduction
The SCGI protocol is a replacement for the Common Gateway Interface
(CGI) protocol. It is a standard for applications to interface with
HTTP servers. It is similar to FastCGI but is designed to be easier
to implement.
"""
http://www.mems-exchange.org/software/scgi/
May be the easiest way to get Lisp behind Apache2. I don't know.
This is used to power Quixote a Python web app behind Apache 1 or 2.
They get pretty good performance with it.
HTH.
Jimmie Houchin