Beste OVH,
De levering van "17 PoP GeoCache CDN" is al een puzzel op zich is, de ene keer kan het wel en de andere keer kan het zogenaamd dus niet enkel aan een webhostingpakket gekoppeld worden. Desondanks werd 2013-12-20 20:28:00 perso2014 besteld inclusief de "17 PoP GeoCache CDN" optie.
Configuratie CDN informatie ontbreekt
Het bevestigingsemail bericht met de titel "[OVH-perso2014]
geinstalleerd" bevat vervolgens geen enkele mededeling over hoe de gefactureerde "Website CDN - 17 POPs" te gebruiken is.
Derhalve heb ik OVH via reeds op 21 december 2013 13:22 per e-mail met als onderwerp "In gebreke stelling: informatievoorziening is ontoereikend om perso2014 met 17 PoP GeoCache in gebruik te stellen" in gebreke gesteld:
Via de suggestie “De handleiding” op adres wordt mij eveneens geen informatie verstrekt hoe de 17 PoP GeoCache te activeren. "Hoe uw shared webhosting configureren via de Manager van OVH?” verwijst naar “http://gids.ovh.nl/ManagerDienstHosting” wat weer een sjabloonpagina zonder inhoud is, zie bijlage "ManagerDienstHosting_27.03.2009.17:11.pdf”, idem dito voor "Samenvatting van de gids over het gp plan” , "Hoe mijn domein doen merken op een plan/pack/gp ?”
Ook de franstalige gidsen op brengen mij geen uitleg over de optionele dienst "17 PoP GeoCache”.
Gelieve de ontvangst van deze e-mail te bevestigen en binnen 7 werkdagen (dat wil zeggen uiterlijk vrijdag 3 februari 2014) volledige instructies te verstrekken over hoe GeoCDN 17 PoP’s (1) te activeren, (2) in te stellen, (3) te controleren dat het correct functioneert en dienovereenkomstig de looptijd van mijn overeenkomst te verlengen.
Op deze in gebreke stelling wordt vervolgens in zijn geheel niet gereageerd door OVH, wel op issues inzake FTP, Nederlandse vertalingen, en het ontbreken van de Last-Modified header.
Na lang zoeken op internet blijk ik uiteindelijk met wat gokken het juiste IP-adres voor de 17 PoP Business CDN op cluster13 te kunnen achterhalen: 213.186.33.83. Inmiddels - het is nu oktober 2014 - is er een handleiding op die uitsluitend vanuit de CDN FAQ gelinkt wordt onder de kop "Hoe kan men de GeoCache Accelerator beheren (inbegrepen bij de nieuwe Web Hosting)?", en die CDN FAQ lijkt op zijn beurt weer helemaal niet gelinkt vanuit enige andere webpagina.
Slechts 11 van 17 CDN PoP's geleverd
Bij het lokaal testen viel mij op dat de pagina’s steeds uit Geo cache PoP “par” (Parijs) geserveerd werden.
Bij het vervolgens wereldwijd testen van de 17 PoP GeoCache bij perso2014 hosting, merk ik dat de navolgende PoP’s gebruikt worden:
X-CDN-Geo: atl (Atlanta, Georgia)
X-CDN-Geo: chi (Chicago, Illinois)
X-CDN-Geo: dal (Dallas, Texas)
X-CDN-Geo: fra (Frankfurt, Germany)
X-CDN-Geo: lag (Los Angeles)
X-CDN-Geo: mad (Madrid, Spain)
X-CDN-Geo: mil (Milaan, Italy)
X-CDN-Geo: nwk (Newark, New Jersey)
X-CDN-Geo: par (Paris, France)
X-CDN-Geo: sea (Seattle, Washington)
X-CDN-Geo: tor (Toronto, Canada)
Vanaf de navolgende locaties wordt overduidelijk geen meest nabije PoP gekozen:
1. Manchester, UK
DNS Server(s): 208.67.222.222,208.67.220.220 (resolver1.opendns.com)
X-CDN-Geo: fra
X-CDN-Geo-IP: 46.105.196.37
2. Dublin, Ireland
DNS Server(s): 172.16.0.23 (?)
X-CDN-Geo: par
X-CDN-Geo-IP: 46.105.197.5
3. Saint Petersburg, Russia
DNS Server(s): 8.8.8.8 (google-public-dns-a.google.com)
X-CDN-Geo: par
X-CDN-Geo-IP: 46.105.197.5
4. Moscow, Russia
DNS Server(s): 188.120.247.2 (wdc-ns1.ispsystem.net)
X-CDN-Geo: par
X-CDN-Geo-IP: 46.105.197.5
5. Vianen, Netherlands
DNS Server(s): 212.54.40.25,212.54.35.25 (dns.tb.iss.as9143.net = ziggo.nl)
X-CDN-Geo: par
X-CDN-Geo-IP: 46.105.197.5
6. Amsterdam, Netherlands (Go Daddy)
DNS Server(s): 188.121.38.46,188.121.38.47 (ip-188-121-38-46.ip.secureserver.net)
X-CDN-Geo: par
X-CDN-Geo-IP: 46.105.197.5
7. Amsterdam, Netherlands
DNS Server(s): 8.8.4.4,208.67.220.220 (google-public-dns-b.google.com)
X-CDN-Geo: par
X-CDN-Geo-IP: 46.105.197.5
8. London, UK
DNS Server(s): 84.45.112.20 (recursor1.c4l.co.uk)
X-CDN-Geo: par
X-CDN-Geo-IP: 46.105.197.5
9. Amsterdam, NL - IISpeed
DNS Server(s): 194.60.207.52 (rdns-01.svc.xl-is.net)
X-CDN-Geo: par
X-CDN-Geo-IP: 46.105.197.5
10. Moscow, Russia
DNS Server(s): 8.8.8.8
X-CDN-Geo: par
X-CDN-Geo-IP: 46.105.197.5
De navolgende Europese PoP’s lijken zelfs helemaal nooit gekozen te worden (down?):
1. Amsterdam
2. London
3. Warschau
Dit werd op 22 december 2013 21:37 aan support@ovh.nl gemeld met als onderwerp "Wanneer gaan de GeoCache PoP's ams, lon, war voor full-cdn-01.cluster013.ovh.net functioneren?"
30 December 2013 20:50u is de Last-Modified header gefixt voor text/html die geserveerd wordt via het OVH CDN. Dit wordt aan support@ovh.nl gemaild met als onderwerp "Fwd: Perso2014: Web hosting: Apache: Content-Type text/html: please don't unset Last-Modified header". Tevens is toen gemeld dat deze punten nog open staan:
1. beschikbaarheid ams/lon/war/asia CDN locations,
2. documentatie instellen CDN bij perso2014,
3. ontvangstbevestiging in gebreke stelling,
4. combinatie Geo-lokalisatie & CDN (anycast IP adres in andere landen dan Frankrijk)
Via ticket#1595515 werd het niet beschikbaar zijn van de CDN locaties nog herhaald op 4 januari 2013 02:37:
Currently the London, Amsterdam and Warschau CDN locations seem to be unavailable.
When will the London, Amsterdam and Warschau CDN locations be operational?
Daarnaast is via ticket#1600500 op 11 januari 2014 om 03:15 een nieuw CDN issue gemeld met als onderwerp "with CDN is slower than without":
Using the OVH CDN serves pages from static html websites slower than without using the OVH CDN
I want a speed improvement, instead of a speed reduction.
With CDN:
First byte: 0.177s
Start render: 0.844s
Load time: 1.025s
Fully loaded: 1.336s
Without CDN:
First byte: 0.159s (10% faster)
Start render: 0.674s (20% faster)
Load time: 0.856s (16% faster)
Fully loaded: 1.144s (14% faster)
In gebreke stelling #3
Vervolgens wordt op 15 januari 2014 om 13:43 in gebreke stelling #3 verzonden aan support@ovh.nl met als onderwerp "In gebreke stelling #3, wegens niet leveren 17 PoP CDN bij Perso hosting [FACTUUR NL39485]".
De 17 PoP CDN functioneert bijna 1 maand na bestelling nog altijd niet naar behoren: minimaal de Amsterdam, London en Warschau Pop’s zijn niet actief voor probackup.nl. Waarmee de dienst tot maximaal een 14 PoP CDN gereduceerd wordt. Er worden ook geen andere alternatieve PoP locaties in Nederland, de UK of Polen aangeboden.
Hiermee stel ik dat er niet geleverd wordt wat er overeengekomen wordt, ook wordt geen vergelijkbaar alternatief aangeboden of een termijn opgegeven waarbinnen wel geleverd gaat worden.
Gelieve daarom het onderdeel “17 PoP” van factuur NL39485 te laten vervallen, te crediteren en het desbetreffende bedrag terug te storten op de gebruikte credit card.
Op 2014-01-15 13:54:19 werd door mij nog aan ticket#1600500 toegevoegd:
The 17 PoP offer doesn't contain 17 PoP's:
1. at least 3 are not active: London,
Amsterdam, Warschau.
2. OVH makes false claims:
nl: "zal het CDN, naast andere voordelen, het laden van uw site versnellen"
en: "the CDN will not only speed up your website loading times"
As our numerous measurements show, the load times are not faster but slower when using OVH CDN. Only one exception
is the North American region. But when measuring from Paris, Amsterdam, Vianen, London, Manchester, Dublin,
Stockholm, Hong Kong using pingdom, webpagetest.org and gtmetrix.com the page load times are longer when using OVH
CDN. And I have even excluded the current issues issue FS#6108 where page load times are not in the 1 second, but in the 15 second range.
Op 18 januari 2014 om 01:47 volgt een antwoord op ticket#1600500:
We are now noticing latencies between the CDN
and shared hosting. An incident is now processing
for this issue:
http://status.ovh.net/?do=details&id=6108
Meanwhile, you could point your domain directly
to the IP address of the cluster.
Regards,
Aurélien L.
En om 21 januari 2014 om 01:35 volgt nog een herhaling:
Dit incident #6108 meldt:
We're experiencing very slow responses from web hosting (2014) for some domains on the CDN GeoCache which may lead to 50x and Proxy errors. Mitigating the issue.
The timeout for slow request between CDN and mutu is currently 60secs.
Na nogmaals bellen en het opnieuw doorzenden van in gebreke stelling #3 op 30 september 2014 om 18:52 wordt vervolgens op 4 oktober 2014 01:39 door support@ovh.nl geschreven:
I'm afraid this is not possible as it is against our policy to refund VPS services.
Regards,
Tom
OVH.nl Support Team
Geen 7 maar 4 CDN PoP in Europa?
Volgens www.ovh.nl/shared-hosting/geocache.xml zijn er 7 PoP's in Europa: Amsterdam (Nederland), Frankfurt (Duitsland), Londen (Engeland), Madrid (Spanje), Milaan (Italië), Parijs (Frankrijk), Warschau (Polen).
Gecontroleerd op zaterdag 4 oktober 2014:
1. Dublin, Ierland: X-Geo: varn39.rbx5
2. Londen, UK: X-Geo: varn08.rbx5
3. Paris, FR: geen CDN voor IE8
4. Amsterdam, NL: X-Geo: varn18.rbx5
5. Falkenstein, Germany: geen CDN voor Firefox 31.0
6. Stockholm, Sweden: geen CDN voor Safari
7. Sint Petersburg, Rusland: X-Geo: varn36.rbx5
Zelfs als gebruik wordt gemaakt van de door OVH aanbevolen name servers ns107.ovh.net en dns107.ovh.net is er geen verandering:
1. Dublin, Ierland: X-Geo: varn39.rbx5
2. Londen, UK: X-Geo: varn08.rbx5
Ik zie slechts 4 unieke X-Geo cache voorbij komen: varn39, varn08, varn18 en varn36.
European OVH CDN speed
En nu de "Cable" snelheidsverschillen met en zonder CDN van de gemiddelde waarde bij 9 runs voor "Document Complete":
1. Dublin, Ierland - IE9: X-Geo: varn14.rbx5
Test Machine DNS Server(s): 172.16.0.23 = ? = internal IP
met CDN: 0.542s = 0.214s sneller
zonder CDN: 0.756s
2. London, UK - Chrome: X-Geo: varn12.rbx5
Test Machine DNS Server(s): 84.45.112.20 = recursor1.c4l.co.uk
met CDN: 1.345s = 0.106s langzamer
zonder CDN: 1.239s
3. Amsterdam, NL - Go Daddy - IE10: X-Geo: varn20.rbx5
Test Machine DNS Server(s): 188.121.38.46,188.121.38.47 = ip-188-121-38-46.ip.secureserver.net,ip-188-121-38-47.ip.secureserver.net
met CDN: 0.529s = 0.009s langzamer
zonder CDN: 0.520s
4. Vianen, NL - Firefox: X-Geo: varn06.rbx5
Test Machine DNS Server(s): 212.54.44.54,212.54.40.25 = dns.mnd.iss.as9143.net,dns.tb.iss.as9143.net = Ziggo
met CDN: 0.860s = 0.013s langzamer
zonder CDN: 0.847s
5. Geneva, Switzerland - IE8: geen X-Geo response header
Test Machine DNS Server(s): 195.70.10.100,195.70.1.100 = 100.10.70.195.rev.dfinet.net,ns.dfi.innet.ch
met CDN: 1.233s = 0.047s sneller
zonder CDN: 1.280s
6. Falkenstein, Germany - IE9: geen X-Geo response header
Test Machine DNS Server(s): 213.133.98.98,213.133.99.99,213.133.100.100 = ns1-coloc.hetzner.de,ns2-coloc.hetzner.de,ns3-coloc.hetzner.de
met CDN: 0.709s = 0.051s sneller
zonder CDN: 0.760s
7. Stockholm, Sweden - Safari: geen X-Geo response header
Test Machine DNS Server(s): 127.0.0.1 = ? = internal IP
met CDN: 1.286s = 0.013s sneller
zonder CDN: 1.273s
8. Petach-Tikva, Israel - Chrome: geen X-Geo response header
Test Machine DNS Server(s): 10.0.0.138 = ? = internal IP
met CDN: 2.107s = 0.060s langzamer
zonder CDN: 2.047s
9. Moscow, Russia - IE 9: geen X-Geo response header
Test Machine DNS Server(s): 188.120.247.2 = wdc-ns1.ispsystem.net
met CDN: 1.064s = 0.046s sneller
zonder CDN: 1.110s
10. Saint Petersburg, Russia - Chrome: X-Geo: varn05.rbx5
Test Machine DNS Server(s): 8.8.8.8 = google-public-dns-a.google.com
met CDN: 2.850s = 0.168s sneller
zonder CDN: 3.018s
Wereldwijde OVH CDN page load time
Voor deze metingen wordt gebruik gemaakt van gtmetrix.com, zij meten met een antieke Firefox 25.0.1 browser. Die per regio ook nog eens een duidelijk verschillend aantal requests en daarmee verschillend aantal hoeveelheid gegevens (kilobytes) download.
Zonder CDN:
Vancouver, Canada: 1.46s
London, UK: 0.26s
Hong Kong, China: 3.17s
Dallas, USA: 1.08s
Mumbai, India: 1.41s
Sydney, Australia: 2.73s
São Paulo, Brazil: 2.41s
Met CDN:
Vancouver, Canada: 1.55s = 0.09s slower
London, UK: 0.26s = no difference
Hong Kong, China: 3.34s = 0.17s slower
Dallas, USA: 1.15s = 0.06s slower
Mumbai, India: 1.31s = 0.11s faster
Sydney, Australia: 2.99s = 0.26s slower
São Paulo, Brazil: 2.39s = 0.02s faster
In totaal zou ik zeggen dat met "OVH Website CDN 17 PoP's" de delivery wereldwijd in totaal 0,45s langzamer is, en gemiddeld 0,0643s langzamer.
Wordt vervolgd...