Are people stealing your bandwidth by hotlinking you Vids?

[nate]

Originally Posted by cd34

http://redmine.lighttpd.net/projects...BeforeDownload

I'm running lighttpd on a different IP address (same server) to check out how well it holds up. Its just running a page or two for now, but using apache's utility to check server speed, lighttp is indeed fuckall bunches faster for serving static pages. I installed it on a local linux server, but it was crashy there, but that's probably because of something other than lighttpd. Its an old server that is really mainly just for backing shit up. lighttpd has run flawlessly so far on my remote server. One of these days I'll get around to putting some tgp galleries on it and seeing how well it works out under a load.


I also read something about trip pages under lighttpd, but havent had time to reallly look into it. Is that what you were referring to?

That was one of the ideas I was going to look into further, as well as some weird iptables and proxy stuff, but the idea to dynamically rewrite the .htaccess for allow/deny was a whole lot simpler, at least under apache.

[cd34]

Originally Posted by nate

I'm running lighttpd on a different IP address (same server) to check out how well it holds up. Its just running a page or two for now, but using apache's utility to check server speed, lighttp is indeed fuckall bunches faster for serving static pages.

lighttpd has some interesting behind-the-scenes limitations that most people probably won't run into. There are reasons that it and alternatives are faster than apache and if you really want to be fair about it, configure apache2 with mpm-worker, strip out a ton of the default modules, turn off overrides and then do your test on a multicore machine. A quadcore or a dual dual-core with apache will handle traffic as quickly as lighttpd.... though.... without flv streaming. Google's infrastructure is core oriented which amazes me that they use lighttpd for youtube. lighttpd does not scale well with multiple cpus/cores. It is a limitation in the core of their code and would require a rewrite from the ground up to fix. It does well for what it is, and when it was written. There are newer alternatives out there that are considerably faster. nginx and varnish are two alternative methods that soundly beat lighttpd's serving. Both solve different problems though.

lighttpd removes quite a few capabilities that apache includes by default and lighttpd starts as a stripped down server.

Apache is by no means a great performer, but, it is consistent, has a huge installed base, and everyone writes software expecting all of the things that would normally be present in an apache environment.

As for your idea, verifying a cookie, trigger before download and trafficguardian, there is a very, very simple way to bypass those protections which makes those methods somewhat fruitless to someone determined to hotlink the sites.

Short of some very specific cases, not using apache will add headaches down the line. If you liked lighttpd, check nginx. If you're looking for something relatively seamless to make apache quicker, check varnish. I'll warn you -- once you step off the path from apache, you either have to change the way you work, or spend a lot of time making them work the way you do. And while they all claim to have somewhat sane defaults, those defaults are nowhere near production quality.

Just to give you an idea:

ab -n 10000 -c 50 http://66.55.44.33/info.php

nginx, Requests per second: 320.79 [#/sec] (mean)
apache mpm-worker, Requests per second: 320.65 [#/sec] (mean)
lighttpd, Requests per second: 278.49 [#/sec] (mean)
varnish, Requests per second: 3391.36 [#/sec] (mean)

(varnish cached the response and answered the request out of the cache. Depending on your site, php isn't cacheable since Wordpress and others stuff expire times in there to require that the page be generated on every pageload. Yes, you can tell varnish to ignore that.)

info.php is just <?php phpinfo();?>

71k .jpg image

nginx, Requests per second: 3505.96 [#/sec]
apache mpm-worker, Requests per second: 814.97 [#/sec]
apache mpm-worker with allowoverride turned off:
Requests per second: 2488.22 [#/sec] (mean)

lighttpd, Requests per second: 3819.69 [#/sec] (had 17 failed to serves)
varnish, Requests per second: 3012.98 [#/sec]

There's another test that I did on throughput -- lighttpd actually serves files slower than each of the others. 100mb file took longer to download on lighttpd than it did on the other three. So, lighttpd dropped 17 requests out of 10000 and serves slower on long files than the others. Granted a benchmark is a crude test, but, it gives you some idea.

So, if you're out for true performance, you've already swapped out apache-mpm-prefork for apache-mpm-worker. Or, if you like to live on the edge (no pun intended), you might be using mpm-event. If you're still using prefork and comparing that to lighttpd and have overrides set and mod_status and the dozen other apache modules still installed, then its not really a fair test.

Apache does extremely well until you start pushing 70-80mb/sec or get close to 1000 requests per second. If you like to use server side includes, varnish has Edge Side Includes which are extremely powerful.

Sort of diverted from the original post.

[nate]

Originally Posted by cd34

lighttpd has some interesting...

Damn, you seem to know this stuff backwards and forwards. Kudos. I just started looking into lighttpd for serving static tgp galleries. If I ever need help with anything server related, your the guy I'll grovel to.

[MadCat]

Originally Posted by cd34

lighttpd has some interesting behind-the-scenes limitations that most people probably won't run into.
....
....

Sort of diverted from the original post.

The only issue with mpm-worker is that you can so seriously wreck mod_perl with it -- one reason I'm still using lighttpd with FastCGI since it does scale up easier than apache does -- what limits exactly are you speaking of for lighty? I know it's pretty core bound but other than that I haven't really seen any issues with the 1.5.x tree.

Waiting for 2.0 really

Anyway back to the regularly scheduled thread...