New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Well when your ventilator has 16 open bug reports and mine has 258 then its save to say that yours was better constructed than mine.
That is a conclusion you can not directly draw from that. It just tells you that there have been more bug reports as more bugs have been visible to somebody. It might however be the case that my ventilator, even if it just has 16 open bug reports, is constructed much worse as it has some hidden bugs that might be fatal but nobody has recognized them so far.
What I'm trying to say is that just looking at the bug-reports list does in no way tell you if one software is better than another.
Considering that nginx is used by much more websites than Lighttpd probability suggests that bugs in nginx have a higher chance of being found than bugs in Lighttpd.
Also i never sad that you can tell one webserver is better than the other from looking at the bug lists, i am just responding to this post:
Well as said, quantity is never a good indicator. I would say that the quality of the websites that are running Lighttpd of Nginx prevails in this case. The absolute numbers are uninteresting to me in that case. Nginx holds the 3rd place whereas Lighty holds the 5th. But Lighttpd is used by "Meebo, YouTube, and SourceForge. Wikimedia also runs Lighttpd servers. Three of the most famous torrent listing websites, The Pirate Bay, Mininova and isoHunt, which have more than 1,000 hits per second, also use Lighttpd." [1] "Wikipedia uses nginx as its SSL termination pr oxy." [2] Both two good indicators for quality.
Consensus. But I didn't ask for the diff I could see myself. I was merely asking for an advantage. I admit that this is not expressed quite obviously in my sentence.
http://de.wikipedia.org/wiki/Nginx
Oh look, it's this thread again. How about you just try them both and use what you like? Lighttpd and Nginx are two different things. I don't see why they are ever even compared in the first place. Building a web app and need a server backend? Go with Lighttpd. Need an Apache alternative with a bunch of walkthroughs online? Go with Nginx. Need to see Nginx fanboys come out of the closet and regurgitate the same misinformation they've been spitting for years now? Then compare Nginx to anything else in the world.
nginx
@subigo is mad again, tch.
Grabs popcorn
Don't choke on the
dicpopcorn, @ElliotJ :PHumour aside though, @subigo has a point this time. You're better off with something that you're comfortable with than whatever uses the lesser resources. Part of my preference for Apache stems from my severe dislike of how lighty handles ACLs, for example :P
Both are very good IMHO. I guess the choice is more a matter of personal preference with configuration files syntax.
During some testing (Debian 6, dotdeb for nginx), I noticed that:
About security or stability, did not notice any difference. Both provided very good uptime.
Saying "Using nginx" also seems more "trendy", but that should not be the reason to choose nginx.
I know it's wrong, but I say Nginx as "N - jinx".
Lighttpd gets my vote.
We used to refer to it internally as "Dammit, <clientname> got compromised again".
I do too.
Same. I didn't know how it was pronounced when I first saw it. That's why I hate these "clever" names with idiotic pronunciations.
I also pronounce GNOME like "genome"... even though I knew at the time how the word "gnome" was pronounced... shrug
Last time we debated...
http://www.lowendtalk.com/discussion/2166/why-nginx-instead-of-lighttpd/p1
N - jinx is more cool
genome too :P
Haha, why's that? Bugs in nginx, or harder to configure securely or something?
Nginx used to have quite a few gaping vulnerabilities. When we were still selling VMWare, maybe 4/5 of our abuse cases were the result of a VPS' nginx being compromised.
It's been quite some time since, so it looks like they've done a decent job of patching up.
Reposting post from other thread:
Note that the above was written using php-fpm with a predefined amount of workers/threads/whatever they are called, which had to be set quite high to prevent HTTP 500 errors when there was a traffic peak - a lot of these workers/threads/etc would cause a lot of RAM usage. I've been told that it doesn't exist with the new on-demand implementation of php-fpm for nginx, but I haven't test this. Since lighttpd operates in on-demand mode to begin with, the problem does not exist for lighttpd.
nginx needs more help docs that can make or break a project.
listen 80;
server_name www.example.com;
rewrite ^/(.*) http://example.com/$1 permanent;
}
Lighty:
url.redirect = ( "^/(.*)" => "http://%1/$1" )
}
Thank you very much! It looks pretty easy only.
This thread inspired me to review my lighttpd config which needed some cleaning up and tuning. Decided to install xcache to play around with also.
why beat around the bush, just go with Apache damnit! or better yet IIS!
Apache can thrash with fork bombin and lol at IIS.
To be or not to be, That is the question.
Both are good software.
See what modules / functionality you need or what system configuration you feel more comfortable.
@nabo that nginx example could be even simpler especially since listening to all interfaces on 80 is default. So you can remove the listen line from there.
Also there's no reason for this:
rewrite ^/(.*) http://example.com/$1 permanent;
No need to capture the whole thing when you're going to pass it all, saves CPU when it's already captured into $request_uri:
rewrite ^ http://example.com$request_uri permanent;
@taipres the wiki is pretty detailed, we're constantly referring people who visit the IRC channel to both http://wiki.nginx.org/ifIsEvil and http://wiki.nginx.org/pitfalls on account of all the incredibly old and incorrect blogs out there.