httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaƫl <raphael.d...@gmail.com>
Subject [users@httpd] resources prioritization/scheduler (app vs assets)
Date Sat, 10 Dec 2016 14:22:48 GMT
Hi,

I've a question on how to prioritize traffic in order to optimize
the service in the case of traffic bursts:


Context:
* a server with finite resources (let's say 1 GB mem)
* a PHP application: initial page load needs 100 MB (index.php)
* for each page load (index.php) approx:
  * ~ 40 subsequent assets (static files) are needed 
  * serving assets is, obviously, quicker than serving index.php
* I assume, and decide, that PHP-FPM must not use more than 700MB
* I want to avoid "broken" pages (missing assets/images/...) as much as possible


Thus PHP-FPM is configured to not allow no more than 7 children.
The Apache MaxRequestWorkers (worker MPM) is set to be strictly superior than
7*40 (lets say 350) 


Now imagine a traffic burst with 200 distinct clients simultaneously
hitting the main page (wow!)
They now occupy 57% of the Apache workers, 193 of them waiting for a
PHP-FPM child. (<Proxy> "max" default value being ThreadsPerChild)

... some hundreds milliseconds later...

The 7 first clients having been served, each one now requests 40 more assets.
And the situation is then as follows:

* 7 hits on index.php were already processed successfully
* 7 currently being processed by PHP-FPM (still occupying Apache workers)
* 186 queued Apache workers hits /index.php, waiting for PHP-FPM/proxy-fcgi
* 7*40 = 280 new hits for assets (subsequent resources needed by the 7 first clients)
   * 157 of them immediately get an available Apache worker and can be
     served (157+186+7 == 350)
   * >>>>>>>  123 assets will NOT get an available worker  <<<<<<<
PROBLEM HERE


In the "best" case these 123 requests, which should have been served
*now*, will end up in the ListenBackLog and wait the 157 first assets to
be served first and liberate their workers.

The server works virtually *as* if only 350-200 = 150 workers were
available (150 being < 280, which is the typical workers implication
for 7 pages-load)

200 being the (unpredictable/variable) "intensity" of the burst, I would
like to know of a better way to handle such a situation.


The first ideas that come to mind is service shaping (prioritization/quotas):
How to make Apache only accept 1/40 of the traffic to the fcgi php-fpm proxy.
Sample heuristic:
> If all worker are used (350/350), we "compute" which proportion is
> dedicated to index.php. If it's superior to a given configurable
> threshold, then free some of the workers dedicated to this resources
> in order to accept assets-directed resources.


I'm curious about possible solutions.
Thank you for reading.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message