a look at fastcgi & mod_php architecture
DESCRIPTION
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.TRANSCRIPT
Mod PHP and Fast CGI
Aimee Maree Forsstrom
Where did we come from?
Where are we going?
Why did we need to get here?
A look at FastCgi & Mod_PHP architecture
{ { [
{ {
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>”
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!
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
• . [ ]
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)
^^^ ^
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
Mod_PHP • Checks queue then parses request
• Is it static? Yes/No? Either way > Apache
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
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
Mod_PHP fails 1b.Incoming
requests are
dropped
2b. Queue
fills up and
fails
One + One = Two?
Page load time =
PHP script load
+
static load
{ { [
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
]
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
_ |
Fast[CGI ] • Apache decides if dynamic script
• If yes, hands across to fastCGI
• PHP load does not effect mark-up load
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
Fast[CGI Load Balanced • Web Server & FCGI Dispatcher separate
• Dispatch among servers randomly
• Dispatch among servers based on list
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.
the difference It’s the
bottle
neck
The load is
balanced
in FCGI
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
Thank you @aimee_maree
www.aimeemaree.com
|