A look at FastCgi & Mod_PHP architecture
6 likes9,018 views
The document discusses the evolution of PHP execution methods, focusing on the limitations of CGI and the advantages of FastCGI and mod_php. It outlines the operational mechanics of Apache and highlights performance issues related to memory usage and request handling. The document concludes with a positive outlook on FastCGI's benefits such as load balancing, security, and configuration flexibility.
![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
[ ]
• .](https://image.slidesharecdn.com/sydphptalkmarch-110331052446-phpapp02/85/A-look-at-FastCgi-Mod_PHP-architecture-4-320.jpg)
![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](https://image.slidesharecdn.com/sydphptalkmarch-110331052446-phpapp02/85/A-look-at-FastCgi-Mod_PHP-architecture-12-320.jpg)
![Fast[CGI ]
• Apache decides if dynamic script
• If yes, hands across to fastCGI
• PHP load does not effect mark-up load](https://image.slidesharecdn.com/sydphptalkmarch-110331052446-phpapp02/85/A-look-at-FastCgi-Mod_PHP-architecture-14-320.jpg)
A look at FastCgi & Mod_PHP architecture
- 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. 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. 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. 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. 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. 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. Mod_PHP • Checks queue then parses request • Is it static? Yes/No? Either way > Apache
- 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. 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. Mod_PHP fails 1b.Incoming requests are dropped 2b. Queue fills up and fails
- 11. One + One = Two? Page load time = { PHP script load + { static load [
- 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. 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. Fast[CGI ] • Apache decides if dynamic script • If yes, hands across to fastCGI • PHP load does not effect mark-up load
- 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. Fast[CGI Load Balanced • Web Server & FCGI Dispatcher separate • Dispatch among servers randomly • Dispatch among servers based on list
- 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. the difference It’s the bottle neck The load is balanced in FCGI
- 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. Thank you @aimee_maree www.aimeemaree.com |