Hi!
I've finally found some time to incorporate Bob's changes, test them and document them. I've also changed the logging API and re-factored some of the code. I'm sure I broke something in the process so please test... :)
Specifically, I tried to explain in the documentation how TBNL talks with the different back-ends. I also changed the test setup so that it now hopefully adapts to all three back-ends and gives new users a chance to understand how TBNL works.
While testing the "stand-alone" version I had some problems with MS Internet Explorer but I /think/ I've nailed them down now.
Note that some of the changes in 0.5.0 might break API compatibility with earlier versions so be careful if you use this release for an existing deployment of TBNL and resort to the docs if in doubt.
Special thanks to Bob Hutchison who made this all possible!
Download: http://weitz.de/files/tbnl.tar.gz.
Have fun, Edi.
On 2005-03-17 02:17:19, Edi Weitz wrote:
Specifically, I tried to explain in the documentation how TBNL talks with the different back-ends. I also changed the test setup so that it now hopefully adapts to all three back-ends and gives new users a chance to understand how TBNL works.
I was just wondering ... isn't now every proxy feature in every webserver some kind of mod_lisp?
What are the pros and cons of mod_lisp vs. proxy (+ TBNL stand-alone)?
On 2005-08-16 22:24:56, Stefan Scholl wrote:
I was just wondering ... isn't now every proxy feature in every webserver some kind of mod_lisp?
What are the pros and cons of mod_lisp vs. proxy (+ TBNL stand-alone)?
Forget it. mod_lisp is much, much faster. 3 to 4 times faster in a local test with ApacheBench against Apache 1.3 + mod_lisp + TBNL, lighttpd + mod_proxy + TBNL, and TBNL stand-alone.
Apache 1.3 + mod_lisp + TBNL was always faster.
The mod_lisp request data can be parsed without any regular expressions. Maybe that's enough to cause that difference in speed.
I think I'll try to remove all calls to CL-PPCRE:SPLIT and test it again (later).
Hi Stefan,
On Aug 17, 2005, at 3:39 AM, Stefan Scholl wrote:
On 2005-08-16 22:24:56, Stefan Scholl wrote:
I was just wondering ... isn't now every proxy feature in every webserver some kind of mod_lisp?
What are the pros and cons of mod_lisp vs. proxy (+ TBNL stand-alone)?
Forget it. mod_lisp is much, much faster. 3 to 4 times faster in a local test with ApacheBench against Apache 1.3 + mod_lisp + TBNL, lighttpd + mod_proxy + TBNL, and TBNL stand-alone.
Apache 1.3 + mod_lisp + TBNL was always faster.
Really? That's very interesting. What lisp implementation are you using? I use Lispworks, and in my tests (on OS X and linux, I don't have a license for windows), Apache+mod_lisp+TBNL was second and TBNL standalone the fastest by just a bit better than a factor of *two* -- except on OS X, where there is a bug that I cannot identify that causes a lot of memory to be permanently allocated and -- depending on the concurrency count -- lispworks either slowly grids to a halt or falls over dead almost instantly. I think Araneida+TBNL was third, but it is really hard to say (and I think I can improve this, I don't quite understand why it isn't closer to the standalone TBNL). And the apache+proxy+?+TBNL was slowest.
However, even though using a proxy is slowest, for me, I can get my ISP to go along with this whereas they won't consider mod_lisp (or the mod_jk? java modules either, so it isn't a lisp problem). I need my ISP to go along with me only if I need to use port 80. Any other port I use standalone TBNL on linux or Araneida+TBNL on OS X -- I've had an application up and running now on linux (standalone TBNL) for just over two months now I think.
And for what its worth, these are all *way* faster than Java.
I have not tried lighttpd.
I wonder what's causing the timing differences? I'm testing against that application I mentioned and there are some pretty significant chunks of HTML generated (sometimes 100's of kb) and sometimes a non- trivial CPU requirement.
Cheers, Bob
The mod_lisp request data can be parsed without any regular expressions. Maybe that's enough to cause that difference in speed.
I think I'll try to remove all calls to CL-PPCRE:SPLIT and test it again (later).
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/ Raconteur -- http://www.raconteur.info/
Hi Bob and list!
On 2005-08-17 07:52:57, Bob Hutchison wrote:
On Aug 17, 2005, at 3:39 AM, Stefan Scholl wrote:
Forget it. mod_lisp is much, much faster. 3 to 4 times faster in a local test with ApacheBench against Apache 1.3 + mod_lisp + TBNL, lighttpd + mod_proxy + TBNL, and TBNL stand-alone.
Apache 1.3 + mod_lisp + TBNL was always faster.
Really? That's very interesting. What lisp implementation are you using? I use Lispworks, and in my tests (on OS X and linux, I don't have a license for windows), Apache+mod_lisp+TBNL was second and TBNL standalone the fastest by just a bit better than a factor of *two*
CMUCL 19a on a Pentium III 650 MHz (2 CPUs), 512 MiB RAM. Linux 2.6.x (Gentoo)
Tested with CL-WIKI serving a little 30 KiB file.
ab -n 100 -c 5 ...
(localhost)
Regards, Stefan
----- Original Message ----- From: "Stefan Scholl" stesch@no-spoon.de To: tbnl-devel@common-lisp.net Sent: Wednesday, August 17, 2005 9:39 AM Subject: Re: [tbnl-devel] New version 0.5.0 / Multiple back-ends
On 2005-08-16 22:24:56, Stefan Scholl wrote:
I was just wondering ... isn't now every proxy feature in every webserver some kind of mod_lisp?
What are the pros and cons of mod_lisp vs. proxy (+ TBNL stand-alone)?
Forget it. mod_lisp is much, much faster. 3 to 4 times faster in a local test with ApacheBench against Apache 1.3 + mod_lisp + TBNL, lighttpd + mod_proxy + TBNL, and TBNL stand-alone.
Apache 1.3 + mod_lisp + TBNL was always faster.
The mod_lisp request data can be parsed without any regular expressions. Maybe that's enough to cause that difference in speed.
They are several reasons why mod_lisp is faster than mod_proxy and generally than a standalone lisp server in real world applications:
The most important point for the speed is that mod_lisp keeps the Apache => Lisp socket open.
Most Lisp implementation don't use native threads or don't allow more than one thread to be active. So using Apache as a front-end is more efficient if there are more than one processor (or an HT one)
Apache can serve the static content thus leaving more Lisp CPU time to process application logic.
BTW 14.6 request/s is very slow. Are you sure you keep the Apache/Lisp socket open ? FYI I get 440 req/s max on a dual Xeon 2GHz for a fixed reply.
Marc
-
Bob Hutchison -
Edi Weitz -
Marc Battyani -
Stefan Scholl