je suis pas un spécialiste apache et php.
Je viens de découvrir qu'il existe plusieurs modes de configuration
(module, cgi)
http://www.devside.net/articles/php
J'ai donc du apache2 et php5. Quelle est la configuration recommandée
pour de la prod et pour une bonne prise en compte de certains services
(mod_expire, memcache, etc.).
Pouvez-vous m'expliquer les conséquences de choix d'intégration de PHP
dans HTTPD ?
ça dépend de ce que tu faire mais pour commencer, le plus simple est d'utiliser php en module car on integre du code php dans les pages html.
Le genre de truc à faire vomir n'importe quelle personne ayant un peu de recul dans ce domaine de développement.
Même PHP dispose maintenant de frameworks MVC, autant les utiliser.
Le CGI est, pour faire simple, un gros programme, pas forcément en php, qui prend en charge toutes les requêtes en renvoi du html en fonction. C'est plutôt utilisé sur les trés gros sites (en nombre de visiteurs).
C'est surtout quasiment plus utilisé, le fork d'un processus de traitement à chaque requête pose des problèmes de perfs assez copieux. On lui préfère donc des long running processes interfacés via fcgi http://fr.wikipedia.org/wiki/FastCGI
Et une fois qu'on est arrivé là, on se demande quel est l'intérêt de conserver apache alors que des alternatives comme nginx, lighttpd ou cherokee sont plus adaptées à ce modèle.
-- Les L*n*x**ns sont par définition des nioubies, biscotte on buvait déjà de la Guiness autour de trucs BSD alors que la pingouinade n'était même pas une lueur lubrique dans le regard de Linus T. -+- FYlG in <http://www.le-gnu.net> : Gouin gouin les pingouins -+-
Fred <fr-icsr@numericable.fr> writes:
'Lut,
ça dépend de ce que tu faire mais pour commencer, le plus simple est
d'utiliser php en module car on integre du code php dans les pages
html.
Le genre de truc à faire vomir n'importe quelle personne ayant un peu de
recul dans ce domaine de développement.
Même PHP dispose maintenant de frameworks MVC, autant les utiliser.
Le CGI est, pour faire simple, un gros programme, pas forcément en php,
qui prend en charge toutes les requêtes en renvoi du html en fonction.
C'est plutôt utilisé sur les trés gros sites (en nombre de visiteurs).
C'est surtout quasiment plus utilisé, le fork d'un processus de
traitement à chaque requête pose des problèmes de perfs assez copieux.
On lui préfère donc des long running processes interfacés via fcgi
http://fr.wikipedia.org/wiki/FastCGI
Et une fois qu'on est arrivé là, on se demande quel est l'intérêt de
conserver apache alors que des alternatives comme nginx, lighttpd ou
cherokee sont plus adaptées à ce modèle.
--
Les L*n*x**ns sont par définition des nioubies, biscotte on
buvait déjà de la Guiness autour de trucs BSD alors que la pingouinade
n'était même pas une lueur lubrique dans le regard de Linus T.
-+- FYlG in <http://www.le-gnu.net> : Gouin gouin les pingouins -+-
ça dépend de ce que tu faire mais pour commencer, le plus simple est d'utiliser php en module car on integre du code php dans les pages html.
Le genre de truc à faire vomir n'importe quelle personne ayant un peu de recul dans ce domaine de développement.
Même PHP dispose maintenant de frameworks MVC, autant les utiliser.
Le CGI est, pour faire simple, un gros programme, pas forcément en php, qui prend en charge toutes les requêtes en renvoi du html en fonction. C'est plutôt utilisé sur les trés gros sites (en nombre de visiteurs).
C'est surtout quasiment plus utilisé, le fork d'un processus de traitement à chaque requête pose des problèmes de perfs assez copieux. On lui préfère donc des long running processes interfacés via fcgi http://fr.wikipedia.org/wiki/FastCGI
Et une fois qu'on est arrivé là, on se demande quel est l'intérêt de conserver apache alors que des alternatives comme nginx, lighttpd ou cherokee sont plus adaptées à ce modèle.
-- Les L*n*x**ns sont par définition des nioubies, biscotte on buvait déjà de la Guiness autour de trucs BSD alors que la pingouinade n'était même pas une lueur lubrique dans le regard de Linus T. -+- FYlG in <http://www.le-gnu.net> : Gouin gouin les pingouins -+-
Eric Masson
Pif - 34 writes:
'Re,
pourquoi pas ?
Parce que c'est lourdingue, vu que ça tente de faire papa, maman, la nourrice et la petite amie en même temps ;)
du coup, j'avais en tête que httpd étant installé par défaut sur toutes les distribs (dans mon cas centos 6), il s'agissait d'une solutions éprouvée, documentée, standard, performante, fiable et sécure...
C'est standard, même si nginx commence à lui tailler des croupières sur les sites à fort volume de requêtes.
Actuellement, j'ai deux soucis: 1) j'ai une vm pas cher qui n'a que 512Mo de RAM 2) Moodle est très lourd à l'exécution (contrairement à joomla, roundcube ou phpmyadmin qui sont assez rapides). En gros, il faut 3 à 10 sec pour exécuter 1 page moodle, voir plus avec les dépendances... Donc NGinx me ferait gagner que quelques ms dans mon problème, non ?
Il faudrait déjà déterminer où se situe le goulot d'étranglement, sans cela impossible de dire si changer de modèle va changer quelque chose aux performances.
au niveau des modules, genre expire, cache, etc. y'a quand meme ce qu'il faut sur nginx ?
Tout semble être recensé sur le site du projet : http://wiki.nginx.org/Modules
donc pour une appli exposée sur internet, le CGI est obligatoire je suppose, surtout dès lors qu'on utilise des framework php donc la sécurité peut s'avérer douteuse et dont le failles sont potentiellement notoires...
Quelque soit la pile choisie, il faut de toutes façons paramétrer ses éléments de manière à contenir le plus possible leurs possibilités d'interaction avec le système sous-jacent (jails, capacités sur les systèmes qui le supportent par exemple)
--
C'est pas un pingouin mais une hirondelle africaine et sa noix de coco
Maintenant que vous le dîtes, c'est fort possible, Roland Courbis a des faux airs de John Cleese, mais en plus petit. -+- fc&t in<www.le-gnu.net> : Une hirondelle ne fait pas le pingouin-+-
Pif - 34 <pif@nospam.invalid> writes:
'Re,
pourquoi pas ?
Parce que c'est lourdingue, vu que ça tente de faire papa, maman, la
nourrice et la petite amie en même temps ;)
du coup, j'avais en tête que httpd étant installé par défaut sur toutes
les distribs (dans mon cas centos 6), il s'agissait d'une solutions
éprouvée, documentée, standard, performante, fiable et sécure...
C'est standard, même si nginx commence à lui tailler des croupières sur
les sites à fort volume de requêtes.
Actuellement, j'ai deux soucis:
1) j'ai une vm pas cher qui n'a que 512Mo de RAM
2) Moodle est très lourd à l'exécution (contrairement à joomla,
roundcube ou phpmyadmin qui sont assez rapides). En gros, il faut 3 à 10
sec pour exécuter 1 page moodle, voir plus avec les dépendances... Donc
NGinx me ferait gagner que quelques ms dans mon problème, non ?
Il faudrait déjà déterminer où se situe le goulot d'étranglement, sans
cela impossible de dire si changer de modèle va changer quelque chose
aux performances.
au niveau des modules, genre expire, cache, etc. y'a quand meme ce qu'il
faut sur nginx ?
Tout semble être recensé sur le site du projet :
http://wiki.nginx.org/Modules
donc pour une appli exposée sur internet, le CGI est obligatoire je
suppose, surtout dès lors qu'on utilise des framework php donc la
sécurité peut s'avérer douteuse et dont le failles sont potentiellement
notoires...
Quelque soit la pile choisie, il faut de toutes façons paramétrer ses
éléments de manière à contenir le plus possible leurs possibilités
d'interaction avec le système sous-jacent (jails, capacités sur les
systèmes qui le supportent par exemple)
--
C'est pas un pingouin mais une hirondelle africaine et sa noix de coco
Maintenant que vous le dîtes, c'est fort possible, Roland Courbis a des
faux airs de John Cleese, mais en plus petit.
-+- fc&t in<www.le-gnu.net> : Une hirondelle ne fait pas le pingouin-+-
Parce que c'est lourdingue, vu que ça tente de faire papa, maman, la nourrice et la petite amie en même temps ;)
du coup, j'avais en tête que httpd étant installé par défaut sur toutes les distribs (dans mon cas centos 6), il s'agissait d'une solutions éprouvée, documentée, standard, performante, fiable et sécure...
C'est standard, même si nginx commence à lui tailler des croupières sur les sites à fort volume de requêtes.
Actuellement, j'ai deux soucis: 1) j'ai une vm pas cher qui n'a que 512Mo de RAM 2) Moodle est très lourd à l'exécution (contrairement à joomla, roundcube ou phpmyadmin qui sont assez rapides). En gros, il faut 3 à 10 sec pour exécuter 1 page moodle, voir plus avec les dépendances... Donc NGinx me ferait gagner que quelques ms dans mon problème, non ?
Il faudrait déjà déterminer où se situe le goulot d'étranglement, sans cela impossible de dire si changer de modèle va changer quelque chose aux performances.
au niveau des modules, genre expire, cache, etc. y'a quand meme ce qu'il faut sur nginx ?
Tout semble être recensé sur le site du projet : http://wiki.nginx.org/Modules
donc pour une appli exposée sur internet, le CGI est obligatoire je suppose, surtout dès lors qu'on utilise des framework php donc la sécurité peut s'avérer douteuse et dont le failles sont potentiellement notoires...
Quelque soit la pile choisie, il faut de toutes façons paramétrer ses éléments de manière à contenir le plus possible leurs possibilités d'interaction avec le système sous-jacent (jails, capacités sur les systèmes qui le supportent par exemple)
--
C'est pas un pingouin mais une hirondelle africaine et sa noix de coco
Maintenant que vous le dîtes, c'est fort possible, Roland Courbis a des faux airs de John Cleese, mais en plus petit. -+- fc&t in<www.le-gnu.net> : Une hirondelle ne fait pas le pingouin-+-
Nicolas George
Eric Masson , dans le message , a écrit :
C'est surtout quasiment plus utilisé, le fork d'un processus de traitement à chaque requête pose des problèmes de perfs assez copieux.
Ça dépend quand même largement de la charge du serveur. Un serveur qui répond à trois requêtes en deux jours, il peut se permettre quelques forks par requête.
Eric Masson , dans le message
<6vh2ja-gbe.ln1@srvbsdfenssv.interne.associated-bears.org>, a écrit :
C'est surtout quasiment plus utilisé, le fork d'un processus de
traitement à chaque requête pose des problèmes de perfs assez copieux.
Ça dépend quand même largement de la charge du serveur. Un serveur qui
répond à trois requêtes en deux jours, il peut se permettre quelques forks
par requête.
C'est surtout quasiment plus utilisé, le fork d'un processus de traitement à chaque requête pose des problèmes de perfs assez copieux.
Ça dépend quand même largement de la charge du serveur. Un serveur qui répond à trois requêtes en deux jours, il peut se permettre quelques forks par requête.
Eric Masson
Nicolas George <nicolas$ writes:
'Lut,
Ça dépend quand même largement de la charge du serveur. Un serveur qui répond à trois requêtes en deux jours, il peut se permettre quelques forks par requête.
C'est clair :)
-- Je viens avec ma femme une fois. S.v.p., soyez gentils avec elle. Ne lui dites pas que je poste dans fcsm. Elle crois que je traduis du logiciel... -+ JPK in Guide du Macounet Pervers : Bien tromper son monde une fois +-
Nicolas George <nicolas$george@salle-s.org> writes:
'Lut,
Ça dépend quand même largement de la charge du serveur. Un serveur qui
répond à trois requêtes en deux jours, il peut se permettre quelques forks
par requête.
C'est clair :)
--
Je viens avec ma femme une fois.
S.v.p., soyez gentils avec elle. Ne lui dites pas que je poste dans
fcsm. Elle crois que je traduis du logiciel...
-+ JPK in Guide du Macounet Pervers : Bien tromper son monde une fois +-
Ça dépend quand même largement de la charge du serveur. Un serveur qui répond à trois requêtes en deux jours, il peut se permettre quelques forks par requête.
C'est clair :)
-- Je viens avec ma femme une fois. S.v.p., soyez gentils avec elle. Ne lui dites pas que je poste dans fcsm. Elle crois que je traduis du logiciel... -+ JPK in Guide du Macounet Pervers : Bien tromper son monde une fois +-
JKB
Le Wed, 16 Oct 2013 16:39:44 +0200, Eric Masson écrivait :
Nicolas George <nicolas$ writes:
'Lut,
Ça dépend quand même largement de la charge du serveur. Un serveur qui répond à trois requêtes en deux jours, il peut se permettre quelques forks par requête.
C'est clair :)
D'autant qu'avec le copy-on-write, le fork() n'est pas forcément beaucoup plus pénalisant qu'un pthread_create() avec la batterie de truc qui va bien juste derrière.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Wed, 16 Oct 2013 16:39:44 +0200,
Eric Masson <emss@free.fr> écrivait :
Nicolas George <nicolas$george@salle-s.org> writes:
'Lut,
Ça dépend quand même largement de la charge du serveur. Un serveur qui
répond à trois requêtes en deux jours, il peut se permettre quelques forks
par requête.
C'est clair :)
D'autant qu'avec le copy-on-write, le fork() n'est pas forcément
beaucoup plus pénalisant qu'un pthread_create() avec la batterie de
truc qui va bien juste derrière.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Wed, 16 Oct 2013 16:39:44 +0200, Eric Masson écrivait :
Nicolas George <nicolas$ writes:
'Lut,
Ça dépend quand même largement de la charge du serveur. Un serveur qui répond à trois requêtes en deux jours, il peut se permettre quelques forks par requête.
C'est clair :)
D'autant qu'avec le copy-on-write, le fork() n'est pas forcément beaucoup plus pénalisant qu'un pthread_create() avec la batterie de truc qui va bien juste derrière.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
william
On 2013-10-15, Pif - 34 wrote:
Bonjour,
je suis pas un spécialiste apache et php. Je viens de découvrir qu'il existe plusieurs modes de configuration (module, cgi) http://www.devside.net/articles/php
J'ai donc du apache2 et php5. Quelle est la configuration recommandée pour de la prod et pour une bonne prise en compte de certains services (mod_expire, memcache, etc.).
Pouvez-vous m'expliquer les conséquences de choix d'intégration de PHP dans HTTPD ?
ca va dependre du module en question, mais ce sont des modules apache que tu cites et qui n'ont pas grand chose a voir avec php a proprement parler.
par contre cela va avoir un effet non pas sur php mais sur les en tetes puisque apache est le conteneur.
Je sais pas si je suis super clair.
On 2013-10-15, Pif - 34 <pif@nospam.invalid> wrote:
Bonjour,
je suis pas un spécialiste apache et php.
Je viens de découvrir qu'il existe plusieurs modes de configuration
(module, cgi)
http://www.devside.net/articles/php
J'ai donc du apache2 et php5. Quelle est la configuration recommandée
pour de la prod et pour une bonne prise en compte de certains services
(mod_expire, memcache, etc.).
Pouvez-vous m'expliquer les conséquences de choix d'intégration de PHP
dans HTTPD ?
ca va dependre du module en question, mais ce sont des modules apache que tu
cites et qui n'ont pas grand chose a voir avec php a proprement parler.
par contre cela va avoir un effet non pas sur php mais sur les en tetes puisque
apache est le conteneur.
je suis pas un spécialiste apache et php. Je viens de découvrir qu'il existe plusieurs modes de configuration (module, cgi) http://www.devside.net/articles/php
J'ai donc du apache2 et php5. Quelle est la configuration recommandée pour de la prod et pour une bonne prise en compte de certains services (mod_expire, memcache, etc.).
Pouvez-vous m'expliquer les conséquences de choix d'intégration de PHP dans HTTPD ?
ca va dependre du module en question, mais ce sont des modules apache que tu cites et qui n'ont pas grand chose a voir avec php a proprement parler.
par contre cela va avoir un effet non pas sur php mais sur les en tetes puisque apache est le conteneur.