The Common Lisp Directory finally crashed after 823 days.
Marc Battyani
yesterday after 823 days of continuous service.
In these 2 years and 93 days, the same lisp process (LispWorks on Linux
Debian) served 273M requests without any problem. Even the crash was not
really lisp's fault as it was caused by a swap disk problem which caused the
kernel to kill a lot of processes.
During these 823 days, I had to restart Apache every few months and the
firewall router every several days. I also got several electric power
outages but fortunately none longer than the 3h of UPS battery time.
BTW this shows than Debian is also a stable platform for this kind of
applications.
So the CLD lisp process uptime experiment is now over and I will move the
CLD to a better place than a simple server in my basement.
Marc
John Thingstad
<Marc.B...@fractalconcept.com>:
What kind of traffic did you get?
Average load/Max load, number of requests etc?.
What web server did you use?
Just curious.. (I also use LispWorks and am considering it.)
--------------
John Thingstad
Marc Battyani
"John Thingstad" <jpt...@online.no> wrote
> På Sat, 15 Mar 2008 18:05:35 +0100, skrev Marc Battyani
> <Marc.B...@fractalconcept.com>:
>
>> The Common Lisp Directory (http://www.cl-user.net) lisp process crashed
>> yesterday after 823 days of continuous service.
>>
>> In these 2 years and 93 days, the same lisp process (LispWorks on Linux
>> Debian) served 273M requests without any problem. Even the crash was not
>> really lisp's fault as it was caused by a swap disk problem which caused
>> the
>> kernel to kill a lot of processes.
>>
>> During these 823 days, I had to restart Apache every few months and the
>> firewall router every several days. I also got several electric power
>> outages but fortunately none longer than the 3h of UPS battery time.
>> BTW this shows than Debian is also a stable platform for this kind of
>> applications.
>>
>> So the CLD lisp process uptime experiment is now over and I will move the
>> CLD to a better place than a simple server in my basement.
>>
>> Marc
>
> What kind of traffic did you get?
> Average load/Max load, number of requests etc?.
273M requests on 823 days gives 3.84 req/s average so it's not so much.
There are also requests for static content which are handled by apache and
not counted here.
I don't know the max load but on that old server the lisp process can serve
1440 req/s so we are very far from that.
The server load was generally around 0.2~0.5%
> What web server did you use?
Apache + mod_lisp + my webapp framework.
http://www.fractalconcept.com/ilc2002-marc-battyani.pdf
Now it would be called an Ajax framework but I don"t even know if the
acronym already existed in 2000/2002.
> Just curious.. (I also use LispWorks and am considering it.)
This is with LW 4.4.6. When I upgrade to a new server I will switch to LW
5.x
Marc
Chun Tian
wrote:
> "John Thingstad" <jpth...@online.no> wrote
>
>
> > What kind of traffic did you get?
> > Average load/Max load, number of requests etc?.
>
> 273M requests on 823 days gives 3.84 req/s average so it's not so much.
> There are also requests for static content which are handled by apache and
> not counted here.
> I don't know the max load but on that old server the lisp process can serve
> 1440 req/s so we are very far from that.
> The server load was generally around 0.2~0.5%
>
> > What web server did you use?
>
>
> Now it would be called an Ajax framework but I don"t even know if the
> acronym already existed in 2000/2002.
>
> > Just curious.. (I also use LispWorks and am considering it.)
>
> This is with LW 4.4.6. When I upgrade to a new server I will switch to LW
> 5.x
LispWorks 5.x support pthreads on Linux, but all pthreads can only use
ONE cpu at the same time. So if you have only one Lisp process
running, it's better to use a high GHz but multi-core CPU on your
server.
May another way to pass this is let multiple Lisp Web process
listening on different TCP ports, and use Apache's Proxy and Rewrite
URL support, Squid, or even LVS to make a "Virtual" 80 port for all
these processes.
I don't know if LW on win32 can use multiple CPUs.
Regards,
Chun Tian (binghe)
Alex Mizrahi
CT> ONE cpu at the same time. So if you have only one Lisp process
CT> running, it's better to use a high GHz but multi-core CPU on your
CT> server.
what parts of this:
MB>> 273M requests on 823 days gives 3.84 req/s average so it's not so
MB>> much. .. I don't know the max load but on that old
MB>> server the lisp process can serve 1440 req/s so we are very far from
MB>> that. The server load was generally around 0.2~0.5%
you failed to understand?
CT> I don't know if LW on win32 can use multiple CPUs.
i think it's not OS-specific.
Christophe
wrote:
Hello Marc,
How are you ?
Perhaps it's time to use AllegroServe ? :)
Best Regards
Christophe
George Neuner
<bingh...@gmail.com> wrote:
>On 3月16日, 上午6时13分, "Marc Battyani" <Marc.Batty...@fractalconcept.com>
>wrote:
>> "John Thingstad" <jpth...@online.no> wrote
>>
>>
>> > What kind of traffic did you get?
>> > Average load/Max load, number of requests etc?.
>>
>> 273M requests on 823 days gives 3.84 req/s average so it's not so much.
>> There are also requests for static content which are handled by apache and
>> not counted here.
>> I don't know the max load but on that old server the lisp process can serve
>> 1440 req/s so we are very far from that.
>> The server load was generally around 0.2~0.5%
>>
>> > What web server did you use?
>>
>> Apache + mod_lisp + my webapp framework.http://www.fractalconcept.com/ilc2002-marc-battyani.pdf
>>
>> Now it would be called an Ajax framework but I don"t even know if the
>> acronym already existed in 2000/2002.
>>
>> > Just curious.. (I also use LispWorks and am considering it.)
>>
>> This is with LW 4.4.6. When I upgrade to a new server I will switch to LW
>> 5.x
>
>LispWorks 5.x support pthreads on Linux, but all pthreads can only use
>ONE cpu at the same time. So if you have only one Lisp process
>running, it's better to use a high GHz but multi-core CPU on your
>server.
What does that buy you? The OS makes each core appear to be a
separate CPU. A Lisp that's limited to one CPU will only use one
core.
>May another way to pass this is let multiple Lisp Web process
>listening on different TCP ports, and use Apache's Proxy and Rewrite
>URL support, Squid, or even LVS to make a "Virtual" 80 port for all
>these processes.
>
>I don't know if LW on win32 can use multiple CPUs.
>
>Regards,
>
>Chun Tian (binghe)
George
--
for email reply remove "/" from address
lisp linux
> I don't know the max load but on that old server the lisp process can serve
> 1440 req/s so we are very far from that.
of hunchentoot+sbcl, showing its default page on what I assume is
a much more powerful hardware (dual core 64bit amd something with 4gb ram) than
your box.
Can someone else please comment if my number seems way out of line.
Basically all I did was
(require 'hunchentoot)
(hunchentoot:start-server :port 7777)
and point apache bench to http:/localhost:7777/ and try a few tests
>
>> What web server did you use?
>
> Apache + mod_lisp + my webapp framework.
So what is it that makes this so much faster or what is the main bottleneck in hunchentoot+sbcl
> http://www.fractalconcept.com/ilc2002-marc-battyani.pdf
>
> Now it would be called an Ajax framework but I don"t even know if the
I am very much interested in hearing anyone having any insights.
Thanks,
-Antony
Ivan Boldyrev
> Marc Battyani wrote:
>> I don't know the max load but on that old server the lisp process
>> can serve 1440 req/s so we are very far from that.
> That sounds much higher than what i got (< 300) for (a not so
> scientific) test of hunchentoot+sbcl ...
Much of Hunchentoot slowness comes from underlying flexi-streams (but
there is some non-optimal code in Hunchentoot itself too). And don't
forget to get newest version -- a speed was somewhat improved somewhere
before 0.15. I have some private patch that improves speed, but I don't
think it worth patching that needs rewriting.
(Perhaps, on Lispworks Hunchentoot works much faster than on SBCL,
because SBCL's CLOS is slower, and it seems Edi wasn't aware of this
fact when designing flexi-streams.)
======================================================================
Hint: setting
(setf ppcre:*use-bmh-matchers* nil)
before calling any hunchentoot:create-regex-dispatcher reduces memory
footprint that also may give you some speed (but very little, perhaps).
======================================================================
--
Ivan Boldyrev
Sorry my terrible English, my native language is Lisp!
attila....@gmail.com
> because SBCL's CLOS is slower, and it seems Edi wasn't aware of this
fyi, i've seens some random benchmarks and it wasn't the case in them
at all. both entire CLOS and generic methods particularly.
- attila