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
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 write
On Mon, 5 Sep 2011 10:43:06 +0200, "vincent finet"
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 égalemen
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
2011/9/5 vincent finet :
> 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.
>
2011/9/5 vincent finet :
> 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'
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 saura
On Mon, 5 Sep 2011 11:15:02 +0200, "vincent finet"
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
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.fi...@viveris-asr.fr
Tel : 01 55 19 47 47
Mob : 06 88 56 27 73
-Original Message-
From: frsag-boun...@frsag.org on behalf of S
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 co
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,
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 au
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 configurati
'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, l
Le 01/09/2011 17:21, Simon Morvan a écrit :
Le 31/08/2011 16:39, Sebastien PLOT a écrit :
Le 31/08/2011 15:35, Sylvain Rochet a écrit :
Lu,
On Wed, Aug 31, 2011 at 03:24:00PM +0200, "Vincent Duvernet (Nolmë
Informatique)" wrote:
Sinon, il y a aussi la politique de l'autruche. Tu rachètes de
Title: Optimisation architecture Web / Retour d'experience ?
Bonjour,
sur les différends fils, tout le monde ne parle que de software.
Est ce que la piste hardware a été étudiée ?
Est ce que tout est géré par une seule machine virtuelle chez OVH ou
bien y en a-t
Le 5 septembre 2011 13:22, Simon Morvan a écrit :
> Le 01/09/2011 17:21, Simon Morvan a écrit :
> Petit retour pour info, on dirait bien que le passage de "unganged" à
> "ganged" rend le serveur stable.
> Ca me chiffone un peu comme resultat des courses mais bon, visiblement je ne
> suis pas le s
Le 05/09/2011 16:28, Yves Rougy a écrit :
En tous cas merci de nous avoir tenu au courant du diagnostic "final".
J'espère qu'il sera effectivement "final".
Pour etre précis, donc :
- La carte mère est une GA-890GPA-UD3H
- Le CPU est un X4 640
- Les barrettes de ram sont des G.Skill F3-10666CL9S
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
sourc
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'i
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 d
Le 6 sept. 2011 à 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 r
On 06/09/2011 07:09, Yacine Kheddache wrote:
>
> Le 6 sept. 2011 à 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
Le 6 sept. 2011 à 07:26, Mathieu Goessens a écrit :
> On 06/09/2011 07:09, Yacine Kheddache wrote:
>>
>> Le 6 sept. 2011 à 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
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
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 x
26 matches
Mail list logo
