Your SlideShare is downloading. ×
  • Like
Scaling application servers for efficiency
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Scaling application servers for efficiency

  • 1,492 views
Published

Slides for the talk/ discussion I gave at ScaleCamp uk 2009, and then repeated the day afterwards at London perl workshop. …

Slides for the talk/ discussion I gave at ScaleCamp uk 2009, and then repeated the day afterwards at London perl workshop.

This presentation covers the key points about serving media files efficiently with 100s or 1000s of concurrent streams, still using a high level web framework in combination with X-Accel-Redirect.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,492
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
23
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Scaling application servers for efficiency Tomas Doran <bobtfish@bobtfish.net> Catalyst web framework core team member Serving lots of media for a living ScaleCamp London 09
  • 2. mod_$lang considered harmful • Web servers send bytes • Application servers generate pages • These two goals are orthogonal
  • 3. EPIC FAIL • 80 Mb mod_perl processes • Serving static media • Reading stuff off disk/network in a while loop • Sending it to people on Virgin, using bittorrent, ‘3g’, via a damp piece of string. • With MaxClients x proc size being waaaay higher than physical memory
  • 4. Pushing bytes - how to fail. • Serve static content from the same servers running your application (mod_perl, mod_python epic fail, mod_php moderate fail) • Static content AT ALL. I don’t care if you need to check ACLs
  • 5. Pushing bytes - Success • X-Sendfile (lighty and mod_sendfile) • X-Accel-Redirect (nginx)
  • 6. App server maps media • Check ACLs / Resolve one-time URI • Locate media • Serve X-Accel-Redirect • Aquire PIE, CAKE and PONY, profit.
  • 7. My setup • App runs FCGI • Run nCPUs x 1.2 procs (measure this!) • Looks up asset mapping (memcache) (Tm) • UPDATE download_attempts + 1 in MyFirstSQL • X-Accel-Redirect
  • 8. • X-Accel-Redirect • Bytes sent by nginx • Serving mp3s - filesize 1-7Mb (ish). • > 30k sessions • > 200 reqs/s • Filling 1Gb of pipe • 1 box.
  • 9. Several 100 Tb of media online Technology stack: nginx perl FCGI Catalyst MyFirstSQL memcache X-Accel-Redirect nginx-mogilefs-module MogileFS lighty
  • 10. Even if extra context switching has zero overhead you serve people sooner if you queue. A B A B A B A B A B A finishes significantly before B in the lower diagram B finishes at the same time in both
  • 11. RUN MOST EFFICIENT NUMBER OF WORKERS QUEUE REQUESTS AFTER THAT PROFILE PROFILE PROFILE
  • 12. • App is notwork bound after tuning • Best efficiency ~ n CPUs x 1.2 (for me!) • CONTEXT SWITCHING HURTS
  • 13. Thanks • Questions? • t0m <bobtfish@bobtfish.net> • http://catalystframework.org • http://search.cpan.org/author/BOBTFISH • http://github.com/bobtfish