Charge d'un script PHP

Mon hébergeur dit que mon script PHP prend trop de ressources.
Y a-t-il une façon simple de le savoir ?

Euh... déjà, il faudrait savoir quel genre de ressources est consommé
en excés par le script, et ça, seul l'hébergeur pourrait le dire :
ressources mémoire, disque, CPU, connexions HTTP, accès à une base de
données, autre ?

[ description « en gros » du script ]

Bon, d'une part on ne peut strictement rien dire avant d'avoir la
réponse à la première question que je posais, et même quand on le
saura je ne suis pas sûr que cette description « en gros » puisse
nous servir à quoi que ce soit (peut-être que si, ça dépend, mais
réponds déjà à la première question).

Bonjour,

Mon hébergeur dit que mon script PHP prend trop de ressources.
ah, j'ai déjà entendu ça quelque part...

Y a-t-il une façon simple de le savoir ?
Quelle version de PHP, compilée comment, et surtout : quel type de

ressources ?

Ce script contient un mécanisme pour bloquer un éventuel visiteur
qui abuserait (trop de visites par minute, heure ou jour par
exemple). Ce blocage se fait en remplaçant le contenu affiché.

C'est sûr que si l'anti abus bouffe plus de ressources que de laisser
faire les abus éventuels... Y'a déjà des modules apache (mod_throttle par
exemple si ma mémoire est bonne) qui font ça très bien.

a++;
JG

Le 21 Dec 2006 23:10:14 GMT, Olivier Miakinen <om+news@miakinen.net>
écrivait dans fr.comp.lang.php:

Mon hébergeur dit que mon script PHP prend trop de ressources.
Y a-t-il une façon simple de le savoir ?

Euh... déjà, il faudrait savoir quel genre de ressources est consommé
en excés par le script, et ça, seul l'hébergeur pourrait le dire :
ressources mémoire, disque, CPU, connexions HTTP, accès à une base de
données, autre ?

Voici un extrait du message annoncçant l'abus (j'ai enlevé
le nom du domaine qui ne devrait pas intervenir dans la nature
du problème).

Resource Usage from Monitoring Daemon:
10.71 11.88 0.0
Top Process %CPU 10.8 httpd [/quebec-genealogy/003/058.php]
Top Process %CPU 8.7 httpd [/favicon.ico]


You have exceeded the maximum allowable resources usage (8% for CPU or
Memory) for any shared hosting account stated above. This limit is set
to ensure that all domains on the server receive a fair share of the
server resources.

Donc, essentiellement, trop de temps de calcul. Ici, je ne suis pas
certain de comprendre. Je pensais que PHP exécutait un seul script
à la fois.

[ description « en gros » du script ]

Bon, d'une part on ne peut strictement rien dire avant d'avoir la
réponse à la première question que je posais, et même quand on le
saura je ne suis pas sûr que cette description « en gros » puisse
nous servir à quoi que ce soit (peut-être que si, ça dépend, mais
réponds déjà à la première question).

À mon message précédent, j'ajoute que le code inclus fait autour
de 160 lignes. Je pourrais l'optimiser en otant la limite par
minute, mais je n'ai aucune idée du comportement normal et je ne
sais pas quoi mesurer sinon le nombre de microsecondes entre le
début et la fin d'un script. Et encore, je ne suis pas certain
que ce soit une mesure très fiable puisque le système est en
temps partagé (c'est un Linux).

En fouillant dans php.net, il y a cette page
http://ca3.php.net/manual/fr/ref.win32ps.php
mais c'est pour Windows Server/NT/XP.

Si je cherche CPU, je ne vois rien d'autres. PS trouve PostScript.


Denis

Le 21 Dec 2006 23:10:14 GMT, John GALLET <john.gallet@wanadoo.fr>
écrivait dans fr.comp.lang.php:

Bonjour,

Mon hébergeur dit que mon script PHP prend trop de ressources.
ah, j'ai déjà entendu ça quelque part...

Y a-t-il une façon simple de le savoir ?
Quelle version de PHP, compilée comment, et surtout : quel type de

ressources ?

PHP Version 4.4.4, serveur Apache/1.3.37, sur Linux mais je ne vois
pas lequel.

compilée comment ? Tu veux la liste complète des options ? Elle
fait 11 lignes mais je ne suis pas certain que ce soit utile.

Quant au type de ressource, un extrait du message (j'ai enlevé
le nom du domaine qui ne devrait pas intervenir dans la nature
du problème).

Resource Usage from Monitoring Daemon:
10.71 11.88 0.0
Top Process %CPU 10.8 httpd [/quebec-genealogy/003/058.php]
Top Process %CPU 8.7 httpd [/favicon.ico]


You have exceeded the maximum allowable resources usage (8% for CPU or
Memory) for any shared hosting account stated above. This limit is set
to ensure that all domains on the server receive a fair share of the
server resources.

Donc, essentiellement, trop de temps de calcul. Ici, je ne suis pas
certain de comprendre. Je pensais que PHP exécutait un seul script
à la fois.

Ce script contient un mécanisme pour bloquer un éventuel visiteur
qui abuserait (trop de visites par minute, heure ou jour par
exemple). Ce blocage se fait en remplaçant le contenu affiché.

C'est sûr que si l'anti abus bouffe plus de ressources que de laisser
faire les abus éventuels... Y'a déjà des modules apache (mod_throttle par
exemple si ma mémoire est bonne) qui font ça très bien.

mod_throttle n'est pas dans la liste des modules installés.

Un abus, c'est quand un aspirateur de site va recopier 40 000 pages
(le contenu complet). Quand j'ai installé mon site, il y avait eu
2 de ces abus en un mois (c'est ce qui m'a incité à installer ce
mécanisme de protection).

Mon mécanisme n'est pourtant pas si affamé il me semble. D'après les
stats, à l'heure la plus occupée, la moyenne est de 9 pages lues
par minute. Le code inclus fait environ 160 lignes de PHP et il y a
plusieurs variables de session $_SESSION.


Denis

Euh... déjà, il faudrait savoir quel genre de ressources est consommé
en excés par le script, et ça, seul l'hébergeur pourrait le dire :
ressources mémoire, disque, CPU, connexions HTTP, accès à une base de
données, autre ?

[...]

Top Process %CPU 10.8 httpd [/quebec-genealogy/003/058.php]
Top Process %CPU 8.7 httpd [/favicon.ico]

[...]

Donc, essentiellement, trop de temps de calcul.

C'est donc bien ce que je pensais : le contenu du script ne nous sert
pas à grand chose. Tu pourrais avoir un script qui totalise plusieurs
milliers de lignes en faisant des appels à 15 bases de données, et qui
consommerait moins de CPU que le mini-script suivant :

<?php
$machin = 42;
while (1) { $machin *= 3.14159; }
?>

Cela étant, ce n'est même pas la peine d'aller chercher si loin puisque
même la lecture du favicon.ico à elle seule consomme déjà plus que les
8 % autorisés par ton hébergeur ! Tu es victime de ton succès et tu as
trop de visites ; il est peut-être temps de chercher un autre hébergeur,
ou au moins de prendre une autre formule d'hébergement chez l'actuel.

Ici, je ne suis pas certain de comprendre. Je pensais que PHP
exécutait un seul script à la fois.

D'une part rien n'empêche le serveur de lancer plusieurs process PHP
pour répondre à plusieurs requêtes en parallèle, et d'autre part je ne
vois pas en quoi cela empêcherait un script seul de consommer beaucoup
de CPU (même si, en l'occurrence, c'est plutôt le premier cas qui me
semble survenir).

À mon message précédent, j'ajoute que le code inclus fait autour
de 160 lignes.

On s'en fiche, comme dit plus haut.

Je pourrais l'optimiser en otant la limite par minute,

Tu peux optimiser favicon.ico aussi ? ;-)

En fouillant dans php.net, il y a cette page
http://ca3.php.net/manual/fr/ref.win32ps.php
mais c'est pour Windows Server/NT/XP.

Surtout, c'est un manuel PHP alors que ton problème est un cran au dessus.

Si je cherche CPU, je ne vois rien d'autres. PS trouve PostScript.

Si cela t'intéresse :
http://www.google.fr/search?q=%22man+ps%22

PHP Version 4.4.4, serveur Apache/1.3.37, sur Linux mais je ne vois
pas lequel.
Ok.

compilée comment ? Tu veux la liste complète des options ? Elle
fait 11 lignes mais je ne suis pas certain que ce soit utile.

Si je le demande, c'est pas pour faire nerd, c'est parce que j'en ai
besoin pour répondre au mieux à la question. Mais si tu estimes que tu
sais mieux que moi ce dont j'ai besoin pour t'aider, tu fais comme tu
veux.

Top Process %CPU 8.7 httpd [/favicon.ico]

Ouais. Je pense qu'il est temps de changer d'hébergeur... Bouffer 8% de
CPU pour renvoyer un fichier image de 16 pixels par 16 pixels, **il y a un
sérieux problème d'installation quelque part**.

Donc, essentiellement, trop de temps de calcul. Ici, je ne suis pas
certain de comprendre. Je pensais que PHP exécutait un seul script à la
fois.
Tout à fait. Ce qui est affiché ici est que pour traiter tel fichier, le

process httpd associé prend x% de CPU. Il y a bien exécution d'un seul
script PHP dans les deux lignes citées, l'autre est un GET d'un pauvre
fichier de taille ridicule sans aucun besoin de CPU. Il est totalement
inutile de perdre du temps à chercher, leur config est totalement
merdique et leurs alertes débiles.

par minute. Le code inclus fait environ 160 lignes de PHP et il y a
plusieurs variables de session $_SESSION.

Je ne serais pas étonné qu'ils aient des problèmes d'accès disque, mais si
tel est le cas, comme il semblerait qu'il ne soit pas utile de me
communiquer les informations que je demande, je ne peux pas en mesurer
l'impact complet.

a++;
JG

Le 22 Dec 2006 08:32:36 GMT, John GALLET <john.gallet@wanadoo.fr>
écrivait dans fr.comp.lang.php:

PHP Version 4.4.4, serveur Apache/1.3.37, sur Linux mais je ne vois
pas lequel.
Ok.

compilée comment ? Tu veux la liste complète des options ? Elle
fait 11 lignes mais je ne suis pas certain que ce soit utile.

Si je le demande, c'est pas pour faire nerd, c'est parce que j'en ai
besoin pour répondre au mieux à la question. Mais si tu estimes que tu
sais mieux que moi ce dont j'ai besoin pour t'aider, tu fais comme tu
veux.

Je suppose que c'est cette partie dont tu as besoin.

Configure Command

'./configure' '--with-apxs=/usr/local/apache/bin/apxs'
'--prefix=/usr/local' '--with-xml' '--with-mm' '--enable-bcmath'
'--enable-calendar' '--with-curl' '--with-dom' '--with-dom-xslt'
'--with-dom-exslt' '--enable-exif' '--enable-ftp' '--with-gd'
'--with-jpeg-dir=/usr/local' '--with-png-dir=/usr'
'--with-xpm-dir=/usr/X11R6' '--with-gettext'
'--with-imap=/usr/local/imap-2004g' '--enable-mbstring'
'--enable-mbstr-enc-trans' '--enable-mbregex' '--with-mcrypt'
'--enable-memory-limit' '--with-mhash' '--enable-magic-quotes'
'--with-mm' '--with-mysqli' '--with-mysql=/usr' '--with-openssl'
'--enable-discard-path' '--with-pear' '--with-pspell' '--enable-xslt'
'--with-xslt-sablot' '--enable-safe-mode' '--enable-sockets'
'--enable-track-vars' '--with-ttf' '--with-freetype-dir=/usr'
'--enable-gd-native-ttf' '--enable-versioning' '--enable-wddx'
'--with-xmlrpc' '--with-zip' '--with-zlib'

Top Process %CPU 8.7 httpd [/favicon.ico]

Ouais. Je pense qu'il est temps de changer d'hébergeur... Bouffer 8% de
CPU pour renvoyer un fichier image de 16 pixels par 16 pixels, **il y a un
sérieux problème d'installation quelque part**.

Je suppose qu'il s'agit de la charge totale et pas seulement de ce
fichier. Et que quand c'est arrivé, j'avais 3 ou 4 visiteurs dans la
même seconde.

Donc, essentiellement, trop de temps de calcul. Ici, je ne suis pas
certain de comprendre. Je pensais que PHP exécutait un seul script à la
fois.
Tout à fait. Ce qui est affiché ici est que pour traiter tel fichier, le

process httpd associé prend x% de CPU. Il y a bien exécution d'un seul
script PHP dans les deux lignes citées, l'autre est un GET d'un pauvre
fichier de taille ridicule sans aucun besoin de CPU. Il est totalement
inutile de perdre du temps à chercher, leur config est totalement
merdique et leurs alertes débiles.

Je leur ai posé la question, à savoir si c'est la charge totale ou
si c'est seulement un fichier. J'ai le favicon.ico m'a sauté aux yeux
tout de suite, et l'autre fichier ne demande pas beaucoup de
ressources. Mais si ma charge totale est réellement autour de 8%
quand j'ai plusieurs visiteurs à la fois, je peux modifier un peu le
source pour améliorer cela, quoique je ne sois pas certain que l'effet
soit énorme. En fait, mon test est en ce moment le suivant:

Est-ce un moteur ? (via une longue série de if IP <= 1.2.3.4)
Sinon, vérifier si le visiteur a dépassé la limite (donc, un
test rapide).

Comme il y a peu de visiteurs, je pourrais inverser les tests, mais
je n'ai rien pour mesurer la charge. Tout ce que je peux faire, c'est
mesurer la durée du script, ce qui est assez aléatoire sur un serveur
en multi-tâche.

par minute. Le code inclus fait environ 160 lignes de PHP et il y a
plusieurs variables de session $_SESSION.

Je ne serais pas étonné qu'ils aient des problèmes d'accès disque, mais si
tel est le cas, comme il semblerait qu'il ne soit pas utile de me
communiquer les informations que je demande, je ne peux pas en mesurer
l'impact complet.

Je suppose que c'est cette partie dont tu as besoin.
Absolument.

Ces deux là retiennent mon attention :

'--enable-memory-limit'
Donc les fonctions permettant de vérifier quelle quantité de

mémoire prend un script sont disponibles.
http://fr2.php.net/manual/en/function.memory-get-usage.php
http://fr2.php.net/manual/en/function.memory-get-peak-usage.php

'--with-mm'
et les sessions ne sont pas en fichiers mais en RAM. Donc s'ils ont, comme

je subodore, des gags d'accès disque, l'impact sera négligeable sur les
accès aux sessions.

'--enable-versioning'
Et ça pour foutre la m... c'est pile poil, mai c'est une autre histoire.

Top Process %CPU 8.7 httpd [/favicon.ico]
Je suppose qu'il s'agit de la charge totale et pas seulement de ce

fichier. Et que quand c'est arrivé, j'avais 3 ou 4 visiteurs dans la
même seconde.

Dans les conventions usuelles, un load c'est de la charge instantanée.
Donc un process appelé httpd était en train de servir une requête HTTP
(ici, un GET vu que c'est une image) et il prenait pour ce faire 8.7% de
la puissance CPU de la machine. Je réitère (et mon camarade Olivier a
exactement le même diagnostic alors que, là non plus, nous ne nous sommes
absolument pas concertés) : ceci est anormal, leur config est nazbrok.

Outre le fait que je ne vois vraiment pas l'ntérêt de tout le machin,
c'est un autre débat :

Est-ce un moteur ? (via une longue série de if IP <= 1.2.3.4)
En termes de CPU, il vaudrait mieux charger ladite liste dans un tableau

associatif et faire un isset() pour tester la présence, au lieu d'une
palanquée de tests.

Si le but est d'autoriser les moteurs à crawler sans être restreints,
c'est doublement improductif :
- si le moteur est écrit intelligement, il ne fera pas d'abus donc le
script ne sert à rien.
- si le moteur est écrit avec les pieds (au hasard, shopwiki) alors il
pourrira la tête pareil.

Si le but est de contrôler leur accès à certaines parties du site :
robots.txt

Et enfin, pour détecter les moteurs, browscap.ini et
http://fr2.php.net/manual/en/function.get-browser.php sont là pour ça.

Sinon, vérifier si le visiteur a dépassé la limite (donc,
un test rapide).
D'où la session je présume.

Comme il y a peu de visiteurs, je pourrais inverser les tests, mais
je n'ai rien pour mesurer la charge. Tout ce que je peux faire, c'est
mesurer la durée du script, ce qui est assez aléatoire sur un serveur
en multi-tâche.
Indeed. On peut aussi mesurer l'emprunte mémoire du script vu les options

de compilation.

On peut regarder comment optimiser le code (si tu commences par nous
exmpliquer exactement ce que tu veux faire) mais le coup du favicon.ico
rend à mon sens l'exercice sans objet vis ) vis des alertes de
l'hébergeur.

a++;
JG

[...] Je réitère (et mon camarade Olivier a
exactement le même diagnostic alors que, là non plus, nous ne nous sommes
absolument pas concertés) :

Tu es vachement sympa avec moi, car -- au moment où j'ai répondu -- mon
diagnostic était différent (même si je suis arrivé à la même conclusion
qu'il devrait changer d'hébergeur).

ceci est anormal, leur config est nazbrok.

Oui, après réflexion je suis d'accord.

Le 23 Dec 2006 16:09:21 GMT, Olivier Miakinen <om+news@miakinen.net>
écrivait dans fr.comp.lang.php:

[...] Je réitère (et mon camarade Olivier a
exactement le même diagnostic alors que, là non plus, nous ne nous sommes
absolument pas concertés) :

Tu es vachement sympa avec moi, car -- au moment où j'ai répondu -- mon
diagnostic était différent (même si je suis arrivé à la même conclusion
qu'il devrait changer d'hébergeur).

ceci est anormal, leur config est nazbrok.

Oui, après réflexion je suis d'accord.

Suite au message ici et en privé de John et aux autres commentaires
d'Olivier et n'ayant que peu de moyens d'en savoir davantage sur
cette surcharge, j'ai fouillé dans ce qui était à ma disposition,
soit le log du site en décembre.

Tout d'abord, je suis un peu mêlé avec les fuseaux horaires. Alors,
je ne suis pas trop certain d'avoir trouvé ce qu'il fallait.

Le script en question a été exécuté 5 fois en décembre. 2 par Google,
2 par Yahoo et 1 par moi en allant voir s'il y avait un problème.
Si j'ai 40 000 pages, seulement 35 000 sont visitées durant le mois
parce que les gens arrivent sur les pages qu'ils cherchent et ne
regardent pas tout. Et ces visites comprennent celles des moteurs.
Il y a donc beaucoup de pages qui ne sont jamais lues et d'autres
qui sont plus populaires (plus de descendants car il s'agit de
généalogie).

Le message est arrivé le 19 et il y a une visite de googlebot le 19,
je présume que c'est le bon et que la surcharge n'a pas empêché
l'ajout de la ligne au fichier log. Dans la minute en question, il
n'y a jamais 2 requêtes à la même seconde et une seule fois, 2 dans
des secondes consécutives. Donc, même si on suppose que c'est le
compte au complet qui est mesuré, il n'y a pas eu de surcharge à ce
moment.

Et selon John, c'est seulement le httpd actif à ce moment qui est
mesuré, donc une seule requête. C'est dingue mais ma conclusion
serait que si j'avais 8% de la machine à ce moment, c'est que les
autres clients n'avaient tout bonnement pas de visiteurs. D'après
les logs, mes seuls visiteurs à ce moment étaient 3 moteurs de
recherche et aucun humain. Ayant beaucoup de pages, je comprends que
les moteurs visitent trop souvent (je me demande si je pourrais
modifier robots.txt pour limiter la visite à une seule par mois)
et que le client moyen ayant sans doute beaucoup moins de pages,
sa probabilité d'être visité à ce moment est moindre (si les visiteurs
humains sont concentrés dans les mêmes fuseaux horaires).

Je pense que je dois considérer l'incident comme clos et que j'aurai
de quoi argumenter s'ils rappliquent.

J'avais signé pour un an. Je pense que j'irai voir ailleurs si cela
recommence.


Denis