Get a handle on PHP handlers

PHP handlers? Mod_php? Fpm? How does the sense of the inner workings of PHP outside of our lines of code? We know we can run PHP on the server to build Web applications swiftly, but what can we optimize our environment and Config Urations to reach maximum scale? We know that PHP have its drawbacks for not being asynchronous or Event-driven, which are all the more reason to ensure maxi Mum optimization. The impact of your server environment on your PHP application performance can is more than your think you can afford. A careful examination of your PHP ecosystem would help you avoid suffering performance loss in areas you can otherwise solv E for easily.

You can deploy PHP, as an ecosystem, in a myriad of settings. As the demands for Web application performance and scalability has increased over time, so has the "the" in which PHP code is invoked, interpreted and handled. This evolution of the configuration optimizations allows for greater scale, security, and durability. If you were uncertain about how your environment is setup, it could be time-audit your environment and reconsider old arch Itectural decisions. Optimizing your PHP application for speed and reliability extends beyond just your code; Taking advantage of the latest technology in PHP handling may solve many of your pain points so you might has been obli Vious to subsisting. We'll explore the various ways in which PHP can is configured to work with your Web server and compare these runtimes from A performance and scalability perspective.

Handlers

Under-the-hood in every PHP application exists a Web server and the PHP interpreter. As HTTP traffic comes in, your Web server completes the request by providing either the static data (e.g. images, JAVASCRI PT, CSS) or Dynamic Data. The Web server would pass the request to PHP to handle the interpretation of your application code, create the response, and hand it back to the Web server, to then deliver it back to the customer. During this process, the interface in which of the Web server communicates with the PHP runtime is called the PHP Handler.

An easy-to-do-you-check-handler-running is-to-create a dummy file on your server named phpinfo.php The following code:

<?php phpinfo(); ?>


Load, page up, your browser and look for the Server API entry block.

cgi–mod_cgi

MOD_CGI is a common option even to this day, mainly in shared hosting environments or (extremely) legacy applications tha T Haven ' t upgraded in almost a decade. It is an old, a outdated, and recommended never to the use of any modern PHP environment.

Running PHP code using this method creates a new CGI process outside of the Apache process causing the PHP interpreter to  Load (and configs read) upon every request.  This approach isn't necessarily the most efficient nor effective. Arguably, this method was more secure:using suexec mod_cgi can keep the execution of PHP code outside of the scope of APAC He meaning that faulty or malicious code cannot go outside of the scope of interpretation. This method was popular for shared hosting environments under the same PHP interpreter roof.

Unfortunately, the bad outweighs the good with this method; Because of its inefficient, poor performance, and heavy taxation in server resources, it quickly fell out of preference fo R Serious PHP developers. It also does not support PHP Opcode Cache methods, which clearly rules it out for serious high-traffic environments.

suphp–mod_suphp

Similar to CGI, suphp (single User PHP) are an Apache module. You have the advantage of seeing which user is running which process and taxing the CPU. However, similar to CGI, this was inefficient and as your traffic begins to increase you'll very quickly push your server to its limits. The benefit of suphp is essentially the security and are a popular option for hosting multiple PHP applications on a single Server because your PHP scripts run as the owning user. Thus, if your application provides an upload form, the uploaded files would be owned by the same owner of the PHP script it Self with the necessary permissions intact. This also guarantees no PHP script execution by any user other than the owner.

With suphp, you'll run PHP as a separate process for each request and quickly max out your resources as your traffic beg INS to Spike. Similar to CGI, Mod_suphp quickly fell out of favor for high-traffic scenarios. Unfortunately, suphp soon fell from popularity as it also provided no support for Opcode Cache. Also, considering its last release is in, it might is safe to assume this project no longer supported.

dso–mod_php

Considered the de facto standard of PHP handlers, mod_php quickly rose-to-popularity for it speed and scale. You may probably already has mod_php installed; Your phpinfo () dump would show Apache 2.0 Handler under the Server API block.

The DSO handler is perhaps one of the oldest and fastest handlers available. The mod_php module integrates PHP as a part of the Apache process itself allowing Apache to interpret the PHP code. Thus, you does not spawn a new PHP process per request, and your overhead are low as PHP preloads as an Apache child process.

One of the greatest advantages of mod_php is so you can now leverage a Opcode cache (e.g. APC), which in turn, would spe Ed up your average response time in extremely significant orders of magnitude. Speaking of APC, if you had not already checked it out, I had another post in which I briefly cover Opcode Cache, and my Colleague Rob Bolton has a excellent article covering it in depth.

A disadvantage to mod_php are that all your PHP application files would be owned and executed by the Apache user. This would cause some loss in visibility to which specific users may be impacting server resources. I do not think for the modern PHP application This is a serious issue; You is probably not running multiple websites in a single server but rather powering one giant PHP application across a F Arm of servers.

Fastcgi–mod_fcgid

FastCGI is the what it name implies:a fast PHP implementation handler as a CGI module built with performance in mind. FastCGI won't limit you to only one Web server (unlike mod_php) and reduces CPU overhead by keeping PHP scripts in memo Ry and not have to invoke a new PHP process on each request. Security is also tight as, the benefit of executing PHP scripts as the owning user and not as the Apache user.

A major disadvantage to FastCGI was that it was taxing on your memory consumption (although less so than mod_php). By keeping your PHP scripts in memory, you may find this your RAM usage on your server begins to spike. This was a common symptom with in-memory cache mechanisms, including APC and Memcached. However, you'll need to find the right tradeoff because keeping data in memory also means lowered CPU usage and faster ACC ESS to that data, thus reducing the overall response time of your requests.

FastCGI is a good modern alternative to suphp if security is your primary concern within a shared environment without SACR Ificing speed.

FPM (FastCGI Process Manager) –php-fpm

While technically not a handler per se, php-fpm are coupled with FastCGI for more efficient process management and can u SED on any server which is also compatible with FastCGI. FPM (FastCGI Process Manager) is a fitting replacement for those of your who may has had experience with spawn-fcgi to Han Dle worker FastCGI processes. FPM manages the FastCGI SAPI, which is the Server API (the interface between PHP and Apache). As a side note, for command line execution, PHP-CLI are the SAPI for PHP.

FPM also supports opcode cache and allows for sharing your APC cache among all PHP-FPM workers. The additional features that PHP-FPM provides enables high-traffic PHP environments to begin to scale at levels never BEFO Re imagined. These types of technical advantages allowed for more scale, better utilization of hardware and OS resources, smarter Proce SS Management, and more concurrency and throughput. PHP applications is also able to scale across multiple servers better. As of Php 5.3.3, FPM now ships with PHP.

Web Servers

We ' ve been talking a lot about handlers, but to reach an optimal environment you need to combine it with the right web Ser Ver for the level of trying is achieve with your PHP application. The popular Web servers for PHP applications is Apache and Nginx. While each server operates under their unique technology and have their strengths and weaknesses, Nginx + PHP-FPM has becom E a clear contender in the fight for speed and scale.

Apache

Being the most common Web server in the world, Apache also have its limitations. As user traffic comes in, Apache would spawn a new worker process per request. Both Prefork and MPM mode create new processes per client connection, although worker mode can handle more requests while It serves more than one connection per process. Nevertheless, as your traffic begins to increase "ll notice your memory begin to exhaust as connections utilize RAM and Compete for CPU. You'll find yourself easily maxing out your connection pool if you run a heavy-traffic environment. You can configure Apache to optimize the number of maximum processes and concurrent connections given your hardware Resour CES, but you'll still find processes competing, and as traffic increases so does your need to scale.

Nginx

Nginx contains an event-driven, non-blocking, and asynchronous architectural model. If node. JS has taught us anything, this design creates the perfect environment conducive to serving multiple requests at t He same time. Because It is non-blocking, it can continue to serve additional events (user connections) without have to wait, and Beca Use it was asynchronous, it can handle multiple concurrent users at the same time. The beauty of this model have quickly proven Nginx to being the leading contender for handling massive amounts of traffic unde R the same server Setup. With Nginx, you can even cluster your processes to spawn a additional process per core on your machine, thus increasing y Our ability to handle more requests per server.

Conclusion

Clearly, you have the options. Regardless of whether your primary concern are security or speed, you'll be need to consider your architecture deeply before G Oing down the path of building a ecosystem in which to deploy your PHP application. Take into consideration not only your immediate needs but also your future needs in order to remain scalable as your appli Cation grows in size and traffic.

In-traffic environments, coupling the Event-driven architectural model of Nginx with PHP-FPM, you'll be running PHP o Ptimized to handle massive amounts of traffic. There is, of course, further methods of optimizing the code itself to decrease your average response time, but from a hos Ting perspective you'll be rest-assured in Flying-high with Nginx and PHP-FPM under your belt.

Original: Https://blog.appdynamics.com/php/get-handle-php-handlers

Get a handle on PHP handlers