Optimisation architecture Web / Retour d'experience ?
Bonjour à tous, Je suis à la recherche de pistes / retour dexpériences pour optimiser les temps de réponse d'une application Web PHP (qui est en fait un jeux flash fonctionnant en appel WebService). On retrouve également tout les médias utilisés par le jeux. Mon architecture est en l'état la suivante : Un serveur frontal HAPROXY qui redirige les requêtes vers un pool de frontaux HTTP ainsi que vers un pool de media static. Les frontaux HTTP sont des apaches / Les serveurs medias sont des lighttpd. J'envisage de déployer des instances VARNISH sur mon frontal HAPROXY pour cacher les accès aux médias. J'aurai alors une chaine HAPROXY <=> VARNISH <=> BACKEND Cela a t'il du sens pour vous ? D'une manière générale quelles sont les "killers app" que vous avez mis en uvre dans vos architectures web ? Merci par avance pour toutes les idées que vous pourrez m'apporter dans ma quête de perf :) Vincent Finet Viveris - ASR Ingénieur système et réseau Mail : vincent.finet@viveris-asr.fr Tel : 01 55 19 47 47 Mob : 06 88 56 27 73
Salut, Varnish t'aidera surement si la latence se situe au niveau de tes serveurs apaches et lighthttpd. Si le goulot d'étranglement se situe au niveau de la bande passante, un CDN peut être une solution (j'en revends plusieurs), surtout si ton audience est hors France. Damien, vincent finet writes:
Bonjour à tous,
Je suis à la recherche de pistes / retour d�expériences pour optimiser les temps de réponse d'une application Web PHP (qui est en fait un jeux flash fonctionnant en appel WebService). On retrouve également tout les médias utilisés par le jeux.
Mon architecture est en l'état la suivante :
Un serveur frontal HAPROXY qui redirige les requêtes vers un pool de frontaux HTTP ainsi que vers un pool de media static. Les frontaux HTTP sont des apaches / Les serveurs medias sont des lighttpd.
J'envisage de déployer des instances VARNISH sur mon frontal HAPROXY pour cacher les accès aux médias. J'aurai alors une chaine HAPROXY <=> VARNISH <=> BACKEND
Cela a t'il du sens pour vous ? D'une manière générale quelles sont les "killers app" que vous avez mis en �uvre dans vos architectures web ? Merci par avance pour toutes les idées que vous pourrez m'apporter dans ma quête de perf :)
Vincent Finet
Viveris - ASR Ingénieur système et réseau Mail : vincent.finet@viveris-asr.fr Tel : 01 55 19 47 47 Mob : 06 88 56 27 73
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Damien WETZEL (ATANAR TECHNOLOGIES) ("`-/")_.-'"``-._ http://www.atanar.com . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' Phone:+33 9 63 05 59 99 _.- _..-_/ / ((.' - So much to do, so little time - ((,.-' ((,/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Mon, 5 Sep 2011 10:43:06 +0200, "vincent finet" <vincent.finet@viveris-asr.fr> wrote:
Bonjour à tous,
Bonjour,
Je suis à la recherche de pistes / retour d’expériences pour optimiser les temps de réponse d'une application Web PHP (qui est en fait un jeux flash fonctionnant en appel WebService). On retrouve également tout les médias utilisés par le jeux.
Mon architecture est en l'état la suivante :
Un serveur frontal HAPROXY qui redirige les requêtes vers un pool de frontaux HTTP ainsi que vers un pool de media static. Les frontaux HTTP sont des apaches / Les serveurs medias sont des lighttpd.
J'envisage de déployer des instances VARNISH sur mon frontal HAPROXY pour cacher les accès aux médias. J'aurai alors une chaine HAPROXY <=> VARNISH <=> BACKEND
Cela a t'il du sens pour vous ? D'une manière générale quelles sont les "killers app" que vous avez mis en œuvre dans vos architectures web ? Merci par avance pour toutes les idées que vous pourrez m'apporter dans ma quête de perf :)
De manière générale, plutot que de rechercher le démon à la mode, qui certes optimisera l'infra, je préfère travailler sur les points critiques. As tu pu trouver le bottleneck de ton infra actuelle? Par exemple, si c'est MySQL qui rame, ton varnish ne servira pas forcément à grand chose. Une fois le bottleneck identifié, nous pourrons avoir une meilleure vision de tes besoins, et te donner des conseils plus sains. Cordialement,
Merci pour vos réponses avisées. Je ne sais en fait pas vraiment ou se situe le goulot. En l'état les perfs sont bonnes et l'architecture bien dimensionnée (tout les indicateurs aux verts dans Nagios). J'aimerai cependant encore améliorer la chose pour que l'application charge plus vite et pour pouvoir faire face à une charge plus importante. En pratique cela veut dire : --> Récupérer des fichiers plus vite ( varnish en amont de mes serveurs backend ? autre ?) --> Computer des appels WS PHP plus vite ( optimiser PHP : HipHop PHP ? mmcache ? autre ? / optimiser Mysql : ?) Cdt Vincent Finet Viveris - ASR Ingénieur système et réseau Mail : vincent.finet@viveris-asr.fr Tel : 01 55 19 47 47 Mob : 06 88 56 27 73 -----Original Message----- From: frsag-bounces@frsag.org on behalf of Richard DEMONGEOT Sent: Mon 05/09/2011 10:55 To: French SysAdmin Group Subject: Re: [FRsAG] Optimisation architecture Web / Retour d'experience ? On Mon, 5 Sep 2011 10:43:06 +0200, "vincent finet" <vincent.finet@viveris-asr.fr> wrote:
Bonjour à tous,
Bonjour,
Je suis à la recherche de pistes / retour d'expériences pour optimiser les temps de réponse d'une application Web PHP (qui est en fait un jeux flash fonctionnant en appel WebService). On retrouve également tout les médias utilisés par le jeux.
Mon architecture est en l'état la suivante :
Un serveur frontal HAPROXY qui redirige les requêtes vers un pool de frontaux HTTP ainsi que vers un pool de media static. Les frontaux HTTP sont des apaches / Les serveurs medias sont des lighttpd.
J'envisage de déployer des instances VARNISH sur mon frontal HAPROXY pour cacher les accès aux médias. J'aurai alors une chaine HAPROXY <=> VARNISH <=> BACKEND
Cela a t'il du sens pour vous ? D'une manière générale quelles sont les "killers app" que vous avez mis en ouvre dans vos architectures web ? Merci par avance pour toutes les idées que vous pourrez m'apporter dans ma quête de perf :)
De manière générale, plutot que de rechercher le démon à la mode, qui certes optimisera l'infra, je préfère travailler sur les points critiques. As tu pu trouver le bottleneck de ton infra actuelle? Par exemple, si c'est MySQL qui rame, ton varnish ne servira pas forcément à grand chose. Une fois le bottleneck identifié, nous pourrons avoir une meilleure vision de tes besoins, et te donner des conseils plus sains. Cordialement, _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
2011/9/5 vincent finet <vincent.finet@viveris-asr.fr>:
Merci pour vos réponses avisées.
Je ne sais en fait pas vraiment ou se situe le goulot. En l'état les perfs sont bonnes et l'architecture bien dimensionnée (tout les indicateurs aux verts dans Nagios).
J'aimerai cependant encore améliorer la chose pour que l'application charge plus vite et pour pouvoir faire face à une charge plus importante.
En pratique cela veut dire : --> Récupérer des fichiers plus vite ( varnish en amont de mes serveurs backend ? autre ?)
Le but serait d'avoir le static au plus prêt de l'utilisateur. Selon le besoin ce n'est pas forcément nécessaire.
--> Computer des appels WS PHP plus vite ( optimiser PHP : HipHop PHP ? mmcache ? autre ? / optimiser Mysql : ?)
C'est quoi comme appli ? (type/dimension)
Cdt
Vincent Finet
Viveris - ASR Ingénieur système et réseau Mail : vincent.finet@viveris-asr.fr Tel : 01 55 19 47 47 Mob : 06 88 56 27 73
-----Original Message----- From: frsag-bounces@frsag.org on behalf of Richard DEMONGEOT Sent: Mon 05/09/2011 10:55 To: French SysAdmin Group Subject: Re: [FRsAG] Optimisation architecture Web / Retour d'experience ?
On Mon, 5 Sep 2011 10:43:06 +0200, "vincent finet" <vincent.finet@viveris-asr.fr> wrote:
Bonjour à tous,
Bonjour,
Je suis à la recherche de pistes / retour d'expériences pour optimiser les temps de réponse d'une application Web PHP (qui est en fait un jeux flash fonctionnant en appel WebService). On retrouve également tout les médias utilisés par le jeux.
Mon architecture est en l'état la suivante :
Un serveur frontal HAPROXY qui redirige les requêtes vers un pool de frontaux HTTP ainsi que vers un pool de media static. Les frontaux HTTP sont des apaches / Les serveurs medias sont des lighttpd.
J'envisage de déployer des instances VARNISH sur mon frontal HAPROXY pour cacher les accès aux médias. J'aurai alors une chaine HAPROXY <=> VARNISH <=> BACKEND
Cela a t'il du sens pour vous ? D'une manière générale quelles sont les "killers app" que vous avez mis en ouvre dans vos architectures web ? Merci par avance pour toutes les idées que vous pourrez m'apporter dans ma quête de perf :)
De manière générale, plutot que de rechercher le démon à la mode, qui certes optimisera l'infra, je préfère travailler sur les points critiques.
As tu pu trouver le bottleneck de ton infra actuelle? Par exemple, si c'est MySQL qui rame, ton varnish ne servira pas forcément à grand chose.
Une fois le bottleneck identifié, nous pourrons avoir une meilleure vision de tes besoins, et te donner des conseils plus sains.
Cordialement, _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Steven Le Roux Jabber-ID : Steven@jabber.fr 0x39494CCB <steven@le-roux.info> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
L'application est un jeux facebook (en flash qui fait des appels WS + fichiers data). Vincent Finet Viveris - ASR Ingénieur système et réseau Mail : vincent.finet@viveris-asr.fr Tel : 01 55 19 47 47 Mob : 06 88 56 27 73 -----Original Message----- From: frsag-bounces@frsag.org on behalf of Steven Le Roux Sent: Mon 05/09/2011 11:19 To: French SysAdmin Group Subject: Re: [FRsAG] Optimisation architecture Web / Retour d'experience ? 2011/9/5 vincent finet <vincent.finet@viveris-asr.fr>:
Merci pour vos réponses avisées.
Je ne sais en fait pas vraiment ou se situe le goulot. En l'état les perfs sont bonnes et l'architecture bien dimensionnée (tout les indicateurs aux verts dans Nagios).
J'aimerai cependant encore améliorer la chose pour que l'application charge plus vite et pour pouvoir faire face à une charge plus importante.
En pratique cela veut dire : --> Récupérer des fichiers plus vite ( varnish en amont de mes serveurs backend ? autre ?)
Le but serait d'avoir le static au plus prêt de l'utilisateur. Selon le besoin ce n'est pas forcément nécessaire.
--> Computer des appels WS PHP plus vite ( optimiser PHP : HipHop PHP ? mmcache ? autre ? / optimiser Mysql : ?)
C'est quoi comme appli ? (type/dimension)
Cdt
Vincent Finet
Viveris - ASR Ingénieur système et réseau Mail : vincent.finet@viveris-asr.fr Tel : 01 55 19 47 47 Mob : 06 88 56 27 73
-----Original Message----- From: frsag-bounces@frsag.org on behalf of Richard DEMONGEOT Sent: Mon 05/09/2011 10:55 To: French SysAdmin Group Subject: Re: [FRsAG] Optimisation architecture Web / Retour d'experience ?
On Mon, 5 Sep 2011 10:43:06 +0200, "vincent finet" <vincent.finet@viveris-asr.fr> wrote:
Bonjour à tous,
Bonjour,
Je suis à la recherche de pistes / retour d'expériences pour optimiser les temps de réponse d'une application Web PHP (qui est en fait un jeux flash fonctionnant en appel WebService). On retrouve également tout les médias utilisés par le jeux.
Mon architecture est en l'état la suivante :
Un serveur frontal HAPROXY qui redirige les requêtes vers un pool de frontaux HTTP ainsi que vers un pool de media static. Les frontaux HTTP sont des apaches / Les serveurs medias sont des lighttpd.
J'envisage de déployer des instances VARNISH sur mon frontal HAPROXY pour cacher les accès aux médias. J'aurai alors une chaine HAPROXY <=> VARNISH <=> BACKEND
Cela a t'il du sens pour vous ? D'une manière générale quelles sont les "killers app" que vous avez mis en ouvre dans vos architectures web ? Merci par avance pour toutes les idées que vous pourrez m'apporter dans ma quête de perf :)
De manière générale, plutot que de rechercher le démon à la mode, qui certes optimisera l'infra, je préfère travailler sur les points critiques.
As tu pu trouver le bottleneck de ton infra actuelle? Par exemple, si c'est MySQL qui rame, ton varnish ne servira pas forcément à grand chose.
Une fois le bottleneck identifié, nous pourrons avoir une meilleure vision de tes besoins, et te donner des conseils plus sains.
Cordialement, _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Steven Le Roux Jabber-ID : Steven@jabber.fr 0x39494CCB <steven@le-roux.info> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On Mon, 5 Sep 2011 11:15:02 +0200, "vincent finet" <vincent.finet@viveris-asr.fr> wrote:
Merci pour vos réponses avisées.
Re,
Je ne sais en fait pas vraiment ou se situe le goulot. En l'état les perfs sont bonnes et l'architecture bien dimensionnée (tout les indicateurs aux verts dans Nagios).
J'aimerai cependant encore améliorer la chose pour que l'application charge plus vite et pour pouvoir faire face à une charge plus importante.
En pratique cela veut dire : --> Récupérer des fichiers plus vite ( varnish en amont de mes serveurs backend ? autre ?) --> Computer des appels WS PHP plus vite ( optimiser PHP : HipHop PHP ? mmcache ? autre ? / optimiser Mysql : ?)
L'idéal serai de faire tout une série de bench. Timers à tire la rigo dans ton appli (et donc logs, soit sur du SQL soit sur du texte standard). Et coté client, toute une batterie de test avec firebug, par exemple, qui va te définir les parties lentes à charger. Ainsi, tu verra, que par exemple, la page "toto.php" met 2 dizièmes, là ou la page tutu.php en met 12. Dans ce cas, l'optimisation passe par le code. Si les lenteurs sont similaire pour un type de page, voir si elles sont "normales" ou dans la moyenne haute par rapport aux autres sites. Ces tests (y compris avec des apache bench à tire la rigo / du wget ou autre / un parsing de site accéléré / toussa) te permettront d'identifier le bottleneck de l'infra, et donc de savoir ou travailler.
Cdt
Cdt,
Effectivement tu as raison une partie de la réponse passe indéniablement par ab / firebug. C'est ce que j'avais commencé à faire et qui tendait à confirmer qu'un cache au niveau du reverse proxy permettrait déja de gagner de la perf au niveau du chargement des médias statiques. Je vais donc continuer dans cette voie. Merci pour vos réponses. Vincent Finet Viveris - ASR Ingénieur système et réseau Mail : vincent.finet@viveris-asr.fr Tel : 01 55 19 47 47 Mob : 06 88 56 27 73 -----Original Message----- From: frsag-bounces@frsag.org on behalf of Richard DEMONGEOT Sent: Mon 05/09/2011 11:28 To: French SysAdmin Group Subject: Re: [FRsAG] Optimisation architecture Web / Retour d'experience ? On Mon, 5 Sep 2011 11:15:02 +0200, "vincent finet" <vincent.finet@viveris-asr.fr> wrote:
Merci pour vos réponses avisées.
Re,
Je ne sais en fait pas vraiment ou se situe le goulot. En l'état les perfs sont bonnes et l'architecture bien dimensionnée (tout les indicateurs aux verts dans Nagios).
J'aimerai cependant encore améliorer la chose pour que l'application charge plus vite et pour pouvoir faire face à une charge plus importante.
En pratique cela veut dire : --> Récupérer des fichiers plus vite ( varnish en amont de mes serveurs backend ? autre ?) --> Computer des appels WS PHP plus vite ( optimiser PHP : HipHop PHP ? mmcache ? autre ? / optimiser Mysql : ?)
L'idéal serai de faire tout une série de bench. Timers à tire la rigo dans ton appli (et donc logs, soit sur du SQL soit sur du texte standard). Et coté client, toute une batterie de test avec firebug, par exemple, qui va te définir les parties lentes à charger. Ainsi, tu verra, que par exemple, la page "toto.php" met 2 dizièmes, là ou la page tutu.php en met 12. Dans ce cas, l'optimisation passe par le code. Si les lenteurs sont similaire pour un type de page, voir si elles sont "normales" ou dans la moyenne haute par rapport aux autres sites. Ces tests (y compris avec des apache bench à tire la rigo / du wget ou autre / un parsing de site accéléré / toussa) te permettront d'identifier le bottleneck de l'infra, et donc de savoir ou travailler.
Cdt
Cdt, _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 05/09/2011 11:37, vincent finet wrote:
Effectivement tu as raison une partie de la réponse passe indéniablement par ab / firebug.
C'est ce que j'avais commencé à faire et qui tendait à confirmer qu'un cache au niveau du reverse proxy permettrait déja de gagner de la perf au niveau du chargement des médias statiques.
Heu, Il y a que moi que ça choque ? Garder en cache des fichiers statiques, je ne vois pas trop l'intérêt. Es tu sûr que cela serait réellement plus performant ? J'en doute... ou alors effectivement, il y a un problème. -- Mathieu Goessens IT consultant. gebura@poolp.org + 33 6 07 91 54 87 http://gebura.eu.org
Le 6 sept. 2011 à 06:40, Mathieu Goessens <gebura@poolp.org> a écrit :
On 05/09/2011 11:37, vincent finet wrote:
Effectivement tu as raison une partie de la réponse passe indéniablement par ab / firebug.
C'est ce que j'avais commencé à faire et qui tendait à confirmer qu'un cache au niveau du reverse proxy permettrait déja de gagner de la perf au niveau du chargement des médias statiques.
Heu,
Il y a que moi que ça choque ? Garder en cache des fichiers statiques, je ne vois pas trop l'intérêt. Es tu sûr que cela serait réellement plus performant ? J'en doute... ou alors effectivement, il y a un problème.
Au contraire, c'est même plutôt la base et le type de reverse proxy le plus simple... Ça permet de décharger les frontaux de nombreuses requêtes (ils peuvent ainsi se concentrer sur le dynamique...) et de fortement booster les temps de réponses sur tout le contenu statique (css, images, videos...). Pour nous (reverse proxy et "CDN" maison pour nos clients), c'est : nginx et ramfs a gogo avec du PCIe SSD pour certains besoins (volumes et budget plus important...). PS: Il va de soit que le gain sera en rapport avec la performance du matériel et du stockage utilisé sur les reverse proxy (ce qui explique nos choix ci-dessus car les IOPS sont ici l'un des points clés). Cordialement, Yacine kheddache / www.alyseo.com
On 06/09/2011 07:09, Yacine Kheddache wrote:
Le 6 sept. 2011 à 06:40, Mathieu Goessens <gebura@poolp.org> a écrit :
On 05/09/2011 11:37, vincent finet wrote:
Effectivement tu as raison une partie de la réponse passe indéniablement par ab / firebug.
C'est ce que j'avais commencé à faire et qui tendait à confirmer qu'un cache au niveau du reverse proxy permettrait déja de gagner de la perf au niveau du chargement des médias statiques.
Heu,
Il y a que moi que ça choque ? Garder en cache des fichiers statiques, je ne vois pas trop l'intérêt. Es tu sûr que cela serait réellement plus performant ? J'en doute... ou alors effectivement, il y a un problème.
Au contraire, c'est même plutôt la base et le type de reverse proxy le plus simple...
Ça permet de décharger les frontaux de nombreuses requêtes (ils peuvent ainsi se concentrer sur le dynamique...) et de fortement booster les temps de réponses sur tout le contenu statique (css, images, videos...).
Pour nous (reverse proxy et "CDN" maison pour nos clients), c'est : nginx et ramfs a gogo avec du PCIe SSD pour certains besoins (volumes et budget plus important...).
PS: Il va de soit que le gain sera en rapport avec la performance du matériel et du stockage utilisé sur les reverse proxy (ce qui explique nos choix ci-dessus car les IOPS sont ici l'un des points clés).
En l'occurrence ici On 05/09/2011 10:43, vincent finet wrote:
Mon architecture est en l'état la suivante :
Un serveur frontal HAPROXY qui redirige les requêtes vers un pool de frontaux HTTP ainsi que vers un pool de media static. Les frontaux HTTP sont des apaches / Les serveurs medias sont des lighttpd.
Donc, ces fichiers sont déjà traités différemment ... Quel serait alors l'intérêt à mettre un reverse proxy devant et surtout de mettre du cache sur ces fichiers ? -- Mathieu Goessens IT consultant. gebura@poolp.org + 33 6 07 91 54 87 http://gebura.eu.org
Le 6 sept. 2011 à 07:26, Mathieu Goessens <gebura@poolp.org> a écrit :
On 06/09/2011 07:09, Yacine Kheddache wrote:
Le 6 sept. 2011 à 06:40, Mathieu Goessens <gebura@poolp.org> a écrit :
On 05/09/2011 11:37, vincent finet wrote:
Effectivement tu as raison une partie de la réponse passe indéniablement par ab / firebug.
C'est ce que j'avais commencé à faire et qui tendait à confirmer qu'un cache au niveau du reverse proxy permettrait déja de gagner de la perf au niveau du chargement des médias statiques.
Heu,
Il y a que moi que ça choque ? Garder en cache des fichiers statiques, je ne vois pas trop l'intérêt. Es tu sûr que cela serait réellement plus performant ? J'en doute... ou alors effectivement, il y a un problème.
Au contraire, c'est même plutôt la base et le type de reverse proxy le plus simple...
Ça permet de décharger les frontaux de nombreuses requêtes (ils peuvent ainsi se concentrer sur le dynamique...) et de fortement booster les temps de réponses sur tout le contenu statique (css, images, videos...).
Pour nous (reverse proxy et "CDN" maison pour nos clients), c'est : nginx et ramfs a gogo avec du PCIe SSD pour certains besoins (volumes et budget plus important...).
PS: Il va de soit que le gain sera en rapport avec la performance du matériel et du stockage utilisé sur les reverse proxy (ce qui explique nos choix ci-dessus car les IOPS sont ici l'un des points clés).
En l'occurrence ici
On 05/09/2011 10:43, vincent finet wrote:
Mon architecture est en l'état la suivante :
Un serveur frontal HAPROXY qui redirige les requêtes vers un pool de frontaux HTTP ainsi que vers un pool de media static. Les frontaux HTTP sont des apaches / Les serveurs medias sont des lighttpd.
Donc, ces fichiers sont déjà traités différemment ... Quel serait alors l'intérêt à mettre un reverse proxy devant et surtout de mettre du cache sur ces fichiers ?
Idem: diminuer la latence sur les statiques les plus sollicités (surtout si il y a xTo de statique stocké sur du stockage "lent"). Yacine kheddache / www.alyseo.com
Le 06/09/2011 07:43, Yacine Kheddache a écrit :
Donc, ces fichiers sont déjà traités différemment ... Quel serait alors l'intérêt à mettre un reverse proxy devant et surtout de mettre du cache sur ces fichiers ? Idem: diminuer la latence sur les statiques les plus sollicités (surtout si il y a xTo de statique stocké sur du stockage "lent").
Je rejoins Mathieu : quelles sont les différences entre un reverse proxy qui va récupérer ses pages sur un frontal de statiques qui va lui même les récupérer sur un disque, puis stocker le tout en mémoire; et un serveur statique type nginx qui va directement récupérer les pages sur disque, qui seront mise en cache par le buffer cache de Linux ? -- Greg
En premier lieu, un grand merci à tous pour votre précieux retour dexpérience dont je ferai (jespère) bon usage. Concernant la question "Quel serait lintérêt de mettre un reverse proxy / cache devant mes serveurs de statics" : J'y vois plusieurs intérêt : 1) Soulager mon haproxy qui est en l'état le seul point d'accès de mon architecture et qui voit donc passer le traffic des serveurs d'applis + le traffic média. Je voudrais donc dédier un serveur pour y mettre varnish. Le cache me permettrait (selon mes benchs) de réduire le temps de réponse en supprimant la majorité des requête vers mes backends statics. Cela s'explique en grande partie car ce serveur cache sera en frontal. En l'état quand j'ai testé avec un varnish en local sur mes serveurs statics le gain était nul voir négatif. 2) Selon les résultats en prod je devrais pouvoir supprimer certains de mes serveurs loués statics chez OVH étant donné qu'il seront moins sollicités grâce au cache. Après, n'étant pas un gourou des architectures Web, je suis ouvert à toute suggestion ou questionnement.. Pour la suite, je pense donc m'orienter dans un premier temps vers une solution de bench HALOG + PIMBA pour tirer les conclusions qui s'imposent quand aux bottlenecks. Merci encore Vincent -----Original Message----- From: frsag-bounces@frsag.org on behalf of Mathieu Goessens Sent: Tue 06/09/2011 07:26 To: frsag@frsag.org Subject: Re: [FRsAG] Optimisation architecture Web / Retour d'experience ? On 06/09/2011 07:09, Yacine Kheddache wrote:
Le 6 sept. 2011 à 06:40, Mathieu Goessens <gebura@poolp.org> a écrit :
On 05/09/2011 11:37, vincent finet wrote:
Effectivement tu as raison une partie de la réponse passe indéniablement par ab / firebug.
C'est ce que j'avais commencé à faire et qui tendait à confirmer qu'un cache au niveau du reverse proxy permettrait déja de gagner de la perf au niveau du chargement des médias statiques.
Heu,
Il y a que moi que ça choque ? Garder en cache des fichiers statiques, je ne vois pas trop l'intérêt. Es tu sûr que cela serait réellement plus performant ? J'en doute... ou alors effectivement, il y a un problème.
Au contraire, c'est même plutôt la base et le type de reverse proxy le plus simple...
Ça permet de décharger les frontaux de nombreuses requêtes (ils peuvent ainsi se concentrer sur le dynamique...) et de fortement booster les temps de réponses sur tout le contenu statique (css, images, videos...).
Pour nous (reverse proxy et "CDN" maison pour nos clients), c'est : nginx et ramfs a gogo avec du PCIe SSD pour certains besoins (volumes et budget plus important...).
PS: Il va de soit que le gain sera en rapport avec la performance du matériel et du stockage utilisé sur les reverse proxy (ce qui explique nos choix ci-dessus car les IOPS sont ici l'un des points clés).
En l'occurrence ici On 05/09/2011 10:43, vincent finet wrote:
Mon architecture est en l'état la suivante :
Un serveur frontal HAPROXY qui redirige les requêtes vers un pool de frontaux HTTP ainsi que vers un pool de media static. Les frontaux HTTP sont des apaches / Les serveurs medias sont des lighttpd.
Donc, ces fichiers sont déjà traités différemment ... Quel serait alors l'intérêt à mettre un reverse proxy devant et surtout de mettre du cache sur ces fichiers ? -- Mathieu Goessens IT consultant. gebura@poolp.org + 33 6 07 91 54 87 http://gebura.eu.org _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 06/09/11 08:58, Gregory Duchatelet a écrit :
Le 06/09/2011 07:43, Yacine Kheddache a écrit :
Donc, ces fichiers sont déjà traités différemment ... Quel serait alors l'intérêt à mettre un reverse proxy devant et surtout de mettre du cache sur ces fichiers ? Idem: diminuer la latence sur les statiques les plus sollicités (surtout si il y a xTo de statique stocké sur du stockage "lent").
Je rejoins Mathieu : quelles sont les différences entre un reverse proxy qui va récupérer ses pages sur un frontal de statiques qui va lui même les récupérer sur un disque, puis stocker le tout en mémoire; et un serveur statique type nginx qui va directement récupérer les pages sur disque, qui seront mise en cache par le buffer cache de Linux ?
Le buffer cache de linux ne fait pas des miracles et les accès disques restent toujours assez élevés. Si tes proxy ont accès au FS qui contient les données effectivement il peut être intéressant de sauter un intermédiaire. Par contre je suis plutôt pour le fait que les proxy se constitue un cache en local sur un média lent et mettent en memcache les éléments les plus demandé. La raison est simple, cas réel, grosse plateforme web multi langues qui pousse H24 à débit constant sans l'effet de vague horaires qui nous permet de faire des maintenances. La plateforme fait une migration, cold restart pour les mysql, les web. Si tous les proxy du client à travers le monde (Asie, Europe, USA) avaient du retransférer les données depuis les serveurs front ou directement le FS partagé la plateforme ne serait jamais repartie. En ayant en cache disque local pratiquement tous les statics, les proxy ont été opérationnels immédiatement. La plateforme en cold restart a déjà bien souffert derrière autant ne pas lui rajouter de la charge inutile.
Bonjour, Gregory Duchatelet <greg-frsag@duchatelet.net> : [...]
Je rejoins Mathieu : quelles sont les différences entre un reverse proxy qui va récupérer ses pages sur un frontal de statiques qui va lui même les récupérer sur un disque, puis stocker le tout en mémoire; et un serveur statique type nginx qui va directement récupérer les pages sur disque, qui seront mise en cache par le buffer cache de Linux ?
Le premier cas impose une copie kernel <-> userspace pour la mise en cache et une autre à chaque restitution. Suivant que la mise en oeuvre est ou non naïve, ça risque d'impliquer de vraies copies bien lourdes (et pas juste des acrobaties de mmap). Apparemment nginx effectue un sendfile sans passage des données par l'espace utilisateur. Pour peu qu'on se décharge du calcul des sommes de contrôle IP sur le matériel, ça devient *très* économique pour des données cachées. J'ai bon ? -- Ueimor
Bonjour, en lisant votre problématique, je trouve que ce que vous exposé reste est encore trop vague. Pour être efficace, mon expérience m'a indiqué qu'il est nécessaire d'avoir entre autre un monitoring temps de réponse entre chaque éléments de votre architecture en particulier durant la monté en charge pour par exemple voir goulot d'étranglement et les temps de bascule. Il existe à mon sens beaucoup de paramètres entrant en jeux dans l'optimisation d'une architecture d'accès. Des tunning kernel nottament de la stack TCP/IP, du nombre de handlers système, des timeout, (...) en passant par la politique de LB avec/sans persistance de session selon quel critère (quid des politiques), des caching opérés (politique de caching ? Edge Side Include, CDN), de la réécriture protocolaire (avec ou sans contenu), de la terminaison SSL, de la compression, de la gestion des chunk, de la sécurité et des blacklist, de l'indexation et/ou du partitionnement des bonne table dans la DB, du caching de requête ... En bref, une approche plus ciblée de votre probélmatique en précisant les bottleneck structurants et impactants pour vous et qui vous sont préjudiciable sont "sine qua non" pour optimiser au mieux votre architecture. Par exemple avez-vous pensez à bien tuner vos worker (max, min et spare) Apache en fonction de vos access log et autres stats ? Mon expérience m'a également appris que les éléments d'architecture les plus en amont de la chaine d'accès doivent implémenter des sockets event pour scaler correctement face au model multi-thread/multi-proc nettement moins performant avec la montée en charge. Ceci passe en général par un vrai projet de fiaibilisation avec des actions plus ou moins prioritaire selon vos besoins et votre budget dans pas mal de cas et ne peut à mon avis être rapidement élucidé à moins d'un véritable SPOF dans votre archi/conf ce qu'un monitoring fin des temps de réponse/code de retour ne mettra pas longtemps à mettre en évidence ;-) HTH. Cordialement, J.M. Le 6 septembre 2011 11:16, Francois Romieu <romieu@fr.zoreil.com> a écrit :
Bonjour,
Gregory Duchatelet <greg-frsag@duchatelet.net> : [...]
Je rejoins Mathieu : quelles sont les différences entre un reverse proxy qui va récupérer ses pages sur un frontal de statiques qui va lui même les récupérer sur un disque, puis stocker le tout en mémoire; et un serveur statique type nginx qui va directement récupérer les pages sur disque, qui seront mise en cache par le buffer cache de Linux ?
Le premier cas impose une copie kernel <-> userspace pour la mise en cache et une autre à chaque restitution. Suivant que la mise en oeuvre est ou non naïve, ça risque d'impliquer de vraies copies bien lourdes (et pas juste des acrobaties de mmap).
Apparemment nginx effectue un sendfile sans passage des données par l'espace utilisateur. Pour peu qu'on se décharge du calcul des sommes de contrôle IP sur le matériel, ça devient *très* économique pour des données cachées.
J'ai bon ?
-- Ueimor _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 06/09/11 06:40, Mathieu Goessens a écrit :
On 05/09/2011 11:37, vincent finet wrote:
Effectivement tu as raison une partie de la réponse passe indéniablement par ab / firebug.
C'est ce que j'avais commencé à faire et qui tendait à confirmer qu'un cache au niveau du reverse proxy permettrait déja de gagner de la perf au niveau du chargement des médias statiques. Heu,
Il y a que moi que ça choque ? Garder en cache des fichiers statiques, je ne vois pas trop l'intérêt. Es tu sûr que cela serait réellement plus performant ? J'en doute... ou alors effectivement, il y a un problème.
Cela dépend de plusieurs choses. J'ai déjà vu des proxy pour les statics qui avaient plusieurs millions de petits fichiers, la taille totale n'était pas grande mais les accès disque étaient horriblement catastrophique (accès aléatoire bien trop nombreux). Pire cela usait prématurément les disques (changement tous les 6 mois). Il était alors plus judicieux de gaver ces machines de mémoire et de mettre la très grande majorité de ces fichiers dans soit un memcache branché sur le reverse proxy, soit un montage shm avec les fichiers dedans (si on l'ensemble contient dans la ram allouée). La machine que le client pensait sous dimensionné s'est révélé très performante grâce à cela. L'avantage avec memcache c'est que l'on est pas obligé de tout mettre en ram et qu'il remplace les fichiers peut utiliser ou les plus vieux par ceux qui sont demandés. Bref ca dépend des cas mais c'est une solution très performante quand cela est possible.
Excerpts from vincent finet's message of Mon Sep 05 11:37:44 +0200 2011:
Effectivement tu as raison une partie de la réponse passe indéniablement par ab / firebug.
C'est ce que j'avais commencé à faire et qui tendait à confirmer qu'un cache au niveau du reverse proxy permettrait déja de gagner de la perf au niveau du chargement des médias statiques.
J'ai tendance à prendre les benchmarks firebug avec des pincettes, car des paramètres "parasites" risquent d'influencer les mesures effectuées. Par exemple la latence réseau, la charge de la machine qui exécute firebug, etc. Bref, des paramètres qui sont hors de ta juridiction en situation de production. Comme tout passe déjà par HAProxy dans ton cas, c'est idéal. HAProxy est le mieux placé pour savoir combien de temps s'écoule entre le moment où un client a terminé d'envoyer sa requête et le moment où un des backends a terminé d'envoyer la réponse (= tout ce qui se déroule dans ton infrastructure et sur lequel tu as effectivement influence). Ensuite, halog te permet d'y voir plus clair. RLA[¹] est également une possibilité. Bon courage ! Marc [¹] https://github.com/wvanbergen/request-log-analyzer
Bonjour, Un test de charge permet d'identifier les goulots d'étranglement, et aussi d'avoir un référentiel de temps de réponse qui peut te servir d'étalon pour tes optimisations d'architectures. (par exemple avec JMeter tu peux tester les webservices cf. http://s.apache.org/kF ) Sinon, il faut aussi penser aux optimisations de la couche OS (optimisations TCP, kernel), et des différents briques logiciels (en particulier Apache et MySQL). Si tu laisses les valeurs par défaut, cela ne risque pas d'être hautement performant. Les composants comme Varnish ou memcache permettent en effet d'améliorer les choses, mais une mauvaise configuration (standard ou non-orientée performance) fera plus de mal. Par ailleurs, trouver un goulot entre l'utilisateur et le fond du backend devient de plus en plus difficile avec l'ajout de couches (load balance ip, reverse proxy cache, frontaux web/php, cache code, base, etc). Pour résumé, dans les points à vérifier : * faire un petit test de charge (par trop d'utilisateur) pour avoir une référence * optimisation tcp / kernel de l'OS (il y a pas mal d'exemple sur Internet sur les choses importantes. Ce redbook pour Linux est plutôt bien http://www.redbooks.ibm.com/abstracts/redp4285.html?Open= * faire le même test de charge et comparer * optimiser les briques logiques : Apache (nb thread, activation mod_cache, mod_expire, mod_deflate entre autres), memcache (compression des flux si sur serveurs distant), varnish (règles de cache optimales), mysql (augmenter la mémoire allouée pour monter les tables en mémoire entre autre) * faire le même test de charge et comparer L'idée est de mesurer l'amélioration. A+ Milamber Le 05/09/2011 09:28, Richard DEMONGEOT a ecrit :
On Mon, 5 Sep 2011 11:15:02 +0200, "vincent finet" <vincent.finet@viveris-asr.fr> wrote:
Merci pour vos réponses avisées.
Re,
Je ne sais en fait pas vraiment ou se situe le goulot. En l'état les perfs sont bonnes et l'architecture bien dimensionnée
(tout
les indicateurs aux verts dans Nagios).
J'aimerai cependant encore améliorer la chose pour que l'application charge plus vite et pour pouvoir faire face à une charge plus
importante.
En pratique cela veut dire : --> Récupérer des fichiers plus vite ( varnish en amont de mes serveurs backend ? autre ?) --> Computer des appels WS PHP plus vite ( optimiser PHP : HipHop PHP ? mmcache ? autre ? / optimiser Mysql : ?)
L'idéal serai de faire tout une série de bench.
Timers à tire la rigo dans ton appli (et donc logs, soit sur du SQL soit sur du texte standard).
Et coté client, toute une batterie de test avec firebug, par exemple, qui va te définir les parties lentes à charger.
Ainsi, tu verra, que par exemple, la page "toto.php" met 2 dizièmes, là ou la page tutu.php en met 12. Dans ce cas, l'optimisation passe par le code.
Si les lenteurs sont similaire pour un type de page, voir si elles sont "normales" ou dans la moyenne haute par rapport aux autres sites.
Ces tests (y compris avec des apache bench à tire la rigo / du wget ou autre / un parsing de site accéléré / toussa) te permettront d'identifier le bottleneck de l'infra, et donc de savoir ou travailler.
Cdt
Cdt, _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 05/09/2011 12:01, Milamber wrote:
* optimisation tcp / kernel de l'OS (il y a pas mal d'exemple sur Internet sur les choses importantes. Ce redbook pour Linux est plutôt bien http://www.redbooks.ibm.com/abstracts/redp4285.html?Open=
Bonjour, Désolé, mais ce serait une annerie: depuis l'introduction des patchs hérités du projet web100.org dans le kernel (quelque-part vers le 2.6.16), celui ci affine ces réglages tout seul. Sauf besoin très spécifique, il est peu recommandé de repasser par dessus, cela risquerait de dégrader les performances. Cdlt, -- Mathieu Goessens IT consultant. gebura@poolp.org + 33 6 07 91 54 87 http://gebura.eu.org
Désolé, mais ce serait une annerie: depuis l'introduction des patchs hérités du projet web100.org dans le kernel (quelque-part vers le 2.6.16), celui ci affine ces réglages tout seul. Sauf besoin très spécifique, il est peu recommandé de repasser par dessus, cela risquerait de dégrader les performances.
Avez-vous des références sur l'intégration de ces patchs dans le kernel et les optimisations qu'ils permettent ? Le site de web10g.org, successeur de web100.org semble dire que les patchs ne sont pas intégrés dans le kernel, mais qu'il doivent être appliqués manuellement. Florian
e dégrader les performances.
Avez-vous des références sur l'intégration de ces patchs dans le kernel et les optimisations qu'ils permettent ? Le site de web10g.org, successeur de web100.org semble dire que les patchs ne sont pas intégrés dans le kernel, mais qu'il doivent être appliqués manuellement.
http://web10g.org/index.php?option=com_content&view=article&id=46&Itemid=67 The plan is to address all of these weaknesses by producing a production quality implementation of the RFC specified standard TCP instrumentation. That implementation would be derived from the existing Web100 code and targeted to be included in all Linux releases. We have successfully done this once already with TCP autotuning, which was prototyped under Web100, then fully integrated into Linux and is now shipped in every operating system.
On Mon, 5 Sep 2011 11:15:02 +0200, vincent finet wrote:
Merci pour vos réponses avisées.
Je ne sais en fait pas vraiment ou se situe le goulot. En l'état les perfs sont bonnes et l'architecture bien dimensionnée (tout les indicateurs aux verts dans Nagios).
Commence par regarder les i/o wait, requettes lente (mysql).
J'aimerai cependant encore améliorer la chose pour que l'application charge plus vite et pour pouvoir faire face à une charge plus importante.
En pratique cela veut dire : --> Récupérer des fichiers plus vite ( varnish en amont de mes serveurs backend ? autre ?)
Faire du cache ne peut pas être mauvais, varnish a déjà fait ses preuves.
--> Computer des appels WS PHP plus vite ( optimiser PHP : HipHop PHP ? mmcache ? autre ? / optimiser Mysql : ?)
APC (le module php) permet de faire du "cache" d'op-code et donc d’accélérer l’exécution des pages sans forcement toucher au code. memcache peut améliorer les choses mais nécessitera de reprendre le code si je ne me trompe pas (et nécessitera de la mémoire vive en plus ?). Ensuite vérifier la configuration des caches de mysql avec des outils comme mysqltunner, vérifier que le moteur de base de donnée est bien choisi par rapport aux requêtes et au métier. et toujours traquer les requêtes lente/ mal optimisées.
Cdt
Vincent Finet
Viveris - ASR Ingénieur système et réseau Mail : vincent.finet@viveris-asr.fr Tel : 01 55 19 47 47 Mob : 06 88 56 27 73
my 2 cents. -- Thomas
2011/9/5 vincent finet <vincent.finet@viveris-asr.fr>:
Bonjour à tous,
Je suis à la recherche de pistes / retour d’expériences pour optimiser les temps de réponse d'une application Web PHP (qui est en fait un jeux flash fonctionnant en appel WebService). On retrouve également tout les médias utilisés par le jeux.
Mon architecture est en l'état la suivante :
Un serveur frontal HAPROXY qui redirige les requêtes vers un pool de frontaux HTTP ainsi que vers un pool de media static. Les frontaux HTTP sont des apaches / Les serveurs medias sont des lighttpd.
J'envisage de déployer des instances VARNISH sur mon frontal HAPROXY pour cacher les accès aux médias. J'aurai alors une chaine HAPROXY <=> VARNISH <=> BACKEND
Cela a t'il du sens pour vous ? D'une manière générale quelles sont les "killers app" que vous avez mis en œuvre dans vos architectures web ? Merci par avance pour toutes les idées que vous pourrez m'apporter dans ma quête de perf :)
C'est bien déjà. Tu peux ajouter peut être une couche LVS/Keepalived pour assurer une redondance sur ta touche reverse proxy. Tu as une archi mono-site ? Après ça dépend un peu de tes applis, comment elles gèrent les connexions, stateful/stateless ? est-ce du comet ? du websocket ? juste du http classic.. est-ce que ça vaut le coup de mettre de l’agrégation de connexion côté backend, etc...
Vincent Finet
Viveris - ASR Ingénieur système et réseau Mail : vincent.finet@viveris-asr.fr Tel : 01 55 19 47 47 Mob : 06 88 56 27 73
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Steven Le Roux Jabber-ID : Steven@jabber.fr 0x39494CCB <steven@le-roux.info> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
Merci, J'ai déja un heartbeat soft au niveau du reverse HAPROXY ;) Toute l'architecture est chez un hébergeur (OVH pour ne pas le citer) dans un Vrack. Pour l'application c'est du HTTP classique avec gestion des session au niveau de PHP et loadbalancing sticky au niveau du HAPROXY. Je ne saurais dire combien d'utilisateurs mais en moyenne 5Mo/s de traffic in/out au niveau du reverse. Derrière HAPROXY j'ai 8 frontaux Web PHP Apache / 4 serveurs medias static Lighttpd / 1 Mysql Vincent Finet Viveris - ASR Ingénieur système et réseau Mail : vincent.finet@viveris-asr.fr Tel : 01 55 19 47 47 Mob : 06 88 56 27 73 -----Original Message----- From: frsag-bounces@frsag.org on behalf of Steven Le Roux Sent: Mon 05/09/2011 11:15 To: French SysAdmin Group Subject: Re: [FRsAG] Optimisation architecture Web / Retour d'experience ? 2011/9/5 vincent finet <vincent.finet@viveris-asr.fr>:
Bonjour à tous,
Je suis à la recherche de pistes / retour d'expériences pour optimiser les temps de réponse d'une application Web PHP (qui est en fait un jeux flash fonctionnant en appel WebService). On retrouve également tout les médias utilisés par le jeux.
Mon architecture est en l'état la suivante :
Un serveur frontal HAPROXY qui redirige les requêtes vers un pool de frontaux HTTP ainsi que vers un pool de media static. Les frontaux HTTP sont des apaches / Les serveurs medias sont des lighttpd.
J'envisage de déployer des instances VARNISH sur mon frontal HAPROXY pour cacher les accès aux médias. J'aurai alors une chaine HAPROXY <=> VARNISH <=> BACKEND
Cela a t'il du sens pour vous ? D'une manière générale quelles sont les "killers app" que vous avez mis en ouvre dans vos architectures web ? Merci par avance pour toutes les idées que vous pourrez m'apporter dans ma quête de perf :)
C'est bien déjà. Tu peux ajouter peut être une couche LVS/Keepalived pour assurer une redondance sur ta touche reverse proxy. Tu as une archi mono-site ? Après ça dépend un peu de tes applis, comment elles gèrent les connexions, stateful/stateless ? est-ce du comet ? du websocket ? juste du http classic.. est-ce que ça vaut le coup de mettre de l'agrégation de connexion côté backend, etc...
Vincent Finet
Viveris - ASR Ingénieur système et réseau Mail : vincent.finet@viveris-asr.fr Tel : 01 55 19 47 47 Mob : 06 88 56 27 73
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Steven Le Roux Jabber-ID : Steven@jabber.fr 0x39494CCB <steven@le-roux.info> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Tout d'abord, as-tu une vision des perfs *actuelles* de l'appli ? Si non, pas la peine de te lancer, tu ne pourras pas mesurer les améliorations (graph de temps de chargement de pages, réultats YSLow/PageSpeed, Pinba pour le code PHP) Ensuite, commence par une revue de la configuration de l'existant: - Désactiver les module Apache inutiles - Revoir les params MySQL pour maximiser l'utilisation mémoire - Activer (et exploiter) les slow-log MySQL Identifie les goulots d'étranglement dans le code (grâce à Pinba par exemple, y en a sûrement) et fais-les corriger. Enfin, et seulement à ce moment là, tu pourras envisager d'ajouter une couche de cache. Globalement, seule une parfaite connaissance de l'appli et de l'infra sous-jacente te permettront d'optimiser son fonctionnement dans de bonnes conditions. De la même façon, sans preuve des améliorations, je ne vois pas trop comment tu pourras justifier les investissements et/ou le temps passer dessus. En conclusion, sans plus d'infos, l'ajout d'un Varnish n'a pas particulièrement de sens pour moi. En matière de "killer app", nous gérons une appli LAMP (jeux facebook itou) qui support en pic plus de 200k requêtes par minute avec des temps de réponse inférieurs à la seconde. Le tout est hébergé sur 50 fronts apache et, bien sûr, quelques serveurs memcache, redis, mysql en backend. Naturellement, tout le contenu statique est sur CDN Cordialement, JB Le 05/09/11 10:43, vincent finet a écrit :
Bonjour à tous,
Je suis à la recherche de pistes / retour dexpériences pour optimiser les temps de réponse d'une application Web PHP (qui est en fait un jeux flash fonctionnant en appel WebService). On retrouve également tout les médias utilisés par le jeux.
Mon architecture est en l'état la suivante :
Un serveur frontal HAPROXY qui redirige les requêtes vers un pool de frontaux HTTP ainsi que vers un pool de media static. Les frontaux HTTP sont des apaches / Les serveurs medias sont des lighttpd.
J'envisage de déployer des instances VARNISH sur mon frontal HAPROXY pour cacher les accès aux médias. J'aurai alors une chaine HAPROXY <=> VARNISH <=> BACKEND
Cela a t'il du sens pour vous ? D'une manière générale quelles sont les "killers app" que vous avez mis en uvre dans vos architectures web ? Merci par avance pour toutes les idées que vous pourrez m'apporter dans ma quête de perf :)
Vincent Finet
Viveris - ASR Ingénieur système et réseau Mail : vincent.finet@viveris-asr.fr Tel : 01 55 19 47 47 Mob : 06 88 56 27 73
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
'jour ----- Mail original -----
Tout d'abord, as-tu une vision des perfs *actuelles* de l'appli ?
Comme les autres, sans ça, pas la peine d'aller plus loin. Et un découpage des perfs aussi ce serait bien (temps passé à résoudre le DNS, la réponse des HA proxy, la réponse des apache derrière, la réponse mysql, la réponse de l'appli qui fait le flash, etc etc etc)
Si non, pas la peine de te lancer, tu ne pourras pas mesurer les améliorations (graph de temps de chargement de pages, réultats YSLow/PageSpeed, Pinba pour le code PHP)
Pas mieux.
- Revoir les params MySQL pour maximiser l'utilisation mémoire - Activer (et exploiter) les slow-log MySQL
Utiliser Percona à la place de mySQL ? David
On Monday 05 September 2011 12:24:11 Jean Baptiste Favre wrote:
Identifie les goulots d'étranglement dans le code (grâce à Pinba par exemple, y en a sûrement) et fais-les corriger.
Pour rentrer plus dans le code, le combo xdebug/kcachegrind est très sympa aussi. <raconte sa vie> De mon côté, j'ai sauvé un serveur de la noyade en implémentant la gestion du cache 304 pour les clients. En gros, on avait chaque client qui faisait un poll sur une table de 100000 entrées toutes les 5 secondes (plus d'autres trucs... On dépassait la requête par seconde par client). L'astuce était simple : à chaque fois que quelqu'un affiche une page, on ajoute l'URL et le numéro de session dans une table MySQL de type MEMORY. Comme ça, la prochaine fois qu'il demande la même page, on lui sert un 304 avant même d'avoir chargé tous les fichiers PHP etc. La technique après c'est bien sûr que quand on reçoit une requête en POST, on vide la table, comme ça on re-génère toutes les URL. Bon dans mon contexte c'était une appli avec peu d'utilisateurs et du contenu qui change relativement peu souvent, donc ça a super bien marché (on a divisé la charge par 10). </raconte sa vie> My 2 bitcoins, -- Rémy Sanchez
On 07/09/2011 20:08, Rémy Sanchez wrote:
On Monday 05 September 2011 12:24:11 Jean Baptiste Favre wrote:
Identifie les goulots d'étranglement dans le code (grâce à Pinba par exemple, y en a sûrement) et fais-les corriger.
Pour rentrer plus dans le code, le combo xdebug/kcachegrind est très sympa aussi.
<raconte sa vie> De mon côté, j'ai sauvé un serveur de la noyade en implémentant la gestion du cache 304 pour les clients. En gros, on avait chaque client qui faisait un poll sur une table de 100000 entrées toutes les 5 secondes (plus d'autres trucs... On dépassait la requête par seconde par client).
L'astuce était simple : à chaque fois que quelqu'un affiche une page, on ajoute l'URL et le numéro de session dans une table MySQL de type MEMORY. Comme ça, la prochaine fois qu'il demande la même page, on lui sert un 304 avant même d'avoir chargé tous les fichiers PHP etc. La technique après c'est bien sûr que quand on reçoit une requête en POST, on vide la table, comme ça on re-génère toutes les URL.
Bon dans mon contexte c'était une appli avec peu d'utilisateurs et du contenu qui change relativement peu souvent, donc ça a super bien marché (on a divisé la charge par 10). </raconte sa vie>
My 2 bitcoins,
C'est probablement un résumé rapide, mais de manière générale si l'idée est de balancer un 304 quasi systématique durant les N prochaines secondes, l'idéal est encore d'envoyer un joli entête expires d'une trentaine de seconde. La requête HTTP sera encore plus rapide, vu qu'elle ne se fera pas.
On Wednesday 07 September 2011 20:15:19 Olivier Bonvalet wrote:
C'est probablement un résumé rapide, mais de manière générale si l'idée est de balancer un 304 quasi systématique durant les N prochaines secondes, l'idéal est encore d'envoyer un joli entête expires d'une trentaine de seconde. La requête HTTP sera encore plus rapide, vu qu'elle ne se fera pas.
Un tchat interactif avec 30 secondes de lag, c'est assez moyen. Par contre, la solution mieux++ c'est d'être buzzword complient et de faire du push (ce qu'on fait maintenant). En gros, de l'attente passive VS du spinlock... La morale de l'histoire étant surtout : une gestion intelligente du cache permet un sacré gain de perfs. -- Rémy Sanchez
On 07/09/2011 21:13, Rémy Sanchez wrote:
On Wednesday 07 September 2011 20:15:19 Olivier Bonvalet wrote:
C'est probablement un résumé rapide, mais de manière générale si l'idée est de balancer un 304 quasi systématique durant les N prochaines secondes, l'idéal est encore d'envoyer un joli entête expires d'une trentaine de seconde. La requête HTTP sera encore plus rapide, vu qu'elle ne se fera pas.
Un tchat interactif avec 30 secondes de lag, c'est assez moyen. Par contre, la solution mieux++ c'est d'être buzzword complient et de faire du push (ce qu'on fait maintenant). En gros, de l'attente passive VS du spinlock...
La morale de l'histoire étant surtout : une gestion intelligente du cache permet un sacré gain de perfs.
D'acc, je comprends mieux ;)
Pour voir le temps de réponse des différentes pages / backends, etc... tu peux activer les logs HTTP dans haproxy. Ca te donne le temps de connexion, le temps de réponse, etc... de chacun des serveurs en fonction de la requête. ensuite, tu utilises halog, dispo dans le répertoire contrib des sources, et ça te compile tout ça tout proprement, en te listant les URLs les plus lentes, les backends les plus lents, etc.... => si une URL est systématiquement plus lentes que les autres peu importe le serveur, alors le code est optimisable. En fonction de la capacité de traitement de tes serveurs d'appli, je te conseillerais de bien tuner con maxconn/fullconn. Il est possible d'améliorer les temps de réponses applicatifs sans rien changer d'autres que ces paramêtres. Si tu ne caches que du statique non-généré par l'application, tu peux utiliser du content switching au niveau du haproxy. Un exemple de conf: http://blog.exceliance.fr/2011/06/17/smart_content_switching_for_news_websit... Au niveau du Varnish, tu as la fonction grace qui est interessante, pour servir un contenu "pas frais" le temps que le serveur délivre le nouvel objet. a+
participants (21)
-
"Vincent Duvernet (Nolmë Informatique) " -
Baptiste -
Damien Wetzel -
David Touitou -
Florian Coulmier -
Francois Romieu -
Gregory Duchatelet -
J. Mardas -
Jean Baptiste Favre -
Jean Spirat -
Marc Fournier -
Mathieu Goessens -
Milamber -
Olivier Bonvalet -
Richard DEMONGEOT -
Rémy Sanchez -
Steven Le Roux -
thomas＠fullbox.org -
vincent finet -
Wallace -
Yacine Kheddache