Jelastic Cloud Inside View – Smart Resources Auto Configuration for PHP

By Tetiana Markova | May 28, 2015

The Jelastic Platform is characterized with one of the best dynamic resources orchestration for cloud services, and its benefits have already been described many times (for example, in this article you can see how this applies to pricing). Though this mechanism is highly efficient by itself, but being combined with and tightly complemented by the basic application servers’ memory organization, it can bring even more profit.

Thus today we’d like to reveal how this integral Jelastic feature helps to optimize the productivity of PHP applications with the dynamically changing amount of resources (made possible due to the versatile combination of the automatic horizontal and vertical scaling). In the most common case, it works in the following manner: when the number of allocated resources (i.e. cloudlets) for your environment is changed, Jelastic instantly adjusts the corresponding server’s directives to suit the new conditions. Below, we’ll show you this in detail through covering the following questions:

which PHP settings are affected?
how does the optimization work?
how can the Jelastic Auto Configuration be disabled?

Now let’s discover this step-by-step!

Auto Adjustable Settings

The first thing you need to learn is the parameters, that are automatically configured by Jelastic – this will give you a better understanding. As our platform provides a choice of two application servers for your PHP apps’ hosting, we’ll consider the appropriate settings for both of them, starting with Apache.

Apache

Dynamic requests’ handling in Apache is implemented using the prefork Multi-Processing Module (MPM), which helps to fully reveal the server potential at the Cloud. The used MPM directives are stored in the main Apache configuration file – httpd.conf, that is located in the conf folder.

list 1

Here is a complete list of parameters, which are configured by Jelastic automatically, based on the amount of allocated resources:

StartServers parameter sets the number of child processes, that should be initiated at a server’s startup.

If you’d like to state your custom value, note: The amount of child processes depends on the load and are not bound to their initial number, set by the current parameter. So there is usually little reason to adjust it.

ServerLimit – this parameter sets the maximum possible value of the MaxClients directive (see its description below) for the lifetime of the server. If you try to state the MaxClients parameter higher than this limit, it will be dropped down to the ServerLimit value.

If you’d like to state your custom value, note: stating ServerLimit to a value, that is much higher than necessary, will cause allocation of the extra, unused shared memory, while stating it too low won’t reveal the full server performance potential.

MaxClients directive sets the maximum number of child processes, that can be launched simultaneously for serving the requests. Any connection attempt over the MaxClients limit will normally be queued, for being consequently picked up and processed, once one of the child processes has finished handling another request.

If you’d like to state your custom value, note: MaxClients should be big enough to handle as many simultaneous requests as you expect to receive, and small enough to ensure that there is enough RAM for the number of clients’ processes you’ve stated. Pay attention, that this value is limited by a ServerLimit parameter, and if both of them are set higher than the system can handle, your Apache server may become unstable.

Within the Jelastic implementation, values for the above described settings are calculated automatically, based on the maximum amount of available resources (dynamic cloudlets). Below, you can find the table with these parameters’ default values for a few main environment RAM levels:

apache_table

Now, let’s learn about the similar NGINX-PHP directives.

NGINX-PHP

Handling of requests in the NGINX-PHP application server is managed by FastCGI Process Manager (FPM). Its main configuration file is php-fpm.conf, located inside the etc folder.

nginx fpm

FPM can work in either dynamic or static mode, enabled according to the pm directive’s value. By default, it is equal to dynamic, which allows Jelastic to configure other related parameters due to the amount of allocated environment resources:

pm.max_children – it has different meanings for the static and dynamic process manager state. In the first case, it defines the number of child processes to be created at the server’s start (which won’t be changed anyway), and in the second one – the maximum number of child processes, that are allowed to be created (as their amount will subsequently scale up, if required).

If you’d like to state your custom value, note: This directive is mandatory. Its value should be big enough to handle such amounts of simultaneous requests as you expect to receive, and small enough to ensure that there is enough RAM for the number of child processes you’ve stated, otherwise the server may become unstable.

pm.start_servers – states the number of child processes, created on server’s startup. It is used only with the dynamic pm value, since for the static process manager mode, all of the children processes (where the amount is stated within the pm.max_children parameter) are loaded at once. If this directive is not set, the default value will be used, which is calculated due to the next formula (the appropriate values can be found within the same configuration file):
pm.min_spare_servers + (pm.max_spare_servers – pm.min_spare_servers) / 2

If you’d like to state your custom value, note: The actual amount of child processes depends on the load and is not bound to their initial number, set by the current parameter. So there is usually little reason to adjust it.

pm.max_spare_servers – sets the desired maximum number of idle (waiting) server processes. Such processes can quickly react on the received requests and process them almost immediately, skipping the regularly needed time of initiating a new operation. After the request is handled, the appropriate child process returns to the waiting state (nevertheless, if the overall number of idle processes becomes greater than the pm.max_spare_servers value, then it will be killed).

If you’d like to state your custom value, note: This directive is used only when the pm mode is set to dynamic and is mandatory. It acts in a bundle with the similar pm.min_spare_servers directive, which is located just up the file and sets the minimum number of child processes in the idle state. So if the amount of spare processes becomes less than this number, then some new ones will be created.

Within the Jelastic implementation, values for these settings are calculated automatically, based on the maximum amount of available resources (dynamic cloudlets). Below you can find the table with these parameters’ default values for a few main environment RAM levels:

nginx_table

Great! Now, when you know the role of each of the directives used in the PHP dynamic memory organization, we can proceed to examination of the Jelastic Auto Configuration workflow.

How the PHP Auto Configuration Works

You can check how the abovementioned parameters are changed depending on the amount of resources you set. The process is almost the same for both application servers, so let’s consider it on the example of Apache:

1. Create a new PHP environment with the Apache application server inside (if you don’t have one).

Then, click the Config button for this node and find the conf > httpd.conf file through the opened tab.

apache 16

Scroll down approximately to the 100th line and remember the values of the directives, used for Jelastic automatic optimization (circled in the image above), and the maximum scaling limit for the server (i.e. dynamic cloudlets number, can be seen in the Usage dashboard column, 16 in our case).

2. Now, with the help of the same-named button, access the Change environment topology wizard and set some other amount of resources for your Apache server (in our case we increased it to 32 cloudlets). Then repeat the operations from the first point (i.e. find and compare the directive values you got with the ones from the previous step).

apache 32

As a result of this comparison, we can conclude that parameter values increased automatically simply due to a higher amount of available resources allocated. Similar to this, upon stating a lower amount of resources, these parameters’ values will be reduced.

That’s how the automatic optimization works! However, if you are an experienced user and would like to change these parameters for your custom needs, Jelastic gives you such an opportunity.

Disable Automatic Jelastic Optimization

To state your custom values for the automatically configured directives described above, at first you’ll need to disable the automatic Jelastic optimization, in order not to lose the performed changes during the update.

Note that inappropriate directive values may cause your server instability, so before proceeding, please see the recommended settings within the corresponding article sections above. Remember that you are doing this at your own risk.

The process is almost the same for both PHP servers – you just need to remove the line with the Jelastic optimization mark at the beginning of the corresponding configuration file:

for Apache: # Jelastic autoconfiguration mark – inside the conf > httpd.conf file

for NGINX-PHP: ; Jelastic autoconfiguration mark – inside the etc > php-fpm.conf file

After the corresponding string is deleted, the auto configurable parameters’ values won’t be reset by the Jelastic optimization mechanism, thus your custom ones can be stated and used by the application server. Just don’t forget to Save the file in order to apply the new configurations.

That’s all for today! If you still have questions or would like to leave a suggestion – feel free to post it to the comments below. You can also examine all of the benefits that Jelastic Cloud smart memory organization delivers by signing up for a free two-week trial.