Successfully reported this slideshow.
Your SlideShare is downloading. ×

A look at FastCgi & Mod_PHP architecture

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 20 Ad

A look at FastCgi & Mod_PHP architecture

Download to read offline

A look at mod_php and fastcgi and how apache handles internal HTTP requests. Aim is to provide web developers and architects with architectural information on how mod_php and fastcgi handle static and dynamic requests to provide background knowledge when deciding on which way to go for your server or application.

A look at mod_php and fastcgi and how apache handles internal HTTP requests. Aim is to provide web developers and architects with architectural information on how mod_php and fastcgi handle static and dynamic requests to provide background knowledge when deciding on which way to go for your server or application.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Advertisement

Similar to A look at FastCgi & Mod_PHP architecture (20)

More from Aimee Maree Forsstrom (20)

Advertisement

Recently uploaded (20)

A look at FastCgi & Mod_PHP architecture

  1. 1. Mod PHP and Fast CGI { { {Where did we come from? { Where are we going? Why did we need to get here? A look at FastCgi & Mod_PHP architecture [ Aimee Maree Forsstrom
  2. 2. The beginning • HTML Tags – 1991 • HTML v2.0 - 1995 • HTTP v1.0 – 1996 • Computer says “213.236.210.9 Show me your home page” • Web server says “HTTP 200 OK Here you go <HTML> … </HTML>”
  3. 3. Dynamic Scripts • CGI – 1993 • Receives PHP page request • Loads PHP environment • Executes request • Kills environment • Cleans it all up • Repeats for every request, yes every single one!
  4. 4. Limitations • The architecture with the worst performance. Why? • Creates new process for every request • Debugging CGI scripts traditionally been difficult. Why? • Because, hard to study standard output and errors • MOD_PHP and FastCGI came about at the same time to deal with the problems of CGI [ ] • .
  5. 5. Mod_PHP takes over • Apache becomes forerunner • ^ Mod_PHP gains momentum • Loads as Apache child process ^ • Preloads PHP environment • Low latency ^ • Use persistent database sessions • Shared memory • Two requests or one after the other can share memory between ^ • Store persistent data in memory (xcache, APC, etc)
  6. 6. Mod|PHP the Downside • Uses Apache Permission > runs as www • Increases Apaches memory usage > Parent – Child design > need 100 apache children, if each one uses 100mb then 1GB of memory needed • Slows down Apache as Apache does the work of PHP • Apache needs to restart the child • Leads to loss of connection • Not suitable for scaling across multiple servers 
  7. 7. Mod_PHP • Checks queue then parses request • Is it static? Yes/No? Either way > Apache
  8. 8. How does Apache work • Procedural based parent/child design • Listener at the front • Listener places request in queue • Queue processed bottom first • Therefore, first come first served • Backend checks for new processes • Pick request from queue • Processes request returns results • Apache decides what to do with it? • PHP runs as a apache child • Therefore it can do nothing else until the script executes/times out and mark-up is delivered
  9. 9. Apache gets a work-out • Backend = mod_php • Architecture leads to blocking • Apache says? • Spawn more backends • But? • We run out of memory? • Solution = limit them! • But now the queue fills up? #fail
  10. 10. Mod_PHP fails 1b.Incoming requests are dropped 2b. Queue fills up and fails
  11. 11. One + One = Two? Page load time = { PHP script load + { static load [
  12. 12. Fast[Cgi takes over • Parent/Child model • Apache does not handle PHP children FastCGI does • Web servers like Apache don’t like processing applications • Web servers like dealing with static requests • Separates application from the web server ] • Web server becomes proxy server and sends PHP requests to FCGI
  13. 13. Fast[CGI benefits • Preloads PHP environment • Webserver free to process static content • FastCGI handles only PHP requests • Server does not die if PHP script dies • Natively load balanced • Round robin load balancing effect • Restart PHP without restarting server • Make configuration changes on the fly _ |
  14. 14. Fast[CGI ] • Apache decides if dynamic script • If yes, hands across to fastCGI • PHP load does not effect mark-up load
  15. 15. Fast CGI dispatcher • Similar workflow to HTTP, but? • FastCgi is its protocol • Not HTTP • Listener takes request • Places in queue • Backends pick up • Processes results
  16. 16. Fast[CGI Load Balanced • Web Server & FCGI Dispatcher separate • Dispatch among servers randomly • Dispatch among servers based on list
  17. 17. how are they different? • FastCGI is interprocess communication • And mod_PHP is an in-process module Example Persistent connections Mod_php every persistent connection would own connection to the database. This can be expensive as some connections would be serving static content such as image files.
  18. 18. the difference It’s the bottle neck The load is balanced in FCGI
  19. 19. The future is bright • Fast CGI, but it’s old? So get into it finally! • Load Balancing • Increased Security as each backend runs as different user • Multiple PHP environment support 5.2/5.3 • Restart PHP without one dropped connection • Configuration changes without dropping connections • Not language specific • PHP runs FastCGI natively inside application • PHP compile time option
  20. 20. Thank you @aimee_maree www.aimeemaree.com |

×