Technical presentation from 2005 about how to make your web site survive slashdot/digg style mega load.

1. Surviving Slashdot:
How to plan
for the deluge.

2. Magnatune’s
architecture:
linux/apache/mysql/php

3. What happened when
Slashdot hit.

4. 1. Thousands of Apache
processes

5. 2. Http Servers
unresponsive

6. 3. Http Audio Streaming
not fast enough for real
time

7. Analysis & Solutions

8. Why is Yahoo so
“snappy” ?

9. By default, Web
browsers ask for every
image on every page
with “If-Modified-Since”.

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

11. What if you could make
browsers not ask for
images that are
unchanging?

12. Trick #1:
use “Expires” HTTP header on
static graphics:
Expires: Thu, 15 Apr 2010 20:00:00 GMT

13. I did this by hacking the
C source code to my
HTTP server.

14. Is there a fast Apache
way to add an Expires:
header when returning
GIF/JPEGs?

15. next problem...

16. In many cases, HTTP
performance is
constrained by the
receiver, not the sender.

17. Large files take a long
time to be downloaded
by the requestor.

18. Each download uses up
an Apache process.

19. Apache Bench shows
great large-file
performance.

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

21. The problem is the
“fork” based
architecture of Apache.

22. Thread-based HTTP
servers have the same
problem.

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

24. Trick #2:
Use a dedicated async-
based HTTP server for
large files.

25. next problem...

26. PHP is handy.
But PHP is slow.

27. Apache Bench
Speed tests:
PHP: 9 pages/sec
HTML: 250 pages/sec

28. Trick #3:
Statically cache most
PHP pages into HTML.

29. Use Apache
“MultiViews”
option.

30. URLs shouldn’t
include .php or .html

31. ie:
http://x.com/mypage
could be PHP or HTML,
doesn’t matter.

32. Have a script regularly
HTTP GET most PHP
files, save as HTML and
delete the PHP.

33. Yields a 25x speed
increase.

34. end