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
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.
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 sym
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.
De mon côté, j'ai sauvé un
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 manuell
> 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 le
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
Bonjour,
Gregory Duchatelet :
[...]
> 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 direct
Wallace a écrit :
>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
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 late
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 pro
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-boun...@frsag.org on behalf of Mathieu Goessens
Sent: Tue 06/09/2011 07:26
To: frsag@frsag.org
Subject: Re: [
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
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 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
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 à 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 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
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
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
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
'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
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
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
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,
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"
wrote:
> Merci pour vos réponses avisées.
Re,
> Je ne sais en fait pas vraiment ou se situe le goulo
lf 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 :
> Merci pour vos réponses avisées.
>
> Je ne sais en fait pas vraiment ou se situe le goulot.
> En l'ét
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
@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 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 fi
> Cdt
>
> 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 Richard DEMONGEOT
> Sent:
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.
>
Group
Subject: Re: [FRsAG] Optimisation architecture Web / Retour d'experience ?
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
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
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
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
35 matches
Mail list logo
