Oct
26
I gave a talk at the Seattle Tech Startups meeting last night on scaling early stage startups. The slides can be found here.
I’ve included some of the data I talked about below…
Here’s a post on Greg Linden’s blog describing the research that Google did and their experience at Amazon wrt page load times. 0.5 seconds increase in page load time can kill user satisfaction and consequently your revenue from that page.
Slow performance may also turn away visitors who may have become customers. If you’re a viral business, this can break your virality. It can take user adoption below that critical viral threshold.
A few key points from the talk:
- Make sure your servers are configured correctly before you get your first burst in traffic. The biggest problem I seem to make constantly is underestimating the amount of memory that MySQL or Apache is going to grab when the web server load builds or the db size increases. This results in my machine running out of memory and using disk as memory (swapping) which slows things down very badly.
- Disable Keepalive until you can set up a separate server for static content like images.
- Cache as much dynamic data as possible. I use Cache::FileCache. Memcached is an excellent product for caching across server boundaries.
- When MySQL isn’t fast enough for you, consider using lightweight systems like BerkeleyDB or Perl’s Tie::File. Or just roll your own using read/write file locking (flock).
- Create a separate static content server with keepalive enabled. Lots of lightweight threads can handle many more connections that your app server. Having keepalive enabled is much friendlier to your browsers. You also get the added benefit of higher browser concurrency with multiple hostnames.
- Block content thieves by monitoring how many actual content pages they fetch per minute. If they exceed a threshold, then do a reverse lookup on their IP address. If they aren’t Google, MSN, etc, then block them using a firewall rule. ‘iptables‘ is a great tool for blocking baddies.
- Most I/O intensive processes like MySQL or your own file access routines benefit hugely from the Linux filesystem cache. Make sure you leave plenty of free memory on your server. Linux will automatically grab that memory and use it to cache disk data and minimize actual disk reads and writes. I/O is a very common bottleneck for servers and this is an easy way to fix this bottleneck.
- Websitepulse.com is great for seeing your actual HTML page load time including DNS lookups.
- httperf from HP Labs is an open source linux tool that you can use to torture your web servers and see exactly how badly or well they perform under load. Make sure you run it on a different machine to the one you’re benchmarking.
