[hunchentoot-devel] Different speed loading images from static apache and hunchentoot handler
I got a folder on my linux box that contains about 240 images of font preview generated from cl-gd (Thanks, Edi!). When I show them from static apache handler it takes approximately 30 seconds. Same thing from hunchentoot static handler (create-folder-dispatcher-and-handler) takes about 50 seconds. I understand it's not a big deal, but still I'd like to know what might get in the way. I use hunchentoot behind mod-proxy. Here are links (first is static apache, second is hunchentoot): http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
Thank you, Andrew
On Fri, 30 Mar 2007 16:24:43 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
I got a folder on my linux box that contains about 240 images of font preview generated from cl-gd (Thanks, Edi!).
Nice... :)
When I show them from static apache handler it takes approximately 30 seconds. Same thing from hunchentoot static handler (create-folder-dispatcher-and-handler) takes about 50 seconds. I understand it's not a big deal, but still I'd like to know what might get in the way. I use hunchentoot behind mod-proxy. Here are links (first is static apache, second is hunchentoot): http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
I guess it's the thread switching that takes the additional time.
From tests on my Linux box (using ApacheBench and a localhost
connection) my impression was that serving static files with Hunchentoot wasn't slower than with Apache. On your website it looks like on the Apache page always two or three pictures are downloaded concurrently while on the Hunchentoot version they come one after another. It seems you're using CMUCL which uses "green threads," so that would explain it.
If you want to pursue this further, I'd recommend testing with ApacheBench and different settings for its "-c" parameter.
Of course, you could/should also try without mod_proxy. And with mod_lisp - that takes a bit of the concurrency off of CMUCL's shoulders.
Edi, do you think SBCL would change the picture? I am not sure but I heard it uses native threads. I'll try ApacheBench. Do you think switching to Apache 2 would help here?
Thank you, Andrew
On 3/30/07, Edi Weitz edi@agharta.de wrote:
On Fri, 30 Mar 2007 16:24:43 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
I got a folder on my linux box that contains about 240 images of font preview generated from cl-gd (Thanks, Edi!).
Nice... :)
When I show them from static apache handler it takes approximately 30 seconds. Same thing from hunchentoot static handler (create-folder-dispatcher-and-handler) takes about 50 seconds. I
understand
it's not a big deal, but still I'd like to know what might get in the
way. I
use hunchentoot behind mod-proxy. Here are links (first is static apache, second is hunchentoot): http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
I guess it's the thread switching that takes the additional time.
From tests on my Linux box (using ApacheBench and a localhost
connection) my impression was that serving static files with Hunchentoot wasn't slower than with Apache. On your website it looks like on the Apache page always two or three pictures are downloaded concurrently while on the Hunchentoot version they come one after another. It seems you're using CMUCL which uses "green threads," so that would explain it.
If you want to pursue this further, I'd recommend testing with ApacheBench and different settings for its "-c" parameter.
Of course, you could/should also try without mod_proxy. And with mod_lisp - that takes a bit of the concurrency off of CMUCL's shoulders. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Fri, 30 Mar 2007 17:10:18 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
Edi, do you think SBCL would change the picture?
Dunno, you'll have to try.
I am not sure but I heard it uses native threads.
It does. On certain platforms. Linux/x86 for example.
I'll try ApacheBench. Do you think switching to Apache 2 would help here?
Speed-wise? I doubt it.
On Fri, 2007-03-30 at 22:57 +0200, Edi Weitz wrote:
On Fri, 30 Mar 2007 16:24:43 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
I got a folder on my linux box that contains about 240 images of font preview generated from cl-gd (Thanks, Edi!).
Nice... :)
When I show them from static apache handler it takes approximately 30 seconds. Same thing from hunchentoot static handler (create-folder-dispatcher-and-handler) takes about 50 seconds. I understand it's not a big deal, but still I'd like to know what might get in the way. I use hunchentoot behind mod-proxy. Here are links (first is static apache, second is hunchentoot): http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
I guess it's the thread switching that takes the additional time.
From tests on my Linux box (using ApacheBench and a localhost
connection) my impression was that serving static files with Hunchentoot wasn't slower than with Apache.
Just as a side note: unless we talk about low traffic/low volume serving i'd expect Apache to be significantly faster than Lisp solutions - once Apache detects that a request serves static files it uses 'sendfile' to shuffle the file content over the network (thus avoiding to read any data at all into userspace only to write it back to kernel space. That does save a lot of time (and context switches)). That's nothing to be ashamed of as a Lisper - Lisp shines when it comes to content generation ;-)
Cheers, Ralf Mattes
Ralf, it was a different issue specific to CMUCL. Performance was just horrible, but it was fixed by calling (mp::startup-idle-and-top-level-loops). SBCL works fine out of the box (there are other issues but not the speed).
Andrew On 4/6/07, Ralf Mattes rm@seid-online.de wrote:
On Fri, 2007-03-30 at 22:57 +0200, Edi Weitz wrote:
On Fri, 30 Mar 2007 16:24:43 -0400, "Andrei Stebakov" <
lispercat@gmail.com> wrote:
I got a folder on my linux box that contains about 240 images of font preview generated from cl-gd (Thanks, Edi!).
Nice... :)
When I show them from static apache handler it takes approximately 30 seconds. Same thing from hunchentoot static handler (create-folder-dispatcher-and-handler) takes about 50 seconds. I
understand
it's not a big deal, but still I'd like to know what might get in the
way. I
use hunchentoot behind mod-proxy. Here are links (first is static apache, second is hunchentoot): http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
I guess it's the thread switching that takes the additional time.
From tests on my Linux box (using ApacheBench and a localhost
connection) my impression was that serving static files with Hunchentoot wasn't slower than with Apache.
Just as a side note: unless we talk about low traffic/low volume serving i'd expect Apache to be significantly faster than Lisp solutions - once Apache detects that a request serves static files it uses 'sendfile' to shuffle the file content over the network (thus avoiding to read any data at all into userspace only to write it back to kernel space. That does save a lot of time (and context switches)). That's nothing to be ashamed of as a Lisper - Lisp shines when it comes to content generation ;-)
Cheers, Ralf Mattes
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On 30-Mar-07, at 4:24 PM, Andrei Stebakov wrote:
I got a folder on my linux box that contains about 240 images of font preview generated from cl-gd (Thanks, Edi!). When I show them from static apache handler it takes approximately 30 seconds. Same thing from hunchentoot static handler (create-folder-dispatcher-and-handler) takes about 50 seconds. I understand it's not a big deal, but still I'd like to know what might get in the way. I use hunchentoot behind mod-proxy.
Have you tried going straight at the hunchentoot server? This as made some difference to my stuff in the past. Might give you a better idea where the problem is.
Cheers, Bob
Here are links (first is static apache, second is hunchentoot): http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
Thank you, Andrew _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
---- Bob Hutchison -- tumblelog at <http:// www.recursive.ca/so/> Recursive Design Inc. -- http://www.recursive.ca/ xampl for Ruby -- http://rubyforge.org/projects/xampl/
Hi Bob,
Could you advise how would I "go straight at the hunchentoot server"? Also I have a feeling that the more I call the images from the server the slower it gets. I even removed (no-chache) option from the page generation so I thought that having images in caches would speed it up. In this context I think what Edi says about Hunchentoot switching contexts with Apache while page generation makes sense. My server is PIII 600 MHz, maybe it's time to upgrade it.
Thank you, Andrew
On 4/3/07, Bob Hutchison hutch@recursive.ca wrote:
On 30-Mar-07, at 4:24 PM, Andrei Stebakov wrote:
I got a folder on my linux box that contains about 240 images of font preview generated from cl-gd (Thanks, Edi!). When I show them from static apache handler it takes approximately 30 seconds. Same thing from hunchentoot static handler (create-folder-dispatcher-and-handler) takes about 50 seconds. I understand it's not a big deal, but still I'd like to know what might get in the way. I use hunchentoot behind mod-proxy.
Have you tried going straight at the hunchentoot server? This as made some difference to my stuff in the past. Might give you a better idea where the problem is.
Cheers, Bob
Here are links (first is static apache, second is hunchentoot): http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
Thank you, Andrew _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Bob Hutchison -- tumblelog at http:// www.recursive.ca/so/ Recursive Design Inc. -- http://www.recursive.ca/ xampl for Ruby -- http://rubyforge.org/projects/xampl/
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On 3-Apr-07, at 9:31 AM, Andrei Stebakov wrote:
Hi Bob,
Could you advise how would I "go straight at the hunchentoot server"?
You'll have something like:
ProxyPass /cphandler/ http://localhost:4321/cphandler/ ProxyPassReverse /cphandler/ http://localhost:4321/cphandler/
in your httpd config file.
Just point your browser at whatever corresponds to http://localhost: 4321/cphandler/
If you are running on a different machine than the server you'll have to temporarily open whatever port you are using (and based on the description of your server below, I'm guessing you *are* running on a different machine (if you aren't then it is definitely time for an upgrade :-))
Also I have a feeling that the more I call the images from the server the slower it gets.
I pretty sure I've not seen this before.
I even removed (no-chache) option from the page generation so I thought that having images in caches would speed it up. In this context I think what Edi says about Hunchentoot switching contexts with Apache while page generation makes sense. My server is PIII 600 MHz, maybe it's time to upgrade it.
it should still be sufficient for a website.
Cheers, Bob
Thank you, Andrew
On 4/3/07, Bob Hutchison hutch@recursive.ca wrote:
On 30-Mar-07, at 4:24 PM, Andrei Stebakov wrote:
I got a folder on my linux box that contains about 240 images of
font
preview generated from cl-gd (Thanks, Edi!). When I show them from static apache handler it takes
approximately 30
seconds. Same thing from hunchentoot static handler (create-folder-dispatcher-and-handler) takes about 50 seconds. I understand it's not a big deal, but still I'd like to know what might get in the way. I use hunchentoot behind mod-proxy.
Have you tried going straight at the hunchentoot server? This as made some difference to my stuff in the past. Might give you a better idea where the problem is.
Cheers, Bob
Here are links (first is static apache, second is hunchentoot): http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
Thank you, Andrew _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Bob Hutchison -- tumblelog at http:// www.recursive.ca/so/ Recursive Design Inc. -- http://www.recursive.ca/ xampl for Ruby -- <http://rubyforge.org/projects/ xampl/>
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
---- Bob Hutchison -- tumblelog at <http:// www.recursive.ca/so/> Recursive Design Inc. -- http://www.recursive.ca/ xampl for Ruby -- http://rubyforge.org/projects/xampl/
On 3-Apr-07, at 10:56 AM, Bob Hutchison wrote:
On 3-Apr-07, at 9:31 AM, Andrei Stebakov wrote:
Hi Bob,
Could you advise how would I "go straight at the hunchentoot server"?
You'll have something like:
ProxyPass /cphandler/ http://localhost:4321/cphandler/ ProxyPassReverse /cphandler/ http://localhost:4321/cphandler/in your httpd config file.
Just point your browser at whatever corresponds to http://localhost: 4321/cphandler/
BTW, if this does turn out to be faster, you might consider running it without apache at all. I've been doing this for a couple of years now (starting with TBNL) though my site is entirely dynamic. Edi has been cautious about recommending this, which I understand, but...
Cheers, Bob
If you are running on a different machine than the server you'll have to temporarily open whatever port you are using (and based on the description of your server below, I'm guessing you *are* running on a different machine (if you aren't then it is definitely time for an upgrade :-))
Also I have a feeling that the more I call the images from the server the slower it gets.
I pretty sure I've not seen this before.
I even removed (no-chache) option from the page generation so I thought that having images in caches would speed it up. In this context I think what Edi says about Hunchentoot switching contexts with Apache while page generation makes sense. My server is PIII 600 MHz, maybe it's time to upgrade it.
it should still be sufficient for a website.
Cheers, Bob
Thank you, Andrew
On 4/3/07, Bob Hutchison hutch@recursive.ca wrote:
On 30-Mar-07, at 4:24 PM, Andrei Stebakov wrote:
I got a folder on my linux box that contains about 240 images
of font
preview generated from cl-gd (Thanks, Edi!). When I show them from static apache handler it takes
approximately 30
seconds. Same thing from hunchentoot static handler (create-folder-dispatcher-and-handler) takes about 50 seconds. I understand it's not a big deal, but still I'd like to know what might get in the way. I use hunchentoot behind mod-proxy.
Have you tried going straight at the hunchentoot server? This as made some difference to my stuff in the past. Might give you a better idea where the problem is.
Cheers, Bob
Here are links (first is static apache, second is hunchentoot): http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
Thank you, Andrew _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Bob Hutchison -- tumblelog at http:// www.recursive.ca/so/ Recursive Design Inc. -- http://www.recursive.ca/ xampl for Ruby -- <http://rubyforge.org/projects/ xampl/>
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Bob Hutchison -- tumblelog at <http:// www.recursive.ca/so/> Recursive Design Inc. -- http://www.recursive.ca/ xampl for Ruby -- <http://rubyforge.org/projects/ xampl/>
---- Bob Hutchison -- tumblelog at <http:// www.recursive.ca/so/> Recursive Design Inc. -- http://www.recursive.ca/ xampl for Ruby -- http://rubyforge.org/projects/xampl/
Bob, even if I can see it from browser the way you described, how would I benefit from it if I need to handle all my images with create-folder-dispatcher-and-handler?
Thank you, Andrew
On 4/3/07, Bob Hutchison hutch@recursive.ca wrote:
On 3-Apr-07, at 10:56 AM, Bob Hutchison wrote:
On 3-Apr-07, at 9:31 AM, Andrei Stebakov wrote:
Hi Bob,
Could you advise how would I "go straight at the hunchentoot server"?
You'll have something like:
ProxyPass /cphandler/ http://localhost:4321/cphandler/ ProxyPassReverse /cphandler/ http://localhost:4321/cphandler/in your httpd config file.
Just point your browser at whatever corresponds to http://localhost: 4321/cphandler/
BTW, if this does turn out to be faster, you might consider running it without apache at all. I've been doing this for a couple of years now (starting with TBNL) though my site is entirely dynamic. Edi has been cautious about recommending this, which I understand, but...
Cheers, Bob
If you are running on a different machine than the server you'll have to temporarily open whatever port you are using (and based on the description of your server below, I'm guessing you *are* running on a different machine (if you aren't then it is definitely time for an upgrade :-))
Also I have a feeling that the more I call the images from the server the slower it gets.
I pretty sure I've not seen this before.
I even removed (no-chache) option from the page generation so I thought that having images in caches would speed it up. In this context I think what Edi says about Hunchentoot switching contexts with Apache while page generation makes sense. My server is PIII 600 MHz, maybe it's time to upgrade it.
it should still be sufficient for a website.
Cheers, Bob
Thank you, Andrew
On 4/3/07, Bob Hutchison hutch@recursive.ca wrote:
On 30-Mar-07, at 4:24 PM, Andrei Stebakov wrote:
I got a folder on my linux box that contains about 240 images
of font
preview generated from cl-gd (Thanks, Edi!). When I show them from static apache handler it takes
approximately 30
seconds. Same thing from hunchentoot static handler (create-folder-dispatcher-and-handler) takes about 50 seconds. I understand it's not a big deal, but still I'd like to know what might get in the way. I use hunchentoot behind mod-proxy.
Have you tried going straight at the hunchentoot server? This as made some difference to my stuff in the past. Might give you a better idea where the problem is.
Cheers, Bob
Here are links (first is static apache, second is hunchentoot): http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
Thank you, Andrew _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Bob Hutchison -- tumblelog at http:// www.recursive.ca/so/ Recursive Design Inc. -- http://www.recursive.ca/ xampl for Ruby -- http://rubyforge.org/projects/ xampl/
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Bob Hutchison -- tumblelog at http:// www.recursive.ca/so/ Recursive Design Inc. -- http://www.recursive.ca/ xampl for Ruby -- http://rubyforge.org/projects/ xampl/
Bob Hutchison -- tumblelog at http:// www.recursive.ca/so/ Recursive Design Inc. -- http://www.recursive.ca/ xampl for Ruby -- http://rubyforge.org/projects/xampl/
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Guys, I need your help here. The static image loading with create-folder-dispatcher-and-handler is really slow. Here I have just 5 images and Apache loads it almost instantaneously and HT handler takes about 10 sec! I have a page where I have to use CSS and other images and the page loads painfully slow. I thought the reason was that I don't have enougt memory so I started removing packages from my Lisp process (I use CMUCL) but it doesn't help (rebooting the system or Lisp also doesn't help). Could it be any encoding issues I could play with? Here are the links for Apache and Hunchentoot handlers:
http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
Any suggestions are greatly appreciated! Andrew
On 4/3/07, Andrei Stebakov lispercat@gmail.com wrote:
Bob, even if I can see it from browser the way you described, how would I benefit from it if I need to handle all my images with create-folder-dispatcher-and-handler?
Thank you, Andrew
On 4/3/07, Bob Hutchison hutch@recursive.ca wrote:
On 3-Apr-07, at 10:56 AM, Bob Hutchison wrote:
On 3-Apr-07, at 9:31 AM, Andrei Stebakov wrote:
Hi Bob,
Could you advise how would I "go straight at the hunchentoot server"?
You'll have something like:
ProxyPass /cphandler/ http://localhost:4321/cphandler/ ProxyPassReverse /cphandler/ http://localhost:4321/cphandler/in your httpd config file.
Just point your browser at whatever corresponds to http://localhost: 4321/cphandler/
BTW, if this does turn out to be faster, you might consider running it without apache at all. I've been doing this for a couple of years now (starting with TBNL) though my site is entirely dynamic. Edi has been cautious about recommending this, which I understand, but...
Cheers, Bob
If you are running on a different machine than the server you'll have to temporarily open whatever port you are using (and based on the description of your server below, I'm guessing you *are* running on a different machine (if you aren't then it is definitely time for an upgrade :-))
Also I have a feeling that the more I call the images from the server the slower it gets.
I pretty sure I've not seen this before.
I even removed (no-chache) option from the page generation so I thought that having images in caches would speed it up. In this context I think what Edi says about Hunchentoot switching contexts with Apache while page generation makes sense. My server is PIII 600 MHz, maybe it's time to upgrade it.
it should still be sufficient for a website.
Cheers, Bob
Thank you, Andrew
On 4/3/07, Bob Hutchison < hutch@recursive.ca> wrote:
On 30-Mar-07, at 4:24 PM, Andrei Stebakov wrote:
I got a folder on my linux box that contains about 240 images
of font
preview generated from cl-gd (Thanks, Edi!). When I show them from static apache handler it takes
approximately 30
seconds. Same thing from hunchentoot static handler (create-folder-dispatcher-and-handler) takes about 50 seconds. I understand it's not a big deal, but still I'd like to know what might get in the way. I use hunchentoot behind mod-proxy.
Have you tried going straight at the hunchentoot server? This as made some difference to my stuff in the past. Might give you a better idea where the problem is.
Cheers, Bob
Here are links (first is static apache, second is hunchentoot): http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
Thank you, Andrew _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Bob Hutchison -- tumblelog at http:// www.recursive.ca/so/ Recursive Design Inc. -- http://www.recursive.ca/ xampl for Ruby -- < http://rubyforge.org/projects/ xampl/>
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Bob Hutchison -- tumblelog at http:// www.recursive.ca/so/ Recursive Design Inc. -- http://www.recursive.ca/ xampl for Ruby -- http://rubyforge.org/projects/ xampl/
Bob Hutchison -- tumblelog at http:// www.recursive.ca/so/ Recursive Design Inc. -- < http://www.recursive.ca/%3E xampl for Ruby -- http://rubyforge.org/projects/xampl/
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
"Andrei Stebakov" lispercat@gmail.com writes:
http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
I'm late to the thread and maybe this has been answered already, but do you have a short snippet of code that replicates the problem? Can you send it out?
I also am unable to reach the cphandler link above.
Cheers, Chris Dean
On Tue, 3 Apr 2007 18:13:48 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
Guys, I need your help here. The static image loading with create-folder-dispatcher-and-handler is really slow. Here I have just 5 images and Apache loads it almost instantaneously and HT handler takes about 10 sec!
That is certainly much slower than it should be. Have you tried SBCL in the meantime? And are you using the dreaded
MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS
on CMUCL? If not, that'd probably explain your problems.
Here are the links for Apache and Hunchentoot handlers:
http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
The second link doesn't work for me.
Sorry Edi, I am in the process of moving it to SBCL this is why it doesn't work. I don't use MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS explicitly, maybe some other package uses it?
Thank you, Andrew
On 4/3/07, Edi Weitz edi@agharta.de wrote:
On Tue, 3 Apr 2007 18:13:48 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
Guys, I need your help here. The static image loading with create-folder-dispatcher-and-handler is really slow. Here I have just 5 images and Apache loads it almost instantaneously and HT handler takes about 10 sec!
That is certainly much slower than it should be. Have you tried SBCL in the meantime? And are you using the dreaded
MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS
on CMUCL? If not, that'd probably explain your problems.
Here are the links for Apache and Hunchentoot handlers:
http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html
The second link doesn't work for me. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Tue, 3 Apr 2007 19:19:31 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
I don't use MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS explicitly
Use it. Start up a new image, execute the function above and only afterwards start your server. Then report about your results.
That should speed up response times on CMUCL considerably. Search Google for why it does that. And ask on the CMUCL mailing list why it's not enabled by default - I don't know.
Thank you, Edi. After I swiched to SBCL it became fast enough.
Regards, Andrew
On 4/3/07, Edi Weitz edi@agharta.de wrote:
On Tue, 3 Apr 2007 19:19:31 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
I don't use MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS explicitly
Use it. Start up a new image, execute the function above and only afterwards start your server. Then report about your results.
That should speed up response times on CMUCL considerably. Search Google for why it does that. And ask on the CMUCL mailing list why it's not enabled by default - I don't know. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Wed, 4 Apr 2007 00:16:47 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
Thank you, Edi. After I swiched to SBCL it became fast enough.
Good.
It would be useful to know if the CMUCL version was only too slow because you didn't know about MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS. The mailing list is not only there to help you with your specific problems but also as a reference other people can look at if they have similar problems. So, if you could try with this modification and report back to the list as I asked you to do, that'd be a welcome feedback.
Yes, it put it in my .cmucl-init.lisp so it looks like: (require :asdf) (push "/home/andrew/systems/" asdf:*central-registry*) (asdf:oos 'asdf:load-op :swank) (setf swank:*use-dedicated-output-stream* nil) (swank:create-server :port 4005 :dont-close t) (mp::startup-idle-and-top-level-loops)
The only problem I had was that my detachtty command : detachtty --dribble-file $dtty/cmulisp.dribble --log-file \ $dtty/detachtty.log --pid-file $dtty/start.lisp.pid \ $dtty/cmulisp.socket /usr/bin/cmucl -load "/LispWeb/WebHandler.lisp"
It just skipped loading the WebHandler.lisp for some reason. Never mind, I connected to lisp, and started my hunchentoot process manually and after that the whole thing started to work pretty fast (just like with SBCL).
Thank you, Andrew
On 4/4/07, Edi Weitz edi@agharta.de wrote:
On Wed, 4 Apr 2007 00:16:47 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
Thank you, Edi. After I swiched to SBCL it became fast enough.
Good.
It would be useful to know if the CMUCL version was only too slow because you didn't know about MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS. The mailing list is not only there to help you with your specific problems but also as a reference other people can look at if they have similar problems. So, if you could try with this modification and report back to the list as I asked you to do, that'd be a welcome feedback. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Wed, 4 Apr 2007 12:08:57 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
Yes, it put it in my .cmucl-init.lisp so it looks like: (require :asdf) (push "/home/andrew/systems/" asdf:*central-registry*) (asdf:oos 'asdf:load-op :swank) (setf swank:*use-dedicated-output-stream* nil) (swank:create-server :port 4005 :dont-close t) (mp::startup-idle-and-top-level-loops)
The only problem I had was that my detachtty command : detachtty --dribble-file $dtty/cmulisp.dribble --log-file \ $dtty/detachtty.log --pid-file $dtty/start.lisp.pid \ $dtty/cmulisp.socket /usr/bin/cmucl -load "/LispWeb/WebHandler.lisp"
It just skipped loading the WebHandler.lisp for some reason.
Yeah, that is to be expected AFAIK. Strange thing, this STARTUP-... function because it doesn't return.
Never mind, I connected to lisp, and started my hunchentoot process manually and after that the whole thing started to work pretty fast (just like with SBCL).
Good to know, thanks.
-
Andrei Stebakov -
Bob Hutchison -
Chris Dean -
Edi Weitz -
Ralf Mattes