Comment comprendre la charge d'un serveur web Apache

[nicocolt]

Bonjour,

J'essaye de calculer la charge que reçoit mon serveur web, et je me pose la question suivante:

Qu'est-ce qui charge le plus le serveur web, les connections ou les requêtes faites à l'intérieur d'une connexion ?

J'ai essayé de faire quelques calculs et voici ce que j'en déduis:
Pour ma compréhension, j’ai 300000 visites par jour sur mon-site.fr. Un GET sur mon-site.fr implique 100 GET sur ce même domaine pour récupérer l’ensemble des ressources.
Par seconde, j’ai donc 300000/24/3600 = 3,5 visites par seconde. Donc 3,5*100 requêtes = 350 requêtes/seconde en moyenne.
Si mon keepalive est à on, j'ai par seconde 3,5 connections et 350 requêtes, c'est bien cela ? Et ce qui charge alors mon serveur web c'est bien le nombre de requêtes ?

Merci de m'éclairer
Nico

 

[Bool]

Bonjour,

si seulement c'était si simple ! Mais soit, tu as 300'000 visites, c'est à dire en moyenne 3.5 visites par seconde. Et de ce que tu indiques, une visite impliquerait N pages de M hits, si bien que N*M = 100, c'est ça ? Auquel cas on arrive à 350 hits par seconde en moyenne.

Le problème, c'est que c'est une grosse approximation : le trafic est rarement lisse sur un site, donc il y a fort à parier qu'en période de pointe tu montes à 10 visites par seconde, voir plus. Mais de leur coté, les navigateurs mettent généralement en cache les fichiers statiques, donc tu auras en pratique nettement moins de 100 hits par visites.

Maintenant pour extrapoler ça en connexions simultanées, c'est une toute autre histoire. Pour le coup ça dépend du parallélisme du navigateur, du temps de réponse du serveur HTTP, de la construction des pages (position de l'inclusion du JS typiquement), et de la vitesse de téléchargement des internautes. On pourrait également ajouter l'age du capitaine, que ne serait pas moins flou.

Et quand bien même tu connaîtrais ton nombre de connexions simultanées, l'impact sur le serveur va aussi dépendre du logiciel utilisé, de sa version, de l'utilisation de chiffrage ou non, du firewall, et arrivé à un certain point, de la carte réseau (et son driver), de la version du kernel (et sa configuration).

Bref, on est guère avancés avec tout ça. Du coup, que cherches-tu réellement à savoir ?

 

[nicocolt]

Merci pour ces informations !

Oui c'est bien ça, N pages de M hits égal à 100. Ce que j'essaye de faire c'est de paramétrer le serveur web (mpm_prefork) de telle manière à ce qu'il puisse absorber le trafic sans plantage. Aussi, ayant le nombre moyen de hits sur chaque page, je suis en mesure de connaître le nombre de requêtes par utilisateur. J'entends bien que ce n'est pas exact car je ne sais pas quelles pages va visiter l'utilisateur ni même la conf réseau et j'en passe, mais ne sachant pas sur quels chiffres me baser pour faire mes calculs, je suis parti de ces hypothèses. Peut être existe t-il des abaques qui permettrait de déterminer la conf pour un certain nombre de visiteurs ?

Merci d'avance
Nico

 

[Bool]

Alors du coup c'est beaucoup plus simple : quoi que tu fasses, le MPM «prefork» absorbe très mal la charge justement. Suffit de le remplacer par le MPM «event» (accompagné de fCGI pour la partie dynamique), et ça encaisse toute de suite beaucoup mieux.
Le MPM «prefork» est en effet très sensible au nombre de connexions simultanées, qui consomment énormément de ressources pour pas grand chose.

Plutôt que d'essayer de le tuner dans tous les sens, je recommande plutôt de s'en débarrasser au profit d'une solution plus moderne, ou bien de le protéger via une solution plus légère en amont, type NginX. NginX se chargerait alors de la partie réseau, de la compression à la volée, ainsi que des fichiers statiques, laissant à Apache la gestion des rewriting et scripts dynamiques.

 

[nicocolt]

merci.

Le tout est de comprendre comment configurer le mpm event et le fcgid tout ça derrière un nginx sur une machine de production
Les params de l'event sont les même que le prefork. Mais je sais pas trop quoi mettre pour le prefork, et pas plus pour l'event...
Après pour le nginx ça doit pas être sorcier je pense. Il faut le configurer en rp et activer les options de compression. Je ne sais pas en revanche comment le faire servir les ressources statiques uniquement.

Merci d'avance pour les conseils.
Nico

 

[Bool]

En supposant que tu utilises une Debian, et que ton Apache est déjà configuré, ce n'est pas très compliqué.

On remplace d'abord les paquets classiques :

aptitude install apache2-mpm-event apache2-mpm-prefork- libapache2-mod-fcgid php5-cgi libapache2-mod-php5-

puis dans /etc/apache2/mods-available/fcgid.conf faut associer les scripts .php à un binaire, genre :

AddHandler fcgid-script .php
FCGIWrapper /usr/bin/php5-cgi .php

Ne restera plus qu'à ajouter le ExecCGI sur la ligne «Options» des différents sites.

Par exemple :

Options -Indexes FollowSymLinks ExecCGI

À noter que le fichier de conf utilisé pour PHP dans ce cas n'est plus /etc/php5/apache2/php.ini mais /etc/php5/cgi/php.ini. Donc à ajuster si nécessaire.

 

[nicocolt]

Super

Mais pourquoi doit-on utiliser le fcgid pour php ?

Merci d'avance
Nico

 

[Bool]

Pour permettre à Apache de tourner avec un MPM moderne, utilisant des threads et gérant correctement les keepAlive (via event). Tant que PHP est agglutiné à Apache en temps que module, ce n'est pas possible.

De plus, ainsi tu limites les process PHP à des process «utiles» uniquement, t'as pas les centaines de process qu'on retrouve avec Apache prefork, ce qui du coup ouvre la voie des connexions persistantes pour MySQL, memcache, et autres. Bref, en terme de ressources c'est beaucoup mieux.

 

[nicocolt]

Hum ok, c'est peut être aussi pour ça que mes processus apache enfants consomment du cpu également...

Je vais indiquer dans le thread les valeurs pour le prefork que j'ai actuellement, je pense que pour l'event c'est les mêmes paramètres

Merci,
Nico

 

[Bool]

Les besoins ne sont pas les mêmes non. Je prends le cas d'un de mes serveurs, là tout de suite j'ai :
- 11064 connexions ouvertes (= socket connectés)
- dont 10595 connexions en keep-alive, soit 469 connexions «utiles»
- c'est à dire 401 connexions en cours de lecture de la requête du client, et 68 connexions en cours de traitement.
- pour ces 68 connexions en cours de traitement, j'ai 36 process PHP qui bossent (les 32 autres connexions sont donc des fichiers statiques)

Pour schématiser, j'ai donc : 11064 sockets → 469 requêtes HTTP → 36 process PHP
Avec un Apache prefork, il faudrait 11064 process Apache-PHP pour obtenir le même résultat... ce qui évidemment ne tiendrait pas.
Toujours dans ce même cas, un Apache event de 500 threads suffirait... et il se chargerait de lancer les 36 process PHP nécessaires.

Pour simplifier : les besoins d'un Apache event sont très similaires à ceux d'un Apache prefork sur lequel tu aurais désactivé le keep-alive... excepté que cette fois c'est rapide.

 

[nicocolt]

Oui, en clair on peut minimiser les paramètres pour l'event par rapport au prefork.

Mais quel outil utilises tu pour détailler de la sorte tes connexions en live ?

Merci
Nico

 

[Bool]

Les sockets ouverts :

netstat -pan | grep ESTABLISHED | grep -c :80

L'utilisation Apache, si mod-status installé :

/bin/nc localhost 80 -w 15 -q 15 <<EOF
GET /server-status?auto HTTP/1.0
Host: localhost

EOF

Les process PHP :

pgrep -c php5-cgi

 

[nicocolt]

Pinaise c'est magique ça

Je vais essayer ça en début de soirée. /bin/nc, c'est un utilitaire que tu as ajouté ?

Merci
Nico

 

[Bool]

C'est «netcat», souvent présent par défaut. Note que cet «apache status» est aussi accessible via un navigateur (ou lynx en local)

 

[nicocolt]

J'ai testé un peu tout ça

J'accède au server-status par le navigateur, via localhost, l'accès est refusé, faudrait que je modifie ça dans la conf du module server-status. Je n'ai aucun mode keep-alive, mais il me semble que le keep-alive est à off, normal donc.

Pour le php, comme je suis en prefork, du coup ça doit être php5 tout court et non pas php5-cgi, le total est à 0, du coup pas de process php qui bosse. Ca me semble bizarre mais bon...

Voici la conf du prefork de mon côté:

<IfModule mpm_prefork_module>
StartServers 15
MinSpareServers 5
MaxSpareServers 25
MaxClients 256
MaxRequestsPerChild 100
</IfModule>

Merci !
Nico

 

[Bool]

Ton PHP est en module Apache, il est donc indissociable d'Apache : pgrep -c apache2 ou pgrep -c httpd, selon les systèmes.

 

[nicocolt]

Ok, donc on peut pas le voir en effet.

Va falloir que je regarde pour passer en event, en espérant ne pas plomber le site trop longtemps.

Merci !
Nico

 

[nicocolt]

En supposant que tu utilises une Debian, et que ton Apache est déjà configuré, ce n'est pas très compliqué.

On remplace d'abord les paquets classiques :

aptitude install apache2-mpm-event apache2-mpm-prefork- libapache2-mod-fcgid php5-cgi libapache2-mod-php5-

puis dans /etc/apache2/mods-available/fcgid.conf faut associer les scripts .php à un binaire, genre :

AddHandler fcgid-script .php
FCGIWrapper /usr/bin/php5-cgi .php

Ne restera plus qu'à ajouter le ExecCGI sur la ligne «Options» des différents sites.

Par exemple :

Options -Indexes FollowSymLinks ExecCGI

À noter que le fichier de conf utilisé pour PHP dans ce cas n'est plus /etc/php5/apache2/php.ini mais /etc/php5/cgi/php.ini. Donc à ajuster si nécessaire.

Salut !

Bon, j'ai testé sur une de mes machines de dev, le switch de prefork vers event avec PHP en mode CGI. Le soucis est que le paquet libapache2-mod-php5 dépend de apache2-mpm-prefork. Et ce dernier ne peut pas être installé avec apache2-mpm-event

Du coup je suis un peu perdu

Merci de ton aide
Nico

 

[Bool]

D'où le :

aptitude install apache2-mpm-event apache2-mpm-prefork- libapache2-mod-fcgid php5-cgi libapache2-mod-php5-

Qui :
* installe : apache2-mpm-event libapache2-mod-fcgid php5-cgi
* enlève : apache2-mpm-prefork libapache2-mod-php5

 

[nicocolt]

Peuchère, je vais aller me coucher, j'ai zappé le pitit moins à coté de libapache2-mod-php5

Milles excuses
Je reviens ici dès que j'ai avancé un peu plus

Merci
Nico

 

[nicocolt]

[RESOLU] Re: Comment comprendre la charge d'un serveur web Apache

Salut bool !

Bon bé ça marche impeccable sur mon poste de dev Faut maintenant que je vois avec le principal intéressé pour faire le basculement.

Merci beaucoup en tout cas pour toutes ces explications !
Nico

 

[Bool]

Et bien, content que ça ait pu t'aider !

 

[nicocolt]

Salut Bool

Je viens de trouver une nouvelle question à laquelle je n'ai pas la réponse, c'est par rapport à ton message que voici:

Les besoins ne sont pas les mêmes non. Je prends le cas d'un de mes serveurs, là tout de suite j'ai :
- 11064 connexions ouvertes (= socket connectés)
- dont 10595 connexions en keep-alive, soit 469 connexions «utiles»
- c'est à dire 401 connexions en cours de lecture de la requête du client, et 68 connexions en cours de traitement.
- pour ces 68 connexions en cours de traitement, j'ai 36 process PHP qui bossent (les 32 autres connexions sont donc des fichiers statiques)

Pour schématiser, j'ai donc : 11064 sockets → 469 requêtes HTTP → 36 process PHP
Avec un Apache prefork, il faudrait 11064 process Apache-PHP pour obtenir le même résultat... ce qui évidemment ne tiendrait pas.
Toujours dans ce même cas, un Apache event de 500 threads suffirait... et il se chargerait de lancer les 36 process PHP nécessaires.

Pour simplifier : les besoins d'un Apache event sont très similaires à ceux d'un Apache prefork sur lequel tu aurais désactivé le keep-alive... excepté que cette fois c'est rapide.

Les 11064 sockets connectés, tu dis qu'il faudrait 11064 process Apache-PHP. Le process Apache-PHP, c'est au sens process système, genre:

14661 www-data  20   0 75468 2956 1260 S    0  0.1   0:00.00 apache2

?

Un process système n'est-il pas en mesure de traiter plusieurs connections (sockets) simultanées ?

Merci de ton aide,
Nico

 

[Bool]

Hello,

Un process système n'est-il pas en mesure de traiter plusieurs connections (sockets) simultanées ?

Bien sûr que si. C'est d'ailleurs le cas du MPM Event d'Apache... mais le principe du MPM Prefork c'est justement d'avoir un process par connexion, même si elle est inactive (keepalive).

 

[nicocolt]

Ah oui en effet.
Donc
event : plusieurs connexions par process système (keep alive ou pas)
Prefork : une seule connexion par process système (keep alive ou pas)

Question hors sujet: peux tu meut me communiquer l'url de ton site qui génère 11000 connections simultanées ? Le sujet doit être vraiment intéressant !

Merci
Nico

 

[ZW3B]

Question hors sujet: peux tu meut me communiquer l'url de ton site qui génère 11000 connections simultanées ? Le sujet doit être vraiment intéressant !

Bonjour, ouais, çà doit être intéressant 11 ans après, votre site est toujours en ligne/production ? Envoyez l'adresse !

Moi mon serveur est en surcharge, j'en ai marre !!

J'essaie de comprendre la bonne valeur à définir dans loadfactor (Facteur de charge) de BalancerMember de ApacheProxyReverse.

J'ai configuré comme cela : Apache2 reverse_proxy && mod_proxy_hcheck

LoadBalancer Status for balancer://zw3bcluster [p222c8df5_zw3bcluster]​

MaxMembers	StickySession	DisableFailover	Timeout	FailoverAttempts	Method	Path	Active
2 [2 Used]	ROUTEID	Off	0	1	bybusyness	/	Yes

Worker URL	Route	RouteRedir	Factor	Set	Status	Elected	Busy	Load	To	From	HC Method	HC Interval	Passes	Fails	HC uri	HC Expr
https://10.101.150.10			1.00	0	Init Ok	3	0	-100	6.5K	2.5K	HEAD	10000ms	1 (0)	1 (0)		ok234
https://10.105.150.10			1.00	0	Init Ok	1	0	100	2.2K	218	TCP	5000ms	2 (0)	3 (0)

---

Health check cond. expressions:
Expr name	Expression
ok234	%{REQUEST_STATUS} =~ /^[234]/
gdown	%{REQUEST_STATUS} =~ /^[5]/
in_maint	hc('body') !~ /Under maintenance/

 

[pomination]

Le loadfactor est une pondération. Si les serveurs membres de la répartition de charge sont identiques, il n'y a pas lieu d'indiquer un facteur de charge.
Si en revanche les configs matérielles sont différentes et qu'un serveur est beaucoup plus puissant, on viendra alors augmenter son facteur de charge et diminuer celui des serveurs moins puissants.

C'est à adapter en fonction de l'analyse des résultats après modification des facteurs de charge.
Il faut aussi prendre en compte la présence de sessions ou non. Si un utilisateur, une fois en session, doit rester sur le même noeud, alors la charge ne sera jamais complètement répartie.