Surviving Slashdot

Surviving Slashdot:

How to plan for the deluge.

Magnatune’s architecture:

linux/apache/mysql/php

What happened when Slashdot hit.

1. Thousands of Apache processes

2. Http Servers unresponsive

3. Http Audio Streaming not fast enough for real

time

Analysis & Solutions

Why is Yahoo so “snappy” ?

By default, Web browsers ask for every image on every page

with “If-Modified-Since”.

Ironically, lots of small graphics on a web page is the least efficient use

of HTTP.

What if you could make browsers not ask for

images that are unchanging?

Trick #1:

use “Expires” HTTP header on static graphics:

Expires: Thu, 15 Apr 2010 20:00:00 GMT

I did this by hacking the C source code to my

HTTP server.

Is there a fast Apache way to add an Expires: header when returning

GIF/JPEGs?

next problem...

In many cases, HTTP performance is

constrained by the receiver, not the sender.

Large files take a long time to be downloaded

by the requestor.

Each download uses up an Apache process.

Apache Bench shows great large-file performance.

But Apache Bench isn’t a useful metric with large files in the real world.

The problem is the “fork” based

architecture of Apache.

Thread-based HTTP servers have the same

problem.

Apache has an experimental “async” mode -- this may be a solution in the future.

Trick #2:

Use a dedicated async-based HTTP server for

large files.

next problem...

PHP is handy.

But PHP is slow.

Apache BenchSpeed tests:

PHP: 9 pages/secHTML: 250 pages/sec

Trick #3:

Statically cache most PHP pages into HTML.

Use Apache “MultiViews”

option.

URLs shouldn’t include .php or .html

ie:

http://x.com/mypage

could be PHP or HTML, doesn’t matter.

Have a script regularly HTTP GET most PHP files, save as HTML and

delete the PHP.

Yields a 25x speed increase.

end