Optimisation Apache+MySql

Olivier MARTINEAU

unread,

Jun 21, 2013, 9:27:11 AM6/21/13

to perform...@googlegroups.com

Bonjour,

Je me présente, je suis CTO dans ma startup SpreadButton. Ça fait longtemps que je gère des serveurs dédiés. Là, j'ai un petit cluster avec 3 serveurs (Apache / Nginx / Mysql Master-Slave / Couchbase / NAS)

J'aurai besoin d'un petit coup de main sur l'optimisation des mes confs Apache et MySQL pour optimiser le nombre de connexions simultanées, sans cramer le serveur, ca j'ai su faire sans aide :-) L'objectif, c'est genre de tenir un passage à la télé !

Je suis en train d'optimiser la plateforme pour tenir de forte charge et pouvoir monter en charge. Pour ça, je mets en place :

- du cache en mémoire (avec Couchbase)

- de la lecture sur un slave MySQL

Pas possible de mettre du proxy cache genre Varnish : c'est de l'applicatif pur mon truc.

J'ai un manque d'expérience sur l'optimisation mémoire d'Apache et de MySql. L'objectif, c'est avec mes serveurs accepter le maximum de connexion, sans mettre le serveur à genoux. Est-ce que vous avez des tips, les tutos, des bonnes idées, voire d'un freelance !

Merci

Olivier

Julien Wajsberg

unread,

Jun 21, 2013, 9:44:49 AM6/21/13

to perform...@googlegroups.com

tu n'as pas dit quelle était la techno ? PHP ?

ensuite je comprends pas l'intérêt d'avoir à la fois apache et nginx ?

2013/6/21 Olivier MARTINEAU <omart...@gmail.com>

--
--
Liste de diffusion sur les performances web : http://groups.google.com/group/performance-web
Plus d'informations : http://performance.survol.fr/
Se déinsinscrire : performance-w...@googlegroups.com
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes performance-web.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse performance-w...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .

Olivier Martineau

unread,

Jun 21, 2013, 9:49:10 AM6/21/13

to perform...@googlegroups.com

Oui, effectivement c'est du PHP.

Le NGINX sert uniquement des fichiers statiques. Je n'ai pas encore sauté le pas de lui confier aussi le PHP, je n'ai pas eu le temps de faire toutes les validations que je voulais faire sur php-pfm.

Du coup, NGINX dégage l'apache de tous les fichiers statiques (d'autant qu'il sert des .js qui ont sur les clients clients où je n'ai aucune visibilité sur la charge. Ca a intérêt à dépoter)

Est-ce que php-pfm permettrait d'optimiser la monté en charge de mes serveurs ? Meilleure gestion de la mémoire qu'en module apache ?

Merci

Olivier Martineau

oli...@cigogne.net

Vous recevez ce message car vous êtes abonné à un sujet dans le groupe Google Groupes "performance-web".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/performance-web/Cfv1lx7Y5rU/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse performance-w...@googlegroups.com.

Cédric Morin

unread,

Jun 21, 2013, 10:13:48 AM6/21/13

to perform...@googlegroups.com

Le 21 juin 2013 à 15:27, Olivier MARTINEAU <omart...@gmail.com> a écrit :

L'objectif, c'est genre de tenir un passage à la télé !

Je suis en train d'optimiser la plateforme pour tenir de forte charge et pouvoir monter en charge. Pour ça, je mets en place :
- du cache en mémoire (avec Couchbase)
- de la lecture sur un slave MySQL

Pas possible de mettre du proxy cache genre Varnish : c'est de l'applicatif pur mon truc.

Hello,

si ton cas test auquel tu veux résister est vraiment un passage télé, alors une simple optimisation risque de ne pas suffire.

Tout dépend ensuite des conditions de passage (audience) et de savoir si ton URL est affichée à l'écran ou non (car cela va fortement impacter le pourcentage de téléspectateur qui consultent sur leurs tablettes).

Ce type d'évènement est vraiment stressant car tu te retrouves avec des milliers de visiteurs qui déboulent dans la même minute : sur un cas de magazine du soir avec une audience moyenne à 4 millions, si tu as 1% qui tape l'url dans son nav quand elle apparaît à l'écran ça te fait 40000 visites dans un créneau très court de quelques minutes.

J'avais eu ce cas il y a quelques années (passage télé dans un CAPITAL avec url affichée à l'écran), et malgré toutes les optimisations que j'avais pu mettre en place auparavant, avec notamment du cache statique, ça n'était pas passé. Au moins le serveur n'avait pas planté, mais j'avais eu plusieurs minutes d'indisponibilité, suivie de plusieurs dizaines de minutes avec du temps de service fortement rallongé, donc expérience utilisateur très dégradée avant de revenir à la normale progressivement. Et c'était avant l'invasion des smartphones et tablettes qui ont carrément démocratisé la consultation du web en parallèle de la télé.

J'ai ai tiré l'expérience qu'il fallait absolument se reposer sur un CDN pour résister à ce type d'évènement. Dans ton cas purement applicatif il faudrait sans doute une infra plus largement dimensionnée que ce dont tu as besoin au quotidien.

A défaut, sans doute faut-il essayer d'éviter que l'URL soit explicitement mentionnée : même si cela peut être frustrant c'est contre-productif de faire venir sur une appli plein de visiteurs qui vont tomber sur une page blanche…

Mes deux sous.

Cédric

Stephane Rios

unread,

Jun 21, 2013, 10:36:33 AM6/21/13

to perform...@googlegroups.com

Salut tout le monde

Entièrement d'accord avec le CDN

Soit en mettant tous les statics sur un cloudfront par ex le temps du passage télé.

Soit faire une page statique cachable dans le CDN qui soit l'URL affichée à l'écran ou bien cacher au moins la home.

Bon ça empêche pas que des que les utilisateurs vont aller plus loin dans le site, ils tomberont sur des pages non cachées et bim.

Et on revient donc à l'optim de l'appli.

Il faut cacher un max mais il y a aussi possibilité de déborder sur du cloud public si ton application est déployable facilement et si tu as un service à la Cedexis par ex pour load balancer ton trafic.

Stéphane RIOS - CEO Fasterize - +33630264480

Sent from my iphone

--

Olivier Martineau

unread,

Jun 21, 2013, 12:49:57 PM6/21/13

to perform...@googlegroups.com

Effectivement le CDN me permettra de tenir la charge sur les statiques, et la page d'accueil. Ce qui est déjà pas mal !

J'avais imaginé utiliser Amazon S3 pour stocker les statiques, ce qui aurait été très pratique, mais il est impossible d'être en SSL et en même temps en nom de domaine personnalisé pour le moment (idem chez Rackspace, d'ailleurs)

Pour le cloud public, c'est effectivement une bonne idée pour gérer un débordement (prévisible)

Mais ça ne règle pas mon problème de tuning de mes configurations. Vous avez de bonnes pratiques ? Une méthodologie.

Il faut bien calculer le ratio nombre de connexions simultanées / RAM. Aussi bien sur MySQL que sur Apache (en attendant que je valide php-fpm)

Une fois, j'ai complètement planté un serveur parce qu'il s'était mis à faire fonctionner apache sur le swap... parce que j'avais configuré trop de connexion (et accessoirement parce que certains de mes process Apache/php montait un peu trop sérieusement en mémoire utilisée)

Coté CDN, avec du SSL et du nom de domaine perso, vous avez des conseils ?

Merci

Olivier Martineau

oli...@cigogne.net

Vous recevez ce message car vous êtes abonné à un sujet dans le groupe Google Groupes "performance-web".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/performance-web/Cfv1lx7Y5rU/unsubscribe.

Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse performance-w...@googlegroups.com.

Stephane Rios

unread,

Jun 21, 2013, 12:57:29 PM6/21/13

to perform...@googlegroups.com

Cloudfront : facturation à l'usage, bonnes perfs, fonctionnalités basiques

Sinon le CDN SFR est très bon et celui d'Ovh est pas cher.

J'ai pas compris l'intérêt du SSL dans ton cas ni de S3 pour diffuser des statiques (juste pour les stocker ok mais apparemment tu as déjà ton serveur)

Désolé mais pour le reste je ne m'y connais pas assez ... (Et si on peut troller, Apache nan quoi ;-)

Stéphane RIOS - CEO Fasterize - +33630264480

Sent from my iphone

Julien Wajsberg

unread,

Jun 21, 2013, 12:59:40 PM6/21/13

to perform...@googlegroups.com

2013/6/21 Stephane Rios <s...@fasterize.com>

Cloudfront : facturation à l'usage, bonnes perfs, fonctionnalités basiques
Sinon le CDN SFR est très bon et celui d'Ovh est pas cher.

J'ai pas compris l'intérêt du SSL dans ton cas ni de S3 pour diffuser des statiques (juste pour les stocker ok mais apparemment tu as déjà ton serveur)

Désolé mais pour le reste je ne m'y connais pas assez ... (Et si on peut troller, Apache nan quoi ;-)

j'ai toujours pas vu de bench sur apache en mode threadé et fpm vs nginx, moi.

Gaël Métais

unread,

Jun 21, 2013, 1:01:42 PM6/21/13

to perform...@googlegroups.com

Bonjour,

Je n'y connais rien en tunning de configuration Apache ou MySQL.

Mais as-tu pensé à utiliser un accélérateur PHP, style APC ou HipHop ?

Gaël METAIS

Olivier Martineau

unread,

Jun 21, 2013, 1:06:55 PM6/21/13

to perform...@googlegroups.com

En fait, j'ai besoin de SSL parce que j'ai des scripts qui sont déployés sur des sites qui peuvent être en SSL (des sites de ecommerce). Et si je n’ai pas de SSL.... ca ne marche tout simplement pas. :-)

Olivier Martineau

oli...@cigogne.net

Stephane Rios

unread,

Jun 21, 2013, 1:08:14 PM6/21/13

to perform...@googlegroups.com

On 21 juin 2013, at 19:00, Julien Wajsberg <fel...@gmail.com> wrote:

2013/6/21 Stephane Rios <s...@fasterize.com>

Cloudfront : facturation à l'usage, bonnes perfs, fonctionnalités basiques

[...]

Désolé mais pour le reste je ne m'y connais pas assez ... (Et si on peut troller, Apache nan quoi ;-)

j'ai toujours pas vu de bench sur apache en mode threadé et fpm vs nginx, moi.

Moi non plus :-))

Stephane Rios

unread,

Jun 21, 2013, 1:08:52 PM6/21/13

to perform...@googlegroups.com

Mais sur les statiques aussi ??

Stéphane RIOS - CEO Fasterize - +33630264480

Sent from my iphone

Olivier Martineau

unread,

Jun 21, 2013, 1:12:42 PM6/21/13

to perform...@googlegroups.com

Bonjour Gaël,

Oui, j'ai Xcache en place. Je n'ai pas essayé Hiphop-php, mais ici http://devel.crossip.net/index.php/experience/28-fast-hiphop ils ont testé et comparé avec nginx + php-fpm et conseillent php-fpm !

Olivier Martineau

oli...@cigogne.net

Olivier Martineau

unread,

Jun 21, 2013, 1:13:28 PM6/21/13

to perform...@googlegroups.com

Oui, sur le .js

Olivier Martineau

oli...@cigogne.net

Eric Daspet

unread,

Jun 21, 2013, 4:32:36 PM6/21/13

to perform...@googlegroups.com

On Friday, June 21, 2013, Olivier MARTINEAU wrote:

Bonjour,

Je me présente, je suis CTO dans ma startup SpreadButton. Ça fait longtemps que je gère des serveurs dédiés. Là, j'ai un petit cluster avec 3 serveurs (Apache / Nginx / Mysql Master-Slave / Couchbase / NAS)

J'aurai besoin d'un petit coup de main sur l'optimisation des mes confs Apache et MySQL pour optimiser le nombre de connexions simultanées, sans cramer le serveur, ca j'ai su faire sans aide :-) L'objectif, c'est genre de tenir un passage à la télé !

Franchement je serai surpris qu'on puisse beaucoup t'aider avec une telle description. Une réponse très classique de quand je faisais du conseil sur le sujet : S'il y avait un "truc" pour ça, il serait dans la configuration par défaut et tu n'aurais pas besoin de le mettre en oeuvre "en plus".

La base :

* Des entêtes de cache sur tous les fichiers statiques

* Des index sur ta base SQL (actives le log des requêtes sans index et vérifies toutes les entrées)

* Pas de keepalive sur ton serveur web applicatif (ici Apache)

* Du keep alive sur ton serveur statique (ici Nginx)

* Un cache d'opcode (APC par exemple), si possible avec un truc genre apc.stat à 0 (attention à en comprendre les implications)

* Le code PHP sur un disque rapide, voir sur de la RAM s'il est suffisamment petit

* Suffisamment de RAM pour ton MySQL

* Un PHP récent (le 5.4 et le 5.5 sont vraiment plus rapides)

* Côté MySQL, un mysql tuner est une bonne idée pour commencer

* Penser à Percona ou MariaDB en lieu et place de MySQL

* Innodb et pas myisam (sauf cas particulier), avec un fichier par table et pas un fichier commun

* Pas de session en base

Maintenant à 95% les problèmes viennent de mauvais codes applicatifs, de mauvaises requêtes SQL, etc. Il est peu probable que tu gagnes 20% sur de la configuration des services, sauf à avoir fait des bêtises à la base. Je t'incite vraiment à regarder côté applicatif par défaut (sauf si vraiment tu as des mesures pour appuyer l'idée que ton problème vient de la configuration système)

Si tu cherches quelqu'un pour accompagner, tu peux contacter Olivier Hoareau http://www.phppro.fr/ de ma part.

--

Eric

--
Éric Daspet
http://eric.daspet.name/

Reply all

Reply to author

Forward