[hunchentoot-devel] Hunchentoot behind apache http proxy (performance)
The moment came when I had to move all of my site from being partially static http web pages to pages generated (or served from cached files) by Hunchentoot. The overall performance noticeably degraded in terms of response time. Even in cases when HT does nothing but serves a static file from its cache the response time increased from 0.3 sec to 1.5 sec (tested with httperf). I am running Apache 2 on Ubuntu (everything latest) with sbcl 1.0.18. I understand that when ht running behind the proxy the response time should increase. I wonder what can I do to optimize. Is it time to run HT as a standalone server? I still have a bunch of pages that I need to serve statically and lately my sbcl had problems with GC so it crashes time after time from heap exhaustion, so I am a bit uncomfortable to switch completely to Hunchentoot. I wonder how do you guys solve those problems? Thank you, Andrew
I wrote a blog entry about how we try to reduce the load on our (Hunchentoot) backend and whet we want in a front end. See http://netzhansa.blogspot.com/2008/07/building-load-resilient-web-servers.ht... - Comments gladly discussed here, too. -Hans On Fri, Jul 25, 2008 at 17:02, Andrei Stebakov <lispercat@gmail.com> wrote:
The moment came when I had to move all of my site from being partially static http web pages to pages generated (or served from cached files) by Hunchentoot. The overall performance noticeably degraded in terms of response time. Even in cases when HT does nothing but serves a static file from its cache the response time increased from 0.3 sec to 1.5 sec (tested with httperf). I am running Apache 2 on Ubuntu (everything latest) with sbcl 1.0.18. I understand that when ht running behind the proxy the response time should increase. I wonder what can I do to optimize. Is it time to run HT as a standalone server? I still have a bunch of pages that I need to serve statically and lately my sbcl had problems with GC so it crashes time after time from heap exhaustion, so I am a bit uncomfortable to switch completely to Hunchentoot. I wonder how do you guys solve those problems?
Thank you, Andrew
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
I've heard nice things about nginx (reverse proxy as well), I gave it a try but it had different rewrite rules from Apache and doesn't have log rotation mechanism. I am back to Apache as I didn't have time to play with it longer. Back to Hunchentoot. I couldn't find how "Accept-Encoding: gzip, deflate" request is handled? When the client sends this header, HT doesn't compress the content responding with "Content-Encoding: gzip", is there a way to enable it to compress some text or CSS content? On Fri, Jul 25, 2008 at 12:43 PM, Hans Hübner <hans@huebner.org> wrote:
I wrote a blog entry about how we try to reduce the load on our (Hunchentoot) backend and whet we want in a front end. See
http://netzhansa.blogspot.com/2008/07/building-load-resilient-web-servers.ht... - Comments gladly discussed here, too.
-Hans
The moment came when I had to move all of my site from being partially static http web pages to pages generated (or served from cached files) by Hunchentoot. The overall performance noticeably degraded in terms of response time. Even in cases when HT does nothing but serves a static file from its cache the response time increased from 0.3 sec to 1.5 sec (tested with httperf). I am running Apache 2 on Ubuntu (everything latest) with sbcl 1.0.18. I understand that when ht running behind the proxy the response time should increase. I wonder what can I do to optimize. Is it time to run HT as a standalone server? I still have a bunch of
On Fri, Jul 25, 2008 at 17:02, Andrei Stebakov <lispercat@gmail.com> wrote: pages
that I need to serve statically and lately my sbcl had problems with GC so it crashes time after time from heap exhaustion, so I am a bit uncomfortable to switch completely to Hunchentoot. I wonder how do you guys solve those problems?
Thank you, Andrew
_______________________________________________ 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
On Fri, Jul 25, 2008 at 19:39, Andrei Stebakov <lispercat@gmail.com> wrote:
I've heard nice things about nginx (reverse proxy as well), I gave it a try but it had different rewrite rules from Apache and doesn't have log rotation mechanism.
The most important drawback of nginx is that it does not do any caching, so it really can';t help with the performance improvement strategies that I'd be interested in. In general, I try to set up things in a manner that only those requests hit my Hunchentoot backend that really create dynamic content which is different from other requests. Everything else is handled by the frontend and served from its cache.
Back to Hunchentoot. I couldn't find how "Accept-Encoding: gzip, deflate" request is handled? When the client sends this header, HT doesn't compress the content responding with "Content-Encoding: gzip", is there a way to enable it to compress some text or CSS content?
No. -Hans
participants (2)
-
Andrei Stebakov -
Hans Hübner