La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine =>
CityPlay =>
Anciens FAI => Opérateurs grand public alternatifs =>
Espace technique CityPlay => Discussion démarrée par: Phena le 21 mars 2014 à 08:41:47
-
Bonjour à tous,
pour me présenter très simplement j'ai un 'lourd' background d'informaticien depuis plus de 30 ans.
J'ai actuellement chez moi les deux opérateurs Free en Adsl-Reach et Cityplay depuis quelques jours... Je trouvais Cityplay plus lent que free malgré un différentiel de bande passante de 100 Mega
(1 chez Free et 100 chez Cityplay)
J'ai lancé depuis mon PC sous linux l'instruction suivante :
ab -n10 -c2 http://www.monsite.fr (http://www.monsite.fr) soit 10 ouvertures de pages avec 2 en simultanées à chaque fois.
Voici les résultats :
Chez CityPlay :
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, [url=http://www.zeustech.net/]http://www.zeustech.net/[/url]
Licensed to The Apache Software Foundation, [url=http://www.apache.org/]http://www.apache.org/[/url]
Benchmarking www......fr (be patient).....done
Server Software: Apache/2.2.22
Server Hostname: www.....fr
Server Port: 80
Document Path: /
Document Length: 61299 bytes
Concurrency Level: 2
Time taken for tests: 26.589 seconds
Complete requests: 10
Failed requests: 0
Write errors: 0
Total transferred: 617980 bytes
HTML transferred: 612990 bytes
Requests per second: 0.38 [#/sec] (mean)
Time per request: 5317.853 [ms] (mean)
Time per request: 2658.927 [ms] (mean, across all concurrent requests)
Transfer rate: 22.70 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 14 18 4.5 17 29
Processing: 5270 5292 10.5 5298 5303
Waiting: 5219 5229 7.2 5230 5238
Total: 5287 5310 12.4 5314 5332
Percentage of the requests served within a certain time (ms)
50% 5314
66% 5315
75% 5315
80% 5315
90% 5332
95% 5332
98% 5332
99% 5332
100% 5332 (longest request)
Le même test depuis le même PC 30 secondes plus tard par Free :
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, [url=http://www.zeustech.net/]http://www.zeustech.net/[/url]
Licensed to The Apache Software Foundation, [url=http://www.apache.org/]http://www.apache.org/[/url]
Benchmarking www.....fr (be patient).....done
Server Software: Apache/2.2.22
Server Hostname: www.....fr
Server Port: 80
Document Path: /
Document Length: 61299 bytes
Concurrency Level: 2
Time taken for tests: 4.353 seconds
Complete requests: 10
Failed requests: 0
Write errors: 0
Total transferred: 617980 bytes
HTML transferred: 612990 bytes
Requests per second: 2.30 [#/sec] (mean)
Time per request: 870.636 [ms] (mean)
Time per request: 435.318 [ms] (mean, across all concurrent requests)
Transfer rate: 138.63 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 35 42 9.6 38 64
Processing: 790 828 36.0 823 887
Waiting: 149 184 35.8 189 238
Total: 831 870 43.9 858 951
Percentage of the requests served within a certain time (ms)
50% 858
66% 891
75% 891
80% 929
90% 951
95% 951
98% 951
99% 951
100% 951 (longest request)
Résultat sans appel :
Chez Cityplay : 5,314 secondes pour charger une page Web
chez Free : 0,858 seconde pour charger la même page Web ...
-
Bienvenue !
L'Apache Bench ne me semble pas pertinent pour évaluer un FAI.
Pour le temps de chargement d'une page les 3 indicateurs de bases à surveiller sont :
- Le ping vers la page destination
- Le débit vers la page destination
- Le temps de résolution DNS
Le ping est l'indicateur le plus important pour une page avec de nombreux petits objets.
Le débit est le plus important pour un téléchargement.
Le DNS peux casser complètement les résultat si il est long a répondre.
Tu à pris pour le test un site hébergé au Japon, j'ai un peu de mal a comprendre pourquoi...
Voici le traceroute depuis Adeli :
$ mtr -rwc100 www.zeustech.net (http://www.zeustech.net)
Start: Fri Mar 21 08:52:07 2014
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- portevlan.adeli.biz 0.0% 100 0.3 2.2 0.2 75.7 8.4
2.|-- he.franceix.net 0.0% 100 6.0 8.6 5.9 17.0 3.5
3.|-- 10ge9-1.core1.par2.he.net 0.0% 100 5.9 9.5 5.8 18.4 4.2
4.|-- 10ge15-1.core1.ash1.he.net 1.0% 100 83.8 87.5 83.8 115.2 5.1
5.|-- 100ge7-1.core1.nyc4.he.net 5.0% 100 88.9 91.5 88.9 99.4 3.5
6.|-- 10ge10-3.core1.lax1.he.net 0.0% 100 160.1 153.1 149.8 162.2 4.0
7.|-- pacnet.10gigabitethernet2-3.core1.lax1.he.net 0.0% 100 158.0 158.0 157.9 158.7 0.0
8.|-- gi12-0-0.cr2.nrt1.asianetcom.net 0.0% 100 251.9 251.9 251.8 252.6 0.0
9.|-- ge-2-1-0-0.gw3.nrt5.asianetcom.net 0.0% 100 252.4 252.6 252.0 260.8 1.5
10.|-- GMO-0003.gw3.nrt5.asianetcom.net 0.0% 100 252.2 252.2 252.1 252.5 0.0
11.|-- b-4ea-b13-1-e-0-3-0-1.interq.or.jp 0.0% 100 259.1 259.3 258.9 265.3 0.6
12.|-- g-o-4eb-a13-1-e-1-4.interq.or.jp 0.0% 100 257.4 257.4 257.3 258.7 0.1
13.|-- g-o-p-4ee-a01-1-e-1-1.interq.or.jp 0.0% 100 269.2 269.2 269.1 269.4 0.0
14.|-- unused-211-125-069-182.interq.or.jp 0.0% 100 266.9 267.0 266.9 267.3 0.0
15.|-- 180.222.177.117 0.0% 100 271.4 270.5 267.3 300.8 6.4
16.|-- ? ? 100.0 100
Free est généralement mauvais pour ce type de destination qui passe par les transit mais certaines plages IP ont le droit a un transitaire non saturé, donc impossible de généraliser
=> 3ème transitaire pour Free: Level3 rejoint Tata et Cogent (https://lafibre.info/transit-ip/3eme-transitaire-pour-free-level3-rejoint-tata-et-cogent/)
Il faudrait faire un traceroute depuis tes deux accès pour voir si le ping est proche ou si il y a un problème de routage.
Tu peux aussi vérifier si tu as le débit max vers un lot de destination qui hébergent des gros fichiers ici : https://testdebit.info/ (https://testdebit.info/)
-
Zeustech c'est pas la boîte qui gère ApacheBench ?
Un peu dommage que Phena ne nous donne pas l'url testé...
-
Bonjour Vivien,
merci pour ton retour
zeustech est le développeur de ab,
j'ai testé sur un des quatre serveurs m'appartenant (je possède plusieurs sites marchands), j'ai masqué l'url cible Benchmarking www......fr
Le serveur cible que j'ai optimisé utilise un cache apc, un cache tmpfs, et j'étais connecté également en telnet pour mesurer la charge du serveur pendant ce temps.
En fait quand je lance une requête URL sur un des mes serveurs, je retrouve le 'hit' environ 4-5 seconds après dans mes fichiers log apache (tail -f /var/log/apache/access.log | grep monadresse ip)
Chez free, c'est instantané (quelques ms) alors que chez Cityplay on est à 4-5 secondes ...
Je serais d'accord avec toi sur le ping mais j'ai l'impression qu'il y a une QOS ip/port qui me pénalise, notamment sur 1 de mes 4 serveurs pour tout dire, je n'ai pas un tel écart vers les autres serveurs.
Mes serveurs sont dans 3 datacenters différents en idf.
Le débit est bon sauf que le premier octet (le TTFB) est excessivement lent... Je continue mes investigations ...
-
Je peux vous donner l'url testé par MP ?
-
Pour bien comprendre, ces 5s de TTFB tu ne le retrouve que vers ce serveur ? Ailleurs ça fonctionne "correctement" ?
Que donnent des traceroute dans un sens et dans l'autre, avec Free et Cityplay ?
Je peux vous donner l'url testé par MP ?
Hésite pas à l'envoyer à vivien, il a de quoi faire des tests depuis quelques FAIs :)
-
Avec l'url que tu m'as envoyé, on peut voir que le serveur en question est chez Online. Ça explique le bon résultat de Free, il faudrait voir la route Cityplay<>Online (dans les deux sens) pour comprendre le mauvais résultat. Tu peux faire des traceroute depuis chez toi et depuis ton serveur pour commencer ?
-
Le speedtest qui est par défaut sur https://testdebit.info (https://testdebit.info) est chez Online.
Tu pourrais nous faire le test et nous montrer le résultat depuis Free et depuis CityPlay ?
Online ne peer pas beaucoup, mais il a correctement dimensionné ses transitaire.
Voici les liens utilisé par Online :
- 70Gb/s Transit vers Telia
- 70 Gb/s Transit vers Tata
- 60 Gb/s Transit vers Level3
- 60 Gb/s PNI vers Hopus (pour joindre Orange, Bouygues Telecom et SFR bientôt)
- 80 Gb/s PNI vers Free
- 10 Gb/s PNI vers Jaguar Network
- 10 Gb/s PNI vers Ielo
Donc on doit passer par le transitaire de CityPlay.
Si c'est correctement dimensionné, le ping et les débits devraient être bons.
-
J'ai fait plusieurs tracert sur différents serveurs
1 2 ms 2 ms 1 ms myhome.home [192.168.1.1]
2 17 ms 4 ms 4 ms 213.151.160.6
3 7 ms 19 ms 20 ms 213.151.160.233
4 12 ms 11 ms 11 ms ae5-240.par70.ip4.tinet.net [77.67.65.1]
5 16 ms 12 ms 14 ms be3257.rcr21.par05.atlas.cogentco.com [130.117.15.105]
6 14 ms 14 ms 12 ms be2427.mpd22.par01.atlas.cogentco.com [130.117.49.165]
7 13 ms 15 ms 20 ms be2041.mag21.par01.atlas.cogentco.com [154.54.78.42]
8 14 ms 15 ms 17 ms 149.6.115.18
9 13 ms 13 ms 14 ms bzn-crs16-1-be1106.intf.routers.proxad.net [212.27.59.101]
10 14 ms 32 ms 19 ms dedibox-2-t.intf.routers.proxad.net [212.27.58.50]
11 14 ms 16 ms 14 ms a9k1-1012.dc3.poneytelecom.eu [88.191.1.131]
12 14 ms 17 ms 21 ms 45-s103-1-1062.dc2.poneytelecom.eu [88.191.1.114]
13 mon serveur 1
Vitesse OK
1 2 ms 1 ms 1 ms myhome.home [192.168.1.1]
2 7 ms 3 ms 5 ms 213.151.160.6
3 20 ms 9 ms 14 ms 213.151.160.233
4 11 ms 11 ms 11 ms ae5-240.par70.ip4.tinet.net [77.67.65.1]
5 13 ms 14 ms 13 ms be3257.rcr21.par05.atlas.cogentco.com [130.117.15.105]
6 14 ms 13 ms 13 ms be2427.mpd22.par01.atlas.cogentco.com [130.117.49.165]
7 13 ms 13 ms 12 ms be2041.mag21.par01.atlas.cogentco.com [154.54.78.42]
8 14 ms 17 ms 15 ms alionis.demarc.cogentco.com [149.6.160.86] // 7 et 9 identique
9 107 ms 12 ms 13 ms bzn-crs16-1-be1106.intf.routers.proxad.net [212.27.59.101]
10 30 ms 81 ms 64 ms dedibox-2-t.intf.routers.proxad.net [212.27.58.50]
11 59 ms 13 ms 13 ms a9k1-1012.dc3.poneytelecom.eu [88.191.1.131]
12 27 ms 13 ms 14 ms 45x-s44-1-1039.dc3.poneytelecom.eu [88.191.1.178]
13 mon serveur 2
Vitesse NOK
les hop 7 et 9 étant les mêmes on doit avoir un load-balancing sur le hop 8 149.6.* ?
Une fois que la route est dans le cache du serveur qui pétouille ... C'est planté ?
-
Si c'est toi qui gère ces serveurs, je t'invite à faire un changement d'IP.
Ce sont les veilles plages IP de Online, avant que Online ait son propre réseau.
Les performances sont mauvaises car il utilise le réseau de Free qui sature ses transitaires => Les performances sont proches de celle de Youtube depuis un accès Free.
Il me semble que Online a donné à tous ceux qui avaient ce type d'IP de nouvelles IP pour leur permettre de faire la transition en douceur.
-
pour les ip oui, migration obligatoire au plus tard le 15/9
-
Aprés le changement d'IP, tu verras que CityPlay sera beaucoup plus performant que Free.
-
Aprés le changement d'IP, tu verras que CityPlay sera beaucoup plus performant que Free.
J'ai fait la bascule sur les nouvelles IP Online, c'est pas mieux ...
j'ai toujours le Get qui arrive en 4-5 secondes ... J'ai sorti WireShark pour voir où ca coince
|Time | Mon PC || | | Mon Serveur |
|0.000000000| 55777 > http [SYN] |TCP: 55777 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1|
|0.029476000| http > 55777 [SYN, |TCP: http > 55777 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=128|
|0.029552000| 55777 > http [ACK] |TCP: 55777 > http [ACK] Seq=1 Ack=1 Win=16384 Len=0|
|0.029687000| GET /a-personnalise |HTTP: GET / HTTP/1.1 |
|0.165801000| http > 55777 [ACK] |TCP: http > 55777 [ACK] Seq=1 Ack=811 Win=16256 Len=0|
|5.318868000| [TCP segment of a r |TCP: [TCP segment of a reassembled PDU]|
|5.321163000| [TCP segment of a r |TCP: [TCP segment of a reassembled PDU]|
|5.321214000| 55777 > http [ACK] |TCP: 55777 > http [ACK] Seq=811 Ack=2921 Win=16384 Len=0|
|5.321278000| [TCP segment of a r |TCP: [TCP segment of a reassembled PDU]|
|5.321289000| [TCP segment of a r |TCP: [TCP segment of a reassembled PDU]|
Les trames SYN et ACK sont bien en timing avec un deltaT de 29 ms et après le Get / on a le ACK à 165 ms et le flow TCP arrive à 5,31 sec, on pourrait croire à une lenteur d'apache mais si je rebascule
chez free le flow TCP arrive à 0,8 sec , là je ne vois pas trop la raison, on dirait un timeout de 5 sec qui se libère ...
Une idée ? un cache ARP ou un truc du genre ?
-
Tu observes la même chose sur d'autres serveurs online ?
-
Un timeout de 5 secondes ? Cela pourrait être une résolution inverse DNS dans Apache qui échoue.
-
Bonne piste : Les IP cityplay n'ont pas de résolution DNS inverse.
CityPlay n'est pas le seul FAI a ne pas avoir de reverse-dns (par exemple Bouygues Telecom mobile)
-
Tu observes la même chose sur d'autres serveurs online ?
J'ai croisé un autre serveur qui avait aussi ce genre de problème mais je ne l'ai pas mémorisé...
sur mon serveur à problème qui est le seul en Ubuntu 12.04, les autres sont en 10, j'avais rajouté (mais je ne sais plus pourquoi)
dans /etc/network/interfaces
dns-nameservers 127.0.0.1 88.191.254.60 88.191.254.70
je viens de commenter cette ligne pour voir ...
-
Bonne piste : Les IP cityplay n'ont pas de résolution DNS inverse.
CityPlay n'est pas le seul FAI a ne pas avoir de reverse-dns (par exemple Bouygues Telecom mobile)
je viens de metttre l'ip cityplay dans le /etc/hosts de mon serveur est en effet je n'ai plus de délai
de latence, c'est bien cela, Merci ;) je n'ai plus qu'à trouver comment paramètrer ce reverse au niveau de d'apache
-
Le paramètre est HostnameLookups (https://httpd.apache.org/docs/2.2/mod/core.html#hostnamelookups).
The default is Off in order to save the network traffic for those sites that don't truly need the reverse lookups done. It is also better for the end users because they don't have to suffer the extra latency that a lookup entails. Heavily loaded sites should leave this directive Off, since DNS lookups can take considerable amounts of time. The utility logresolve, compiled by default to the bin subdirectory of your installation directory, can be used to look up host names from logged IP addresses offline.
-
Le paramètre est HostnameLookups (https://httpd.apache.org/docs/2.2/mod/core.html#hostnamelookups).
Oui c'est un des 4 paramètres qui fait faire un reverse DNS au serveur :
- hostnamelookups Off dans apache.conf
- pas de %h dans le log combined d'apache => à remplacer par un %a
- Pas de de Allow/Deny dans les .htaccess sur des hostnames
- Le module Status d'apache à désactiver
J'ai fait ces 4 modifs et malgré tout j'ai toujours un reverse DNS de 5 sec ...
Je continue mes recherches ...
-
4/ Le module Status d'apache à désactiver
Il n'est pas nécessaire de désactiver Le module status d'apache.
Au pire, c'est juste une requête DNS si tu affiches la page (je ne suis même pas sur)
-
Sur le même serveur, j'ai des sites en Oxwall ( http://www.oxwall.org/ (http://www.oxwall.org/) ) ceux là répondent bien sans time out
et d'autres en Magento et là j'ai le time-out du reverse dns : quand j'ajoute l'ip client dans le /etc/hosts du serveur le time out disparaît ...
J'en suis à conclure que j'ai fait toutes les optim coté apache mais que je dois avoir des modules coté magento qui font des reverse dns ...