Rolf Bode-Meyer | 1 Aug 18:31 2006
Picon

I thought lighttpd is fast

Sorry, no rant intended, but after looking at
http://litespeedtech.com/library/benchmarks/benchmark_r3/ and
http://litespeedtech.com/library/benchmarks/benchmark_r2/, I'm
shocked.

From these benchmarks, not only that lighttpd is even slower than
Apache or thttpd, but it's up to six times slower than LiteSpeed.

It looks lighttpd isn't as good as it could and has a huge problem
with Keep Alive? And that all when delivering simple static files. Is
the bottleneck in the code known and located?

Regards,
Rolf

Marcus Rueckert | 1 Aug 22:26 2006
Picon

Re: I thought lighttpd is fast

On 2006-08-01 18:31:26 +0200, Rolf Bode-Meyer wrote:
> Sorry, no rant intended, but after looking at
> http://litespeedtech.com/library/benchmarks/benchmark_r3/ and
> http://litespeedtech.com/library/benchmarks/benchmark_r2/, I'm
> shocked.
> 
> From these benchmarks, not only that lighttpd is even slower than
> Apache or thttpd, but it's up to six times slower than LiteSpeed.
> 
> It looks lighttpd isn't as good as it could and has a huge problem
> with Keep Alive? And that all when delivering simple static files. Is
> the bottleneck in the code known and located?

run your own benchmark and see if it is really the case.

darix

Ilya A. Volynets-Evenbakh | 1 Aug 22:36 2006

Re: I thought lighttpd is fast

Also, with SMP system, make sure to configure
ligttpd to run multiple listeners.

Marcus Rueckert wrote:
> On 2006-08-01 18:31:26 +0200, Rolf Bode-Meyer wrote:
>   
>> Sorry, no rant intended, but after looking at
>> http://litespeedtech.com/library/benchmarks/benchmark_r3/ and
>> http://litespeedtech.com/library/benchmarks/benchmark_r2/, I'm
>> shocked.
>>
>> From these benchmarks, not only that lighttpd is even slower than
>> Apache or thttpd, but it's up to six times slower than LiteSpeed.
>>
>> It looks lighttpd isn't as good as it could and has a huge problem
>> with Keep Alive? And that all when delivering simple static files. Is
>> the bottleneck in the code known and located?
>>     
>
> run your own benchmark and see if it is really the case.
>
> darix
>
>   

--

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com

(Continue reading)

Nathan Seven | 1 Aug 22:38 2006

Re: I thought lighttpd is fast

Yeah- I took a brief look at it, and there are any number of things  
that could be going on.
I wouldn't put too much faith in this benchmark-
(nothing against lightspeed at all)
Do your own, for your own application- (note things like memory usage  
and cpu time as well)
Testing such a small file is nowhere near a typical web-delivery  
situation at all btw :)

--
"Jupiter accepts your offer..."
AIM:IMFDUP

On Aug 1, 2006, at 1:26 PM, Marcus Rueckert wrote:

> On 2006-08-01 18:31:26 +0200, Rolf Bode-Meyer wrote:
>> Sorry, no rant intended, but after looking at
>> http://litespeedtech.com/library/benchmarks/benchmark_r3/ and
>> http://litespeedtech.com/library/benchmarks/benchmark_r2/, I'm
>> shocked.
>>
>> From these benchmarks, not only that lighttpd is even slower than
>> Apache or thttpd, but it's up to six times slower than LiteSpeed.
>>
>> It looks lighttpd isn't as good as it could and has a huge problem
>> with Keep Alive? And that all when delivering simple static files. Is
>> the bottleneck in the code known and located?
>
> run your own benchmark and see if it is really the case.
>
(Continue reading)

Rob Park | 2 Aug 03:17 2006
Picon

Re: I thought lighttpd is fast

On 8/1/06, Rolf Bode-Meyer <robome <at> gmail.com> wrote:
> Sorry, no rant intended, but after looking at
> http://litespeedtech.com/library/benchmarks/benchmark_r3/ and
> http://litespeedtech.com/library/benchmarks/benchmark_r2/, I'm
> shocked.
>
> From these benchmarks, not only that lighttpd is even slower than
> Apache or thttpd, but it's up to six times slower than LiteSpeed.

I can't comment on the validity of those benchmarks but the big draw
for me to lighttpd is not the speed (though that is nice), the big
benefit is the lower RAM usage. My servers tend to be old, recycled
PCs with very little RAM in them, and Apache is just a dog on those
systems! To avoid swap death on the servers I turn to lighttpd to use
less RAM. I originally chose lighttpd because apache just would not
run on a system with 32MBs of RAM, but since that initial time my
server has grown to 96MBs, so it's less of an issue, but I still like
lighttpd because it's easier to configure than Apache, by far.

--

-- 
Rob Park
http://exolucere.ca

N. Harrington | 2 Aug 04:44 2006
Picon

Re: How can I have an alias that will match upper and lower case requests?

--- Ryan Schmidt <lighty-2006c <at> ryandesign.com> wrote:

> On Jul 13, 2006, at 17:22, Ryan Schmidt wrote:
> 
> > On Jul 12, 2006, at 21:22, nmh wrote:
> >
> >> Hello
> >>  I have a fairly extensive aliases file that was
> used
> >> to shorten URLs. Sadly most of the directories I
> am
> >> aliasing to are Upper Case like this:
> >>
> >> "/VOLUME1/" =>"/home/dir/WW4/VOLUME1/",
> >> "/VOLUME2/" =>"/home/dir/WW2/VOLUME2/",
> >> "/VOLUME3/" =>"/home/dir/WW1/VOLUME3/",
> >>
> >>
> >> However it seems that some sites are now breaking
> this
> >> by converting all html to lower case.
> >>  So I need to allow "VOLUME1" to be matched by an
> >> upper case and lower case request.
> >>  If I duplicate as upper and lower case, it fails
> as a
> >> duplicate array key.
> >> "/VOLUME1/" =>"/home/dir/WW4/VOLUME1/",
> >> "/volume1/" =>"/home/dir/WW4/VOLUME1/",
> >
> > Try this:
(Continue reading)

Jonathan Vanasco | 2 Aug 06:49 2006

Re: I thought lighttpd is fast


On Aug 1, 2006, at 12:31 PM, Rolf Bode-Meyer wrote:

> Sorry, no rant intended, but after looking at
> http://litespeedtech.com/library/benchmarks/benchmark_r3/ and
> http://litespeedtech.com/library/benchmarks/benchmark_r2/, I'm
> shocked.
>
> From these benchmarks, not only that lighttpd is even slower than
> Apache or thttpd, but it's up to six times slower than LiteSpeed.
>
> It looks lighttpd isn't as good as it could and has a huge problem
> with Keep Alive? And that all when delivering simple static files. Is
> the bottleneck in the code known and located?

Having worked in marketing for a few years I can say that it wasn't  
unlikely for someone in management/sales to create a  set of results,  
then leave it up to others to create tests to achieve them.

I'm sure litespeed legitimately killed everything on that bench-  
litespeed isn't going to lie to people.

But I'm also sure that they're not going to tell everyone the exact  
specifics of the test.  Notice how the runtime configuration files  
are shown for each server-- but what about the compile time options?   
I'm sure that the people at LiteSpeed know how to tweak their compile  
to get the most out of a server-- but do they know how to do the same  
on Apache or Lighty ?

Also note that the biggest difference was between the 2 client  
(Continue reading)

Rolf Bode-Meyer | 2 Aug 16:24 2006
Picon

Re: I thought lighttpd is fast

On 8/2/06, Jonathan Vanasco <lighttpd-list <at> 2xlp.com> wrote:

> Having worked in marketing for a few years I can say that it wasn't
> unlikely for someone in management/sales to create a  set of results,
> then leave it up to others to create tests to achieve them.
>
> I'm sure litespeed legitimately killed everything on that bench-
> litespeed isn't going to lie to people.

Yeah, it's obviously that benchmarks are done and published to make
the own product look good.

And yes, they might not have used the best (compiler-) options for
lighttpd. But while I'd be happy to see that can be responsible for
looking that bad, I doubt so. 10 to 20 percent ok, but up to 200% more
req/s (1 server config)?

> If you want the closest thing to a fair benchmark, get a team of
> people each from Apache, LIghty, thttpd , Litespeed  and whomever
> else wants , in the same room.  Give them each 8 hours on an
> identical machine to compile, tweak, and do what is needed.  Make
> sure that every machine has the same hardware and OS that people
> agree on beforehand , that every team are all experts on the project
> from the development staff, and that all the bench software is the same.

While that would be fair, wouldn't it be poor for the products if a
team of experts is needed to get the best out of it?

> Other than that, just ignore all the benchmark stuff out there.
> Whether people are doing it on purpose or accidental, everyone is
(Continue reading)

Rolf Bode-Meyer | 2 Aug 16:29 2006
Picon

Re: I thought lighttpd is fast

On 8/1/06, Marcus Rueckert <darix <at> web.de> wrote:
> On 2006-08-01 18:31:26 +0200, Rolf Bode-Meyer wrote:
> > It looks lighttpd isn't as good as it could and has a huge problem
> > with Keep Alive? And that all when delivering simple static files. Is
> > the bottleneck in the code known and located?
>
> run your own benchmark and see if it is really the case.

You're right, that would be the best. But at I answered to Jonathan, I
can't because of incompatible system.

In any case, I don't care for my application (at least not yet). But
liking efficient software and being surprised by those benchmarks, it
made me wonder what's up.

Doesn't nobody here know LiteSpeed from his own experiences?

Bye,
Rolf

Jonathan Vanasco | 2 Aug 19:49 2006

Re: I thought lighttpd is fast


On Aug 2, 2006, at 10:24 AM, Rolf Bode-Meyer wrote:

> And yes, they might not have used the best (compiler-) options for
> lighttpd. But while I'd be happy to see that can be responsible for
> looking that bad, I doubt so. 10 to 20 percent ok, but up to 200% more
> req/s (1 server config)?

Where do you see that?

Lighttpd 1.4.8 and Litespeed 2.1 STD are neck-and-neck for all of the  
tests.

Litespeed 2.1 Ent has a 20-50% bump over either item

The 200% increases over Lighty were on "2 test clients from 2  
separate machines to showcase the SMP scalability of the Enterprise  
edition server."  Lighty wasn't tested under the same conditions.   
Apache was, then omitted from the results becuase they didn't show  
meaningful increase.  I'd like to see how lighty compares, though I'm  
sure Litespeed is faster.

> While that would be fair, wouldn't it be poor for the products if a
> team of experts is needed to get the best out of it?

People don't do benchmarking for actual intended use- they do it to  
find the theoretical best-condition purposes.  Would you rather use a  
product that will give you good performance out of the box, but thats  
as much as you'll get because they spent all their time on setup/user  
interface -- or a product where you need to get a good understanding,  
(Continue reading)


Gmane