Re: [FRsAG] Apero parisien

2013-07-23 Par sujet Greg
Bonjour, un simple Doodle + discussion offlist me parait plus judicieux pour ce type d'évènement, la ML est quelque peu poluée ces derniers temps ! Merci, Le 22 juillet 2013 21:13, Jonathan bartoua Schneider a écrit : > Présent. Mais pas à l'heure (faut pas changer les habitudes) > >

[FRsAG] Incidence des TCP Timestamps sur les connexions

2013-07-23 Par sujet Greg
Bonjour, je rencontre un problème d'établissement de connexions TCP sur un serveur par forte charge, qui se concrétise par des timeouts de connexion. Ce serveur établit de nombreuses connexions : - serveur web NGiNX - fichiers statiques sur NFSv4 (4 connexions TCP) - reverse-proxy sur une 20ène de

Re: [FRsAG] Apero parisien

2013-07-23 Par sujet Christophe Gasmi
avec plaisir. Le 21 juillet 2013 23:26, Sébastien FOUTREL a écrit : > Hello tous. > Avec cette chaleur je boirais bien une biere un soir. > Des amateurs ? > > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > > __

[FRsAG] Apero parisien

2013-07-23 Par sujet Sébastien FOUTREL
Hello tous. Avec cette chaleur je boirais bien une biere un soir. Des amateurs ? ___ Liste de diffusion du FRsAG http://www.frsag.org/

Re: [FRsAG] Apéro de Lyon - Juillet

2013-07-23 Par sujet cam.la...@azerttyu.net
Ciao a tutti Alors comme promis la date est figée. Ce sera donc mercredi 24 à partir de 19h30. Le point de chute est : Le tono 17 rue Claudia 69002 Lyon (Métro Cordelier) N'hésitez pas à me bipper par mail pour échange de numéro de tel. Comme j'ai déjà eu la remarque sur la possibilité en

Re: [FRsAG] optim page load à l'autre bout du monde

2013-07-23 Par sujet Greg
Merci pour vos réponses. Pour le contenu statique il existe plein de solutions, ce qui m'intéresse c'est le contenu dynamique. Donc je résume : - CDN applicatif ou serveur reverse-proxy type NGiNX avec keepalive, pour gagner sur le nombre d'établissement de connexions - découper le contenu sur plu

Re: [FRsAG] optim page load à l'autre bout du monde

2013-07-23 Par sujet neo futur
avoir un _vrai_ cdn, qui a reellement des ips un peu partout. appengine assure ca comme un dieu : http://www.just-ping.com/index.php?vh=static.ww7.be&c=&s=ping! ( voir le nombre d ips differentes selon la source ) pour ca quelques lignes de python suffisent : https://github.com/neofutur/myCDN/ e

Re: [FRsAG] optim page load à l'autre bout du monde

2013-07-23 Par sujet Valentin Beck
Bonjour, On Jul 23, 2013, at 8:49 PM, Thomas Pedoussaut wrote: > C'est donc dans la conception du site que tu dois travailler: > […] > - utiliser de l'aliasing massif des serveurs (img.foo.com, css.foo.com, > js.foo.com, app.foo.com) pour que le navigateur ouvre plusieurs sessions > simultanées

[FRsAG] optim page load à l'autre bout du monde

2013-07-23 Par sujet Damien Wetzel
Salut Greg, Comme l'a dit Antoine les CDNs proposent maintenant ce qu'ils appellent application delivery. Le concept est d'avoir non plus un proxy entre l'internaute et l'origine, mais deux. Ayant la maitrise sur les deux bouts ils peuvent faire de la cuisine sur le stack tcp/ip pour limiter les

Re: [FRsAG] optim page load à l'autre bout du monde

2013-07-23 Par sujet Benjamin BILLON
Les fournisseurs de CDN proposent souvent des solutions pour ça. Il ne s'agit plus de cache a proprement parlé mais d'accélération (ou de déport des scripts, mais c'est une autre histoire). Par exemple, pour tout ce qui ne peut pas être mis en cache, le fournisseur ouvre des connexions persistantes

Re: [FRsAG] optim page load à l'autre bout du monde

2013-07-23 Par sujet Thomas Pedoussaut
On 2013-07-23 15:31, Greg wrote: > comment améliorer le temps d'affichage d'une page web dynamique (PHP) > à l'autre bout du monde ? (Sans délocalisation de serveurs) > > Les CDNs permettent d'améliorer le temps d'affichage des documents > statiques. > Délocaliser des serveurs peut couter cher dans

Re: [FRsAG] optim page load à l'autre bout du monde

2013-07-23 Par sujet Antoine Drochon
Salut, Les CDN des années 2000 faisaient que du cache, tu as raison. Entre temps, il y a quelques évolutions et tu peux accélérer des contenus dynamiques. Le facteur d'accélération dépend directement de la manière dont est conçue l'appli et où sont les utilisateurs mais généralement plus ils son

[FRsAG] optim page load à l'autre bout du monde

2013-07-23 Par sujet Greg
Bonjour, comment améliorer le temps d'affichage d'une page web dynamique (PHP) à l'autre bout du monde ? (Sans délocalisation de serveurs) Les CDNs permettent d'améliorer le temps d'affichage des documents statiques. Délocaliser des serveurs peut couter cher dans certain pays, et puis dans ce cas

Re: [FRsAG] Apero parisien

2013-07-23 Par sujet Mathieu Arnold
+--On 23 juillet 2013 08:51:25 +0200 Greg wrote: | Bonjour, | | un simple Doodle + discussion offlist me parait plus judicieux pour ce | type d'évènement, la ML est quelque peu poluée ces derniers temps ! Bah, au moins, il s'y passe quelquechose :-) Il suffit de dire "apéro vendredi 26 juille

Re: [FRsAG] Incidence des TCP Timestamps sur les connexions

2013-07-23 Par sujet Greg
Merci Vincent pour ces explications et recommandations, que j'ai prise en compte. Néanmoins je me demande toujours pourquoi désactiver les TCP timestamps a un tel impact sur l'établissement des connexions TCP. Damien> je suis en contact aussi avec eux, mais comme tout CDN ils ne peuvent rien fair

Re: [FRsAG] Apéro de Lyon - Juillet

2013-07-23 Par sujet cam.la...@azerttyu.net
Ciao Suffit de demander :) La votation c'est par là : http://framadate.org/studs.php?sondage=xaies5mfbhbix3ca Km ___ Liste de diffusion du FRsAG http://www.frsag.org/

Re: [FRsAG] Incidence des TCP Timestamps sur les connexions

2013-07-23 Par sujet Stephane . DIENY
jolie réponse et merci d'avoir partagé avec le reste de la liste ! :) /s frsag-boun...@frsag.org wrote on 23/07/2013 10:05:39: > From: Vincent Bernat > To: Greg > Cc: French SysAdmin Group > Date: 23/07/2013 10:05 > Subject: Re: [FRsAG] Incidence des TCP Timestamps sur les connexions > Sen

Re: [FRsAG] Incidence des TCP Timestamps sur les connexions

2013-07-23 Par sujet Vincent Bernat
❦ 23 juillet 2013 09:29 CEST, Greg  : > net.ipv4.tcp_tw_recycle=1 > net.ipv4.tcp_tw_reuse=1 tcp_tw_recycle est très dangereux et peut causer divers problèmes difficiles à diagnostiquer, notamment une impossibilité pour certains clients d'établir la connexion. > A ce moment commence les recherch