gratifiant > linux.debian.user.french

JUPIN Alain (09/07/2019, 11h50)
Bonjour,

J'ai un serveur ISPConfig 3 qui tourne sous Debian 9 et apparemment, le
nombre de process apache reste bloqué aux alentours de 150 (dixit Munin).
J'ai eu beau tenter de modifier 
/etc/apache2/mods-enabled/mpm_prefork.conf qui ressemble à cà
<IfModule mpm_prefork_module>
    StartServers             5
    MinSpareServers          5
    MaxSpareServers         10
    MaxClients                500
    MaxRequestsPerChild   0
</IfModule>

Actuellement, je reste bloqué à 150 connexions simultanées. Une idée
pour passer à 500 ?

Qu'ai donc foiré, mal compris ?

PS : Apache utilise le MPM prefork mais çà vous l'aurez sans doute
compris ;)

Merci à vous
JUPIN Alain (09/07/2019, 12h00)
Désolé pour le doublons il m?avait semblé avoir fait qu'un seul envoi !

Alain JUPIN
Lumières d'Ici ... et d'Ailleurs <http://www.jupin.net>
Le 09/07/2019 à 11:43, JUPIN Alain a écrit :
[..]
JUPIN Alain (09/07/2019, 15h30)
Bonjour

C'est un Apache 2.4.25, dans la config initiale, j'avais bien
MaxRequestWorkers mais comme cela ne fonctionnait pas, j'ai testé
l'ancienne directive MaxClients.
Par contre, en effet, je n'ai pas indiqué de directive ServerLimits.

Je vais tester cela. Merci

Alain JUPIN
Lumières d'Ici ... et d'Ailleurs <http://www.jupin.net>
Le 09/07/2019 à 14:44, Yahoo a écrit :
[..]
JUPIN Alain (09/07/2019, 16h10)
Bonjour,

J'avoue que je me suis posé la question, mais d'après pas mal de forum,
si PHP lui-même est safe threadé il semble que ce ne soit pas le cas de
toutes les librairies dont il dépend. Et on m'avait conseillé pour
l'usage de PHP de conserver "prefork". L'ancien serveur lui était en
worker et cela ne semble pas poser de problème (fonctionnellement
parlant) après j'ai pas testé s'il y avait des fuites entre threads.

Mais je vais de nouveau réexaminer la question suite à ta remarque ;)
Merci à toi.

Alain JUPIN
Lumières d'Ici ... et d'Ailleurs <http://www.jupin.net>

Le 09/07/2019 à 15:59, Daniel Caillibaud a écrit :
[..]
Daniel Caillibaud (09/07/2019, 16h10)
Le 09/07/19 =C3=A0 11h43, JUPIN Alain <ajupin> a =C3=A9crit :
> PS : Apache utilise le MPM prefork mais =C3=A7=C3=A0 vous l'aurez sans do= ute
> compris ;)


Juste par curiosit=C3=A9 (j'utilise plus d'apache depuis ~10ans), pourquoi
utiliser le mode prefork ?

=C3=80 moins d'avoir de la RAM en trop, c'est quand m=C3=AAme bcp plus effi=
cace en
mode worker non ?

Y'a des applis qui supportent pas le multi-threading ?

--=20
Daniel

Le g=C3=A9nie consiste =C3=A0 voir ce que tout le monde a vu
et =C3=A0 penser ce que personne n'a pens=C3=A9.
Daniel Caillibaud (09/07/2019, 17h50)
Le 09/07/19 =C3=A0 16h07, JUPIN Alain <ajupin> a =C3=A9crit :
> Bonjour,
>=20
> J'avoue que je me suis pos=C3=A9 la question, mais d'apr=C3=A8s pas mal d= e forum,
> si PHP lui-m=C3=AAme est safe thread=C3=A9 il semble que ce ne soit pas l= e cas de
> toutes les librairies dont il d=C3=A9pend. Et on m'avait conseill=C3=A9 p= our
> l'usage de PHP de conserver "prefork". L'ancien serveur lui =C3=A9tait en
> worker et cela ne semble pas poser de probl=C3=A8me (fonctionnellement
> parlant) apr=C3=A8s j'ai pas test=C3=A9 s'il y avait des fuites entre thr= eads.
>=20
> Mais je vais de nouveau r=C3=A9examiner la question suite =C3=A0 ta remar= que ;)


Effectivement, regarde un peu la litt=C3=A9rature avant, c'est bien possibl=
e que
prefork soit conseill=C3=A9 pour mod_php, mais tu n'auras aucun pb en mpm a=
vec
php-fpm.
En gros php n'est plus dans le binaire apache mais a son propre serveur =C3=
=A0
qui les threads apache d=C3=A9l=C3=A8guent le boulot si =C3=A7a le concerne=
..=20

C'est nettement plus efficace.

J'ai bascul=C3=A9 de apache prefork + mod_php vers nginx + php-fpm y'a ~10a=
ns
suite =C3=A0 des mesures sur mon contexte de l'=C3=A9poque
- =C3=A0 faible/moyenne charge apache + mod_php =C3=A9tait un peu plus rapi=
de
- sur un hardware donn=C3=A9, nginx + php-fpm pouvaient encaisser 3~4 fois =
plus
de clients simultan=C3=A9s (mesur=C3=A9 avec tsung, avec de vraie sessions
utilisateur et plein d'al=C3=A9atoire pour ne pas mesurer le cache)
- quand on s'approchait de la limite, la solution apache d=C3=A9crochait tr=
=C3=A8s
vite (r=C3=A9pondait mal =C3=A0 tout le monde voire plus =C3=A0 personne)=
quand nginx
arrivaient =C3=A0 servir la plupart des connect=C3=A9s (avec pas mal de t=
imeout
pour les nouveaux arrivants)

Aujourd'hui je crois que apache mpm + php-fpm devrait donner des choses
voisines de nginx + php-fpm (question perfs tout se joue ensuite sur les
r=C3=A9glages, qui se font diff=C3=A9remment sur les deux solutions, mais u=
ne fois
d=C3=A9branch=C3=A9 les .htaccess et autres tueurs de perfs activ=C3=A9s pa=
r d=C3=A9faut
apache tient la comparaison, dixit le peu de litt=C3=A9rature que j'ai surv=
ol=C3=A9).

Et php-fpm a plein d'autres avantages sur mod_php (la s=C3=A9curit=C3=A9, a=
vec des
droits r=C3=A9gl=C3=A9s par pool php, des configs php qui d=C3=A9pendent du=
contexte,
etc., choses p=C3=A9nibles =C3=A0 faire avant avec suexec par ex).

--=20
Daniel

L'id=C3=A9e d'une arm=C3=A9e europ=C3=A9enne est vraiment int=C3=A9ressante,
mais pourquoi ne pas aller plus loin en cr=C3=A9ant une arm=C3=A9e
mondiale dont le principal int=C3=A9r=C3=AAt serait qu'elle n'aurait=20
pas d'ennemis.
Philippe Geluck, Le chat
Discussions similaires