Surviving Slashdot

1,570 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,570
On SlideShare
0
From Embeds
0
Number of Embeds
41
Actions
Shares
0
Downloads
34
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Surviving Slashdot

  1. 1. Surviving Slashdot: How to plan for the deluge.
  2. 2. Magnatune’s architecture: linux/apache/mysql/php
  3. 3. What happened when Slashdot hit.
  4. 4. 1. Thousands of Apache processes
  5. 5. 2. Http Servers unresponsive
  6. 6. 3. Http Audio Streaming not fast enough for real time
  7. 7. Analysis & Solutions
  8. 8. Why is Yahoo so “snappy” ?
  9. 9. By default, Web browsers ask for every image on every page with “If-Modified-Since”.
  10. 10. Ironically, lots of small graphics on a web page is the least efficient use of HTTP.
  11. 11. What if you could make browsers not ask for images that are unchanging?
  12. 12. Trick #1: use “Expires” HTTP header on static graphics: Expires: Thu, 15 Apr 2010 20:00:00 GMT
  13. 13. I did this by hacking the C source code to my HTTP server.
  14. 14. Is there a fast Apache way to add an Expires: header when returning GIF/JPEGs?
  15. 15. next problem...
  16. 16. In many cases, HTTP performance is constrained by the receiver, not the sender.
  17. 17. Large files take a long time to be downloaded by the requestor.
  18. 18. Each download uses up an Apache process.
  19. 19. Apache Bench shows great large-file performance.
  20. 20. But Apache Bench isn’t a useful metric with large files in the real world.
  21. 21. The problem is the “fork” based architecture of Apache.
  22. 22. Thread-based HTTP servers have the same problem.
  23. 23. Apache has an experimental “async” mode -- this may be a solution in the future.
  24. 24. Trick #2: Use a dedicated async- based HTTP server for large files.
  25. 25. next problem...
  26. 26. PHP is handy. But PHP is slow.
  27. 27. Apache Bench Speed tests: PHP: 9 pages/sec HTML: 250 pages/sec
  28. 28. Trick #3: Statically cache most PHP pages into HTML.
  29. 29. Use Apache “MultiViews” option.
  30. 30. URLs shouldn’t include .php or .html
  31. 31. ie: http://x.com/mypage could be PHP or HTML, doesn’t matter.
  32. 32. Have a script regularly HTTP GET most PHP files, save as HTML and delete the PHP.
  33. 33. Yields a 25x speed increase.
  34. 34. end

×