Hand Coding A Personal Website

I've had run-ins with nginx, and it's pretty cool, except configuring it is a giant pain. Also, it still isn't dispatching dynamic requests as fast as could be (goes trough a socket to another process or whatever).

Then there's stuff that no webserver out there does really satisfactory, which is low-latency websockets. Reason is that they proxy the websockets trough to another process, and even though it's on the local machine, this just drives latency up by whole dozens of milliseconds...

Ok, so what's my obsession with speed all about? My capital is strictly limited, so I've got to run whatever I want to run on my own VPS. Unfortunately I started running http://webglstats.com/ the tracker of which is embedded in some 500 other sites. They shuffle traffic me at a rate of between 5-10 stat impressions per second, and each of those triggers 3 requests (two gets, one post). I concurrently run around 50-150 open connections at all times.

So naturally I'd want the tracker to run as fast as I can, and I'd like my other web properties not to slow down because I run a high-traffic service on that server. And I found that pretty much everything out there just isn't very good at that.

So having had finally enough after years, I wrote my own. It's about 1500 lines of python, it's asynchronous, can do http-pipelining, has a dynamic dispatch router that can do things like vhosts, has an inotify integration so it avoids stat'ing static files all the time, it lets me plug python modules directly into the webserver (so no more subprocesses/sockets/fastcgi/whatever for dynamic requests). It does around 4000 requests/s, it easily does at least 512 concurrent open connections, it peaks at a troughput on localhost of +300mb/s and it does that while maintaining a maximum latency (on localhost) of 2ms, or outside (across about 6 hops) of around 15ms.

I'm happy with that, and now that the I spent the last two weeks writing that server (it's not the first I wrote, but I finally took the leap), I'm 100% sure that whatever problem I encounter in my hosting adventures, I can make my server solve them.

(I can't find the site I got this from though - and just not saving passwords probably would be better)

12% performance boost is actually quite a significant jump when you're pushing heavy traffic and looking to shave any fat from the stack you can find.

Also your comment about "and it goes down either way if you're getting more than 245 rps" doesn't really make a whole lot of sense as the webfarm isn't going to magically crash the moment you get one request more. I suspect you're not really understanding what those ab results are representing, but that doesn't really matter as I wouldn't trust those figures for any real world usage anyway. As I pointed out in another post in this thread, the actual performance penalty will be subject to a considerable number variables.

> and, as to the security of it -- if you have access to the httpd.conf file, i GUARANTEE you've got bigger holes in your own hodge-podge, whole-system security than something like an .htaccess file on which you'd have to work really hard and explicitly make insecure.

You have things completely backwards there. httpd.conf is more secure than .htaccess because httpd.conf can only be amended and actioned by root where as .htaccess will have lower security permissions and is loaded on demand (ie an attacker doesn't need to restart the Apache daemon to action any changes).

Same difference. 12% on 1 server is 12%. But if you have a dozen servers with the same 12% gain then it's still 12%. Such is the nature of percentages.

> therefore, if you get hit by something that will actually make a difference, it's not going to be within 12%. it's going to be like 12,000%. so, it's not going to make a whit of difference at that point whether you have httpd.conf or .htaccess.

I manage a data centre for a number of high profile sites. If I can improve throughput by 12% then that means I need one less server in the farm. It means less strain on the db as connections are clearing down quicker. And it also means the likelihood of visitors hitting 'refresh' due to slow load times is reduced, which in turns slows the exponential growth that happens shortly before a site buckles. So trust me when I say 12% does matter if you're building busy sites - I know this because I wouldn't be doing my day job properly if I didn't load test this stuff and implement any free optimisations I can.

> i'm just saying, if you've got access to httpd.conf, you've got the whole server. that means you've probably got bigger fish to fry as to worrying about security than a pretty harmless, defaulted as secure, .htaccess file.

Yes, I'd already said the former point myself, however your latter point is still ignoring the simple fact that you don't need to be root to edit a .htaccess file. I repeat, you do /NOT/ need to be root to edit a .htaccess file!

Someone can edit your .htaccess file even when they don't have permissions to edit httpd.conf (and thus ssh_config nor anything else in /etc nor other root-owned config hierarchies). Thus if your http docs are writeable (and they typically are for personally web servers as you don't have a dedicated network storage such as a SAN shared across your web servers, so your content is stored on the web server itself) then a bug in your website could allow an attacker access to write to the disk in the web docs directory. In short, attackers could create and edit their own .htaccess files.

We're not talking about root access here, these are not attacks that have permissions to write to httpd.conf; we're talking about a http-owned (eg 'www-data' on Debian) users who shouldn't have ability to write files having that ability to edit the Apache config because .htaccess is not typically root owned.

If you want the convenience of a .htaccess file but the security of a httpd.conf, then change all your .htaccess files to be root owned:

    sudo find / -name ".htaccess" -exec chown root:root {} \; -exec chmod 644 {} \; -print