مميزات / فائدة php fpm pool لعزل كل موقع عن الاخر داخل السيرفر

مميزات / فوائد php fpm pool لعزل كل موقع عن الاخر داخل السيرفر
شرح fpm pool لفصل كل موقع على السيرفر عن الاخر
جعل كل موقع على السيرفر منفصل عن غيره
حل مشكلة ارتفاع اللود على احد المواقع و تاثيره على كافة مواقع السيرفر
كل موقع حمام سباحة خاص به مستقل عن غيره
PHP-FastCGI Process Manager
mod_php vs fpm

https://www.rise.company/upload/uplo...9789287841.png

خاصية PHP-FPM مناسبة للخوادم التي تحتوي على أكثر من موقع وأنها مخصصة لعزل كل موقع عن الآخر، يجب استخدام أحواض php-fpm فإن ميزة عملية الفصل يمكنها منع خروق أمنية خطيرة. مزايا أمن وعزل المواقع عن طريق إنشاء أحواض pools خاصّة بـ php-fpm و التى تشمل معها بالتالى فصل قواعد البيانات MySQL, PHP

المشاكل فى الاسفل تم حلها في php-fpm بإنشاء أحواض مختلفة والتي تشتغل تحت مستخدم مختلف لكل موقع.
حيث اذا كان هنالك حوض واحد فقط والذي سيشغل جميع سكربتات PHP لجميع المواقع هذا يطرح مشاكل منها:

https://www.rise.company/upload/uplo...9789287912.jpg

• إذا تعرض تطبيق ويب على أحد أجزاء خادوم إلى خطر أو هجوم فستتعرض جميع مواقع الموجودة على هذا الخادوم أيضا، فالمهاجم سيتمكن من قراءة ملفات الإعداد (configuration files) بما في ذلك تفاصيل قواعد بيانات لمواقع أخرى أو حتى تغيير ملفاتها.
  
• إذا أردت إعطاء مستخدم صلاحيات للدخول إلى الخادوم الخاص بك، فسوف تعطيه صلاحيات الوصول إلى جميع المواقع، فعلى سبيل المثال، إذا كان مطورك يحتاج إلى العمل على بيئة الإدراج (staging environment)، فحتى مع صلاحيات صارمة جدا على الملفات، فستبقى له إمكانية وصوله إلى جميع المواقع بما في ذلك موقعك الرئيسي على نفس الخادوم.

• اذا كان هناك موقع ما يسبب لود عالى على السيرفر فسيغلق جميع المواقع على نفس السيرفر.

هذه الميزة موجودة فى Easy Apache version 4 وليس فى Easy Apache version 3
لذا يجب الترقية لكى تتمتع بمميزات php fpm pools

https://www.rise.company/upload/uplo...2979022291.jpg

PHP-FastCGI Process Manager (PHP-FPM) to provide the best performance for websites using the WordPress content management system (CMS). PHP-FPM is an advanced, highly-efficient processor for the PHP scripting language. WordPress websites configured to use PHP-FPM can serve much greater amounts of website traffic while using the same or fewer server resources than other PHP handlers. This owes to PHP-FPM’s architecture and features. For an overview of InMotion Hosting’s WordPress Hosting platform and how PHP-FPM fits into it, please refer to our guide discussing the technologies used in the WordPress Hosting Stack. PHP-FPM’s Architecture

As a high-level programming language, PHP scripts require compiling before a web server’s underlying processor hardware can understand it. Traditionally, the web server handles compiling PHP scripts through integrated web server modules such as single user PHP (suPHP), Common Gateway Interface (CGI), or Dynamic Shared Object (DSO, also known as mod_php). When using these PHP handlers, the web server tightly couples to processing PHP scripts. The server compiles and executes the PHP scripts as part of the individual web server’s processes as it responds to website traffic. They execute using the web server processes’ permissions and ownership configurations. Running PHP this way provides a stable, mature means of using PHP scripts. However, PHP-FPM provides a new experience that addresses many of the shortcomings of the previously mentioned PHP handlers (suPHP, CGI, and DSO).
https://www.rise.company/forum/image...2018/06/67.png When using PHP-FPM, a separate service specifically designed for processing PHP scripts handles the task. Internally, PHP-FPM is organized as a “master process” managing pools of individual “worker processes.” When the web server has a request for a PHP script, the web server uses a proxy, FastCGI connection to forward the request to the PHP-FPM service. The PHP-FPM service can listen for these requests on the host server’s network ports or through Unix sockets. Although requests pass via a proxy connection, the PHP-FPM service must run on the same server as the web server. Notably, the proxy connection for PHP-FPM is not the same as a traditional proxy connection. As PHP-FPM receives a proxied connection, a free PHP-FPM worker accepts the web server’s request. PHP-FPM then compiles and executes the PHP script, sending the output back to the web server. Once a PHP-FPM worker finishes handling a request, the system releases the worker and waits for new requests.

The PHP-FPM master process dynamically creates and terminates worker processes -- within configurable limits -- as traffic to PHP scripts increases and decreases. The extra worker processes it spawns to handle increases in traffic terminate only after a set amount of time has passed, allowing the worker processes to remain available while increased traffic persists. Worker processes also periodically terminate and respawn after serving a fixed number of requests. This helps to prevent memory leaks during the processing of PHP scripts. Each PHP user can have its own separate pool of worker processes for handling PHP requests. Although this does increase some of the overhead of using PHP-FPM, the additional resource cost is negligible and well-offset by its other benefits.
PHP-FPM’s architecture shares design similarities with event-driven web servers such as the NGINX web server and the Apache web server with the Event Multi-Processing Module. Processing PHP scripts in this way allows for much higher processing performance, improved security, better stability, and greater configurability.

Performance

The primary performance benefits from using PHP-FPM are more efficient PHP handling and the ability to use opcode caching for PHP scripts.
As mentioned, PHP-FPM’s event-driven framework allows PHP scripts to use as much of the server’s available resources as necessary without the additional overhead that comes from running them inside of web server processes. PHP-FPM can reuse worker processes repeatedly instead of having to create and terminate them for every single PHP request. Although the cost of starting and terminating a new web server process for each request is relatively small, the overall expense quickly increases the web server begins to handle increasing amounts of traffic. PHP-FPM can serve more traffic than traditional PHP handlers while creating greater resource efficiency.
The largest performance improvement resulting from using PHP-FPM comes from enabling opcode caching for PHP scripts. When using opcode caching, the resulting opcode from compiled PHP scripts gets cached in memory (RAM). If a request comes in for a PHP script, PHP-FPM quickly checks for previously cached copies of the the script. When it finds a cached copy, PHP-FPM executes the script using the cached opcode immediately and continues processing the request.
This ability to immediately execute the opcode from memory removes the need for reading the script’s source code from disk and compiling the PHP source code to opcode. Reading data from the server’s memory is orders of magnitude quicker than reading the same data from the server’s filesystem. PHP-FPM also saves time and resources by not having to compile the PHP source code to opcode. As with starting and terminating processes, the cost and time to read a source code file and compile it may be relatively small on its own, but grows with additional instances. For example, when a system repeats those steps tens, hundreds, or even thousands of times a second, the aggregate cost can significantly impact the resource usage of a web server. Using opcode caching significantly improves the efficiency of processing PHP scripts, especially when processing large volumes of requests for PHP scripts.

Security

Enabling opcode caching while still maintaining isolated PHP processing for each user also provides an enormous security benefit of PHP-FPM over other PHP handlers. Opcode caching has no effect when using the suPHP and CGI handlers due to the way these handlers manage their memory usage. The DSO handler supports opcode caching, but the DSO module requires running PHP scripts as the Apache user, which can create a security risk. Using DSO may also require additional configuration to ensure that PHP scripts have the proper permissions to allow the Apache user to read them. There are solutions for this problem, but they usually involve installing additional server modules or relying on outdated technologies. By default, PHP-FPM provides opcode caching and isolated PHP script processing.
When using opcode caching, one must take care to configure PHP-FPM for security. For example, the server’s main PHP configuration file should have the following values set to true:
opcache.validate_root = true
opcache.validate_permission = true
These settings provide an additional layer of restriction that can prevent users from obtaining access to other users’ opcode caches. The main PHP-FPM configuration files contain the necessary settings for providing a secure use of PHP-FPM. These concerns apply primarily to multi-tenant hosting environments. For example, InMotion Hosting’s WordPress Hosting platform provides a multi-tenant hosting environment configured to provide a secure platform with PHP-FPM.

Stability

PHP-FPM’s architecture prevents PHP processing from overwhelming a server. When web servers handle requests for PHP scripts in their own processes, additional web server processes have to be created. As traffic for PHP scripts increases, web servers can quickly become overwhelmed, even to the point where the host server becomes unresponsive.
PHP-FPM can only serve as much traffic as it has worker processes to handle. When properly configured, this creates a relatively hard limit on how many requests for PHP scripts it can process at the same time through PHP-FPM. As PHP-FPM’s worker processes become fully utilized, additional requests for PHP scripts will result in timeouts or gateway errors from PHP-FPM. Instead of using up server resources waiting for a response, the web server will simply return a 503 or 504 HTTP status code. Although site visitors may not want to see 503 or 504 HTTP status codes, this behavior is far better than allowing the hosting server to become entirely unresponsive. Additionally, site owners can create custom 503 status pages to improve the user experience versus a non-descript white error page.
Although PHP-FPM’s architecture provides stability, when improperly configured PHP-FPM can become a bottleneck in processing PHP scripts. Properly configuring PHP-FPM to provide enough workers to process the amount of traffic that the web server can process remains key. Too few workers can result in excessive 503 or 504 HTTP responses, even though the web server is not experiencing high levels of traffic. This problem occurs more frequently with single-tenant servers running PHP-FPM with a single pool of worker processes for all websites, such as a virtual private server or a dedicated server. However, multi-tenant hosting environments with separate pools of worker processes also need to have a properly configured PHP-FPM in order to provide enough workers for each tenant’s web traffic.

Configurability

As a separate service, PHP-FPM provides more configuration options than other PHP handlers. Many of these configuration options can also be defined differently for each website on the server. Some of the options include but are not limited to:

• User for running scripts
• Group for running scripts
• Worker Limits
• PHP-FPM worker creation behavior
• Slow PHP script logging
• Status reports
• Connection settings (e.g. listening on network port or on Unix socket)
• PHP runtime configuration values

Users can finely tune PHP-FPM to provide superior performance for PHP websites over other PHP handlers lacking such configuration options. Unfortunately, properly configuring PHP-FPM can be relatively complex and involved. Users wishing to do so should consult a skilled systems administrator for configuration assistance should the hosting platform not provide a preconfigured version of PHP-FPM.
--------------------------------------------------------
How to Use PHP-FPM with cPanel

PHP performance is an enduring issue for web hosts. PHP is the most widely used server programming language on the web by a big margin. The most popular content management systems and ecommerce applications are written in PHP, including WordPress®, Joomla, Drupal, Magento®, and dozens more.
The ultra-fast PHP-FPM accelerates PHP execution on busy web servers, making it a valuable tool in the fight against slow sites and resource-constrained servers.
This article takes a deep dive into how PHP-FPM works and explains how to deploy and configure it with cPanel & WHM.
What is PHP-FPM?

PHP-FPM is an alternative PHP implementation that makes busy web applications faster while helping system administrators to control resource consumption on their server.
A PHP implementation, also known as the runtime, interprets and executes code. Traditional runtimes such as Apache’s mod_PHP do their work within the web server. That approach has advantages, but each connection consumes a chunk of the server’s resources for as long as it lasts. If there are too many concurrent connections, the server may run out of resources like memory altogether, impacting the performance of every site it hosts.
PHP-FPM does things differently: it operates outside of the web server and uses a pool of worker processes to execute code. The workers are ready and waiting when a request comes in, and you can control how many workers are in the pool so they can’t multiply until they consume all the server’s RAM and processor time.
It works like this:
https://www.rise.company/forum/image...2020/04/89.png

• Apache sends code to PHP-FPM over a high-speed binary interface called FastCGI.
• A supervisor process chooses a worker process from the pool and gives it the code.
• The worker executes the code, and the result is sent back to Apache, which sends it to the web browser.
• Once the worker is done, it returns to the pool to await another chunk of code to execute.

If there are too many concurrent connections, some might have to wait for a free worker, but they will never consume all of the server’s resources. On a busy web server, worker pools are faster and more efficient than other strategies.
Getting Started with PHP-FPM in CentOS and EasyApache

It is straightforward to activate and configure PHP-FPM in cPanel & WHM. You can choose which domains use it and set configuration variables that influence its behavior.
The first step is to turn it on in the System PHP-FPM settings in WHM’s MutliPHP Manager.
https://www.rise.company/forum/image...2020/04/90.png When you click Turn On, WHM makes PHP-FPM available, but it doesn’t activate it for all domains automatically. You can force all accounts on the server to use PHP-FPM by clicking Convert All Accounts to PHP-FPM.
https://www.rise.company/forum/image...2020/04/91.png Alternatively, you can activate PHP-FPM for individual domains in the table at the bottom of this page. To turn it on for several domains at once, select them in the table and choose On in the drop-down menu.
https://www.rise.company/forum/image...2020/04/92.png Configuring PHP-FPM in cPanel

Once you have activated PHP-FPM, you can configure both the system defaults and the settings for individual domains in MultiPHP Manager.
Click the System PHP-FPM Configuration tab.
https://www.rise.company/forum/image...2020/04/93.png In this section, there are three pool settings you can change. These are the default values that are applied to domain pools.

• Max Requests: The number of requests each worker process should execute before it restarts itself. This setting is useful for working around memory leaks. The default of 20 is acceptable for most web hosting scenarios, but you may want to increase it to between 40 and 60 on servers with heavy traffic.
• Process Idle Timeout: How long an idle worker process will wait before shutting down. Idle processes consume resources, so we don’t want too many hanging around, but we don’t want to kill them too soon because it takes a while to start new ones. The default of 10 (seconds) may be too low for a busy server.
• Max Children: The maximum number of worker processes in each pool. The default is 5.

Many factors affect the optimal values for these settings, including the code your server runs and the amount of RAM it has. We wrote PHP-FPM Performance Tuning Basicsto help you decide on the correct values for your server.
https://www.rise.company/forum/image...2020/04/94.png Underneath the pool options are PHP INI directives. We surface several of the most useful in the interface, and you can find more information about them in PHP’s Runtime Configuration documentation. We’ll show you how to add other directives in the next section.
In addition to system-wide configuration, you can also configure individual domains in the WHM interface.
https://www.rise.company/forum/image...2020/04/95.png In the table at the bottom of MutliPHP Manager, click Edit PHP-FPM at the end of the domain’s row. The options that appear are identical to those in the system-wide configuration interface.
https://www.rise.company/forum/image...2020/04/96.png How the cPanel PHP-FPM Module Works

Although the WHM interface contains the most useful configuration options, there are many more in the documentation. To add or modify them, you will need to edit configuration files on the server’s command line or in the cPanel & WHM File Manager.
The two most important system-wide configuration files are:

• /var/cpanel/ApachePHPFPM/system.yaml
• /var/cpanel/ApachePHPFPM/system_pool_defaults.yaml

WHM doesn’t create these files because the system doesn’t need them, but you can create them yourself and add directives to override the defaults.
touch /var/cpanel/ApachePHPFPM/system.yaml
touch /var/cpanel/ApachePHPFPM/system_pool_defaults.yaml You may also have to create the directory with:
mkdir -p /var/cpanel/ApachePHPFPM/ In these files, enter only directives that differ from and override the system directives. For example, if you wanted to change the emergency_restart_threshold directive from the default of 0, the system_pool_defaults.yaml file would look like this:
https://www.rise.company/forum/image...2020/04/97.png The three dashes at the top of the file (———) are part of the YAML markup language and must be present. The configuration file won’t work without them.
In the PHP documentation, you will find directives formatted with periods (.) and other symbols; syslog.facility,for example. When adding directives to configuration files, these symbols must be replaced with an underscore (_). For example, instead of syslog.facility, use syslog_facility.
You can learn more about configuring the cPanel PHP-FPM module in Configuration Values of PHP-FPM and PHP-FPM Code and FileSystem Layout for EasyApache 4.
Creating User Pools in PHP-FPM

Finally, we’ll look at manually creating and configuring domain-specific user pools in PHP-FPM. These are the worker pools used by sites hosted on your server’s domains.
The PHP-FPM module creates a worker pool for a domain if it finds a configuration file in:
/var/cpanel/userdata/[user]/[domain].php_fpm.yaml Replace [user] and [domain] with the relevant values for your server. You can create this file or activate PHP-FPM for a domain in WHM and it will be created automatically.
https://www.rise.company/forum/image...2020/04/98.png At a minimum, the file must contain the following information:
As with the system files, you can add directives to configure the user pools. After creating or editing the .yaml file, run the following command:
/scripts/php_fpm_config – rebuild
The script adds directives to Apache’s config file and restarts PHP-FPM, after which the new pool will be up and running. You can find more information about creating user pools in PHP-FPM User Pools.
Easy PHP-FPM Configuration with cPanel & WHM

PHP-FPM gives busy web servers a huge performance boost. Just as important, it helps web hosts to make the most of limited server resources, reducing the cost of providing an excellent hosting experience to clients and their users.
With cPanel & WHM, PHP-FPM can be activated in seconds and configured in an intuitive interface. If you need to dig deeper into PHP directives, our module makes building custom configurations for the runtime and worker pools straightforward.


شاهد ايضا :

مميزات / فائدة php fpm pool مواقع اسرع | حماية اعلي | لود اقل advantages
مميزات / فائدة php fpm pool لمواقع ويب / ووردبريس اسرع 300% Speed