A look at FastCgi & Mod_PHP architecture
•
6 gostaram•8,996 visualizações
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.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (13)
Semelhante a A look at FastCgi & Mod_PHP architecture
Semelhante a A look at FastCgi & Mod_PHP architecture (20)
Mais de Aimee Maree Forsstrom
Mais de Aimee Maree Forsstrom (20)
Último
Último (20)
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 |