+holbi Posted January 13, 2015 Share Posted January 13, 2015 Hi! Veterans on gc.com might remember what a friend of mine has called "hourglass Sunday" on the gc website, when trying to compose logs on Sunday evenings was a real patience game. These times seemed to be over for quite a time now, but in the last weeks I've got the feeling that it's Sunday every day . At first I've blamed the holidays for it, but now we have middle of January and it is still a pain to use the website on evenings (GMT). Listings take minutes to load, or even don't load at all in a finite timeframe. I've checked back with several friends, tried different browsers or went over LTE, the result has always been the same. The servers seem to have severe performance issues and I wonder what the reason is. Is this a known (temporary) problem being worked on, or do I have to log my caches in lunch break from now on? holbi ps: The forum is very slow, too Quote Link to comment
+Marmotte Posted January 13, 2015 Share Posted January 13, 2015 Hi, here also, response times are incredible slow! Calling www.geocaching.com takes 60sec's until sandglass disappears. In other words, it is currently more or less unusable. Location is Hamburg/Germany; ISP: Hansenet; O2; telefoncica; Alice. (sorry, this company changes it's name every few years) For the network guys, probably this traceroute may help Routenverfolgung zu geocaching.com [63.251.163.200] ber maximal 30 Abschnitte: 1 1 ms <1 ms <1 ms alice.box [192.168.1.1] 2 27 ms 28 ms 28 ms 62.52.200.146 3 27 ms 28 ms 28 ms bundle-ether5.0001.dbrx.01.ham.de.net.telefonica.de [62.53.10.230] 4 27 ms 27 ms 27 ms et-1-0-0-0.0001.corx.01.ham.de.net.telefonica.de [62.53.0.36] 5 26 ms 28 ms 28 ms et-0-0-0-0.02.xd.0176-03.ham.de.net.telefonica.de [62.53.0.43] 6 27 ms 28 ms 27 ms ae1-0.0001.prrx.02.ham.de.net.telefonica.de [62.53.8.41] 7 35 ms 34 ms 34 ms ae0-0-grtdusix1.red.telefonica-wholesale.net [84.16.7.233] 8 58 ms 43 ms 44 ms Xe1-0-0-0-grtlontl1.red.telefonica-wholesale.net [94.142.120.238] 9 45 ms 43 ms 45 ms te0-1-0-2.ccr21.lon01.atlas.cogentco.com [130.117.14.205] 10 45 ms 45 ms 45 ms be2350.ccr41.lon13.atlas.cogentco.com [154.54.39.185] 11 53 ms 53 ms 52 ms be2391.ccr21.lpl01.atlas.cogentco.com [154.54.39.150] 12 133 ms 133 ms 134 ms be2384.ccr21.ymq02.atlas.cogentco.com [154.54.44.137] 13 134 ms 133 ms 133 ms be2090.ccr21.yyz02.atlas.cogentco.com [154.54.30.205] 14 143 ms 142 ms 142 ms be2079.ccr41.ord01.atlas.cogentco.com [154.54.27.181] 15 156 ms 156 ms 156 ms be2156.ccr21.mci01.atlas.cogentco.com [154.54.6.85] 16 169 ms 169 ms 169 ms be2128.ccr21.den01.atlas.cogentco.com [154.54.25.173] 17 176 ms 176 ms 177 ms be2126.ccr21.slc01.atlas.cogentco.com [154.54.25.66] 18 202 ms 202 ms 203 ms be2085.ccr21.sea02.atlas.cogentco.com [154.54.2.197] 19 202 ms 201 ms 201 ms be2084.ccr22.sea01.atlas.cogentco.com [154.54.0.253] 20 205 ms 196 ms 196 ms te4-2.ccr01.sea03.atlas.cogentco.com [154.54.41.146] 21 204 ms 204 ms 204 ms 38.122.90.42 22 199 ms 199 ms 199 ms border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.83] 23 202 ms 201 ms 205 ms geocaching.com [63.251.163.200] Ablaufverfolgung beendet. BR Marmotte Quote Link to comment
+ecanderson Posted January 14, 2015 Share Posted January 14, 2015 (edited) A lot of the time in the tracert above is taken up with intermediate systems (largely, bouncing all over hell in the cogento servers, which represents the vast majority of the problem you're having with latency). Here's a quick ping from my site: Pinging 63.251.163.200 with 32 bytes of data: Reply from 63.251.163.200: bytes=32 time=42ms TTL=245 Reply from 63.251.163.200: bytes=32 time=40ms TTL=245 Reply from 63.251.163.200: bytes=32 time=44ms TTL=245 Reply from 63.251.163.200: bytes=32 time=42ms TTL=245 Ping statistics for 63.251.163.200: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 40ms, Maximum = 44ms, Average = 42ms Edited January 14, 2015 by ecanderson Quote Link to comment
+ecanderson Posted January 14, 2015 Share Posted January 14, 2015 (edited) Here's my tracert, obviously through an entirely different path (which based upon those numbers above, is a GOOD thing!) Tracing route to 63.251.163.200 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 192.168.1.1 2 12 ms 12 ms 11 ms 50.155.210.1 3 21 ms 18 ms 9 ms te-5-4-ur02.longmont.co.denver.comcast.net [68.85.107.197] 4 14 ms 25 ms 11 ms xe-14-0-0-0-ar01.aurora.co.denver.comcast.net [162.151.8.1] 5 16 ms 15 ms 16 ms he-3-4-0-0-cr01.denver.co.ibone.comcast.net [68.86.90.149] 6 19 ms 14 ms 14 ms xe-0-0-2-0-pe01.910fifteenth.co.ibone.comcast.net [68.86.84.26] 7 15 ms 16 ms 14 ms dvr-edge-13.inet.qwest.net [72.164.247.149] 8 * * * Request timed out. 9 44 ms 45 ms 40 ms 63-235-80-54.dia.static.qwest.net [63.235.80.54] 10 43 ms 40 ms 40 ms border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.83] 11 41 ms 43 ms 40 ms 63.251.163.200 Trace complete. Edited January 14, 2015 by ecanderson Quote Link to comment
+GeoLog81 Posted January 14, 2015 Share Posted January 14, 2015 Same in Germany, on evenings (our time) it's so slow that it's almost impossible to use. Quote Link to comment
+Viajero Perdido Posted January 14, 2015 Share Posted January 14, 2015 Yeah, it's slow. I've gotten used to it. If we complain too much, they'll take away features until it runs smoothly again. (Remember full-text name search?) Quote Link to comment
+tomatosoup_v2.0 Posted January 14, 2015 Share Posted January 14, 2015 Same here gc Homepage verrrry slow . with DSL and over Air with LTE 100mb ;( Quote Link to comment
+EngPhil Posted January 15, 2015 Share Posted January 15, 2015 I've noticed the same over the last couple of months, with both the website and the API at times, often during the Australian evenings (which is the middle of the night in the USA, a time when I'd expect less traffic load on the platform...) Quote Link to comment
+Homer_J_Simpson Posted January 16, 2015 Share Posted January 16, 2015 So, I - and many other users in Germany - have the same Problems for quite a while. In German evenings around 8pm the Website is not even slow, even getting Access to a Cache listing is impossible. If you log out, Login to the site is not possible anymore. I saw the following behaviour: You click on a link to a Cache listing and the browser (IE11 or Firefox or ...) tries to get the data from Groundspeak. After a while, a Brown Background ist displayes and a few minutes later, the browser stops (the "loading circle" on top is not circling anymore, but no Cache listing is displayed. However, when I callup the sites source code, all data seems to be transferred because I can read the last logs in the HTML Code. Perhaps the slowniness is caused by elements which are loaded from other Servers like Advertising or picturs? One time I tried to clear my browser Cache and History. After that, I have to log in again which was not possible. Getting on the Login page, entering my credentials and clicking on the Login button put me back again to the Login page. This issue happens every evening for quite a while. Meanwhile, In Germany it is impossible to plan a Cache tour or solve mysteries when you cannot get the listings in the evening. Only at daytime - when nearly everyone is at work - the site Performance is ok. Please get this issue fixed really soon, or many People who pay for the Service will be very angry! Quote Link to comment
+capsai Posted January 16, 2015 Share Posted January 16, 2015 I can confirm the behaviour. Maybe Groundspeak should install an mirror-server in europe... Quote Link to comment
+GeoLog81 Posted January 16, 2015 Share Posted January 16, 2015 Have someone noticed that behaviour? Because I'm not sure how to report it, the most fitting category was Bug Report. The website practically is impossible to use until late evening hours (about 23). In that time, API calls are slow, but they are eventually finished. I've managed to download 500 caches with listing to Locus in a dozen of minutes, in the same time I wasn't able to open a single listing in the browser. Quote Link to comment
+holbi Posted January 16, 2015 Author Share Posted January 16, 2015 Have someone noticed that behaviour? Because I'm not sure how to report it, the most fitting category was Bug Report. I did so and received an answer from Alex yesterday, that the IT team is looking in to this issue. Quote Link to comment
+MartyBartfast Posted January 16, 2015 Share Posted January 16, 2015 Maybe Groundspeak should install an mirror-server in europe... I can't say I've noticed any problems here in the UK, and I haven't seen anyone complaining on any of the UK Geocaching facebook groups which I'm a member of, everything seems reasonably quick from over here, so maybe it's just a Central Europe issue, or maybe you're all on the same Internet Service Provider and it's their problem? Quote Link to comment
+massafranz Posted January 16, 2015 Share Posted January 16, 2015 It doesn't look like it depends on the provider. There are some other players which told me about the same problem, and they definitively use different ISPs than i do. Today, the manner appeared between 1800 and 2100 local time (1700-2000 GMT). Quote Link to comment
+pri0n Posted January 18, 2015 Share Posted January 18, 2015 I'm fairly sure it's got nothing to do with ISPs as I was (and still am) experiencing the very same behaviour described by German users in both France and Austria over the past few days - different providers, same hours of the day though... Quote Link to comment
+massafranz Posted January 18, 2015 Share Posted January 18, 2015 (edited) Today, it was a new 'milesone' related to waiting. without any problem, i could order and polish off a pizza while waiting for the page... Edited January 18, 2015 by massafranz Quote Link to comment
+holbi Posted January 18, 2015 Author Share Posted January 18, 2015 Today, the website is completely unusable for me here in Germany since ~18:00 UTC. I've somehow managed to get my three logs for today posted through the API, but nothing more. A statement from Groundspeak on this topic would be greatly appreciated! holbi Quote Link to comment
+Confectrician Posted January 18, 2015 Share Posted January 18, 2015 (edited) Same here. Other website are running quite fine here. Only geocaching.com is lagging like hell. Tested with dsl and lte connection. (I needed also 15min to access the forum and post here.) Edited January 18, 2015 by Confectrician Quote Link to comment
+ecanderson Posted January 18, 2015 Share Posted January 18, 2015 Not experiencing any unusual lag here in North America at any time today. Have been working with the site most of the morning, and this afternoon while I watch the football game. For those of you struggling with this, would you please run tracert a few times to see where the problem occurs? Quote Link to comment
+webmicha Posted January 18, 2015 Share Posted January 18, 2015 I do not have any problems. Wether log in, nor page loading or app access takes a lot of time. For, also in Germany, everything is fine, even when a lot of other geocachers are complaining on facebook. Quote Link to comment
+EngPhil Posted January 19, 2015 Share Posted January 19, 2015 Works fine for some folks while being ridiculously slow for others? Could it be content served off an iffy CDN, or perhaps a bad backend node coupled with a load balancer with persistence locking people onto it? Perhaps those experiencing problems could do a "view source" on the geocaching.com homepage (once it eventually loads) and check right at the end... there's a comment that shows what server you're hitting. For example, right now this server: <!-- Server: WEB20; Build: Tucson.Main.release-20150113.Release_234 --> seems to be flying along for me..... Quote Link to comment
+ecanderson Posted January 19, 2015 Share Posted January 19, 2015 What's of interest is that as far as I can tell, all of the complaints in this thread are coming out of Europe, and it's not related to time of day. Quote Link to comment
+Sherlock__Holmes Posted January 19, 2015 Share Posted January 19, 2015 Just a quick confirmation: I was unable to use gc.com and the forum yesterday (Sunday) afternoon until around 11pm (then I stopped trying) from Frankfurt, Germany. It took ages for the main page, listings, or the map to load or sites failed to appear completely. Would be great if this issue could be resolved. Best regards, Sherlock Quote Link to comment
+MartyBartfast Posted January 19, 2015 Share Posted January 19, 2015 What's of interest is that as far as I can tell, all of the complaints in this thread are coming out of Europe, and it's not related to time of day. Specifically continental Europe, there are no complaints from the UK and I have had no issues in the UK and I haven't seen any complaints from any UK cachers, so it certainly sounds like it's geographical, in which case it's unlikely to be at Groundspeak's end. Quote Link to comment
+holbi Posted January 19, 2015 Author Share Posted January 19, 2015 When a website is implemented with a CDN the location of the request can make a difference. And while every other website I've tried runs smoothly, gc.com is dead slow every single evening for me in Germany for weeks now! So I do not think that it is a network issue, when having a look at a request for a cache listing with firebug I see that some elements or scripts won't load while others do. I also think that http://status.geocaching.com/ might be misleading if it is based on ping measurements, because they won't say anything about http performance in a CDN. Quote Link to comment
Funkenbande Posted January 19, 2015 Share Posted January 19, 2015 I notice also the extremely bad performance of the GC site since some time now. I also live in Germany and I asked myself if the bad performance migth have something to do with the changed website-layout? The really bad performance started this year. Last year everything was fine. I was thinking about getting Premium - but not with that performance (( Quote Link to comment
cezanne Posted January 19, 2015 Share Posted January 19, 2015 (edited) A lot of the time in the tracert above is taken up with intermediate systems (largely, bouncing all over hell in the cogento servers, which represents the vast majority of the problem you're having with latency). Yes, it's well known that the cogento servers and also some less than ideal routings constitute a considerable portion of the problem. Game players complain a lot about issues with cogento.com. When using other web sites in the US, I did not encounter cogento.com among the hops which might explain while so many continental European geocachers experience lags with geocaching.com but not when addressing other sites in the US (arbitrary example e.g. www.mit.edu www.nytimes.com, etc) Edited January 19, 2015 by Keystone Quote Link to comment
+Igors Gesandte Posted January 19, 2015 Share Posted January 19, 2015 The network times doesn't justify the lag and even timeouts I see in the last weeks. Just tried to access the main page from Germany which took about 8 seconds. Tryping to access the maps (https://www.geocaching.com/map/default.aspx?ll=...) timed out after 35 seconds. Then i started a VPN terminating in the US and everything is responsive: 200ms TFB for the start page, approx 2 seconds to load and render the map. Quote Link to comment
+GeoLog81 Posted January 19, 2015 Share Posted January 19, 2015 Server: WEB09; Build: Tucson.Main.release-20150113.Release_234 Today is also very slow (even more than minute to get the page loaded). Quote Link to comment
+HHL Posted January 19, 2015 Share Posted January 19, 2015 [...] Tryping to access the maps (https://www.geocachi...ult.aspx?ll=...) timed out after 35 seconds. [...] You'd better should have used a working url. Try this: https://www.geocaching.com/map/ Hans Quote Link to comment
+massafranz Posted January 19, 2015 Share Posted January 19, 2015 Today is also very slow (even more than minute to get the page loaded). ONE minute? Lucky guy... Quote Link to comment
+Igors Gesandte Posted January 19, 2015 Share Posted January 19, 2015 Of course used a working URL; see http://en.wikipedia.org/wiki/Ellipsis [...] Tryping to access the maps (https://www.geocachi...ult.aspx?ll=...) timed out after 35 seconds. [...] You'd better should have used a working url. Try this: https://www.geocaching.com/map/ Hans Quote Link to comment
+pri0n Posted January 20, 2015 Share Posted January 20, 2015 (edited) Perhaps those experiencing problems could do a "view source" on the geocaching.com homepage (once it eventually loads) and check right at the end... there's a comment that shows what server you're hitting. For example, right now this server: <!-- Server: WEB20; Build: Tucson.Main.release-20150113.Release_234 --> seems to be flying along for me..... WEB14 is veeeeery slow for me right now (but that was the only server I could even reach within the last hour...) Routenverfolgung zu geocaching.com [63.251.163.200] über maximal 30 Abschnitte: 1 1 ms 1 ms 1 ms home.router [xxx.xxx.xxx.xxx] 2 19 ms 10 ms 11 ms 84.116.231.159 3 23 ms 19 ms 24 ms 84.116.229.193 4 196 ms 190 ms 196 ms at-vie01a-rd1-vl-2047.aorta.net [84.116.228.145] 5 195 ms 190 ms 206 ms nl-ams05a-rd2-xe-0-0-0.aorta.net [84.116.130.81] 6 118 ms 119 ms * us-nyc01b-rd1-gi-2-0-0.aorta.net [84.116.130.26] 7 189 ms 196 ms 192 ms 84.116.137.222 8 191 ms 184 ms 195 ms 63-235-40-153.dia.static.qwest.net [63.235.40.153] 9 233 ms 222 ms 229 ms sea-edge-13.inet.qwest.net [67.14.41.70] 10 221 ms 216 ms 211 ms 63-235-80-54.dia.static.qwest.net [63.235.80.54] 11 215 ms 219 ms 212 ms border8.po1-40g-bbnet1.sef.pnap.net [63.251.160.18] 12 213 ms 213 ms 209 ms 63.251.163.200 EDIT: took me 20 minutes and 3 timeout errors to post this answer' date=' accessing the forums from my french vpn now (normal loading times right now, server WEB11): Hop Hostname IP Time 1 Time 21 private xxx.xxx.xxx.xxx 0.111ms 1 vss-2b-6k.fr.eu 94.23.226.252 54.500ms 1 vss-2b-6k.fr.eu 94.23.226.252 0.693ms 2 rbx-g1-a9.fr.eu 91.121.131.237 1.010ms 3 no reply * 4 no reply * 5 no reply * 6 ae10.mpr2.lhr2.uk.zip.zayo.com 64.125.31.194 4.602ms 7 xe-7-1-0.cr1.lga5.us.zip.zayo.com 64.125.26.37 73.112ms 8 ae6.cr1.ord2.us.zip.zayo.com 64.125.24.34 91.090ms 9 ae16.mpr1.sea1.us.zip.zayo.com 64.125.21.138 139.423ms 10 208.185.125.106.IPYX-072053-008-ZYO.above.net 208.185.125.106 224.791ms 11 border9.po1-40g-bbnet1.sef.pnap.net 63.251.160.19 148.827ms 12 63.251.163.200 63.251.163.200 147.038ms Edited January 20, 2015 by pri0n Quote Link to comment
+1887 Posted January 20, 2015 Share Posted January 20, 2015 Hi, in a fast period I will add an answer: Which provider do you use? I use T-Online and have a slow access to the pages (gc, forum and wiki). I tested http://www.seattle.gov/ it has the same speed issues. So I think it is a routing problem of the provider. Best regards Jann Quote Link to comment
+holbi Posted January 20, 2015 Author Share Posted January 20, 2015 As requested in a PM by Alex, here is my current trace. Location Germany, ISP T-Online: 1 <1 ms <1 ms <1 ms fritz.slwlan.box [192.168.0.250] 2 8 ms 7 ms 8 ms 217.0.118.46 3 10 ms 9 ms 10 ms 87.186.241.22 4 11 ms 12 ms 11 ms f-ed4-i.F.DE.NET.DTAG.DE [62.154.14.138] 5 31 ms 30 ms 31 ms 80.156.161.46 6 27 ms 26 ms 33 ms ae-1.r21.frnkge03.de.bb.gin.ntt.net [129.250.6.216] 7 141 ms * 139 ms ae-3.r23.nycmny01.us.bb.gin.ntt.net [129.250.3.180] 8 92 ms 107 ms 93 ms ae-0.r22.nycmny01.us.bb.gin.ntt.net [129.250.3.72] 9 195 ms 194 ms 206 ms ae-1.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.13] 10 197 ms 199 ms 202 ms ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45] 11 170 ms 171 ms 170 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18] 12 170 ms 170 ms 172 ms border8.po2-40g-bbnet2.sef.pnap.net [63.251.160.82] 13 179 ms 183 ms 178 ms 63.251.163.200 Same behaviour as in the last days, gc.com almost unusable since 19:00 UTC, now it's ok again. Quote Link to comment
+tomatosoup_v2.0 Posted January 20, 2015 Share Posted January 20, 2015 Hi"JS" from Twitter goGeocaching Account, here our trace data. Hope you can do something with it and the problem will be solved soon. Because sometimes it´s so slow, one can´t do anything with the website or the API. Location is: Dresden, Germany ISP: T-Online traceroute to geocaching.com (63.251.163.200), 64 hops max, 72 byte packets 1 XXXXXXXXX(192.XXXXXXXXX) 3.376 ms 3.894 ms 2.037 ms 2 87.186.224.218 (87.186.224.218) 9.161 ms 8.740 ms 9.796 ms 3 87.190.191.134 (87.190.191.134) 8.571 ms 9.676 ms 8.832 ms 4 f-ed4-i.f.de.net.dtag.de (62.154.14.130) 18.317 ms 18.280 ms 17.100 ms 5 80.157.128.230 (80.157.128.230) 18.090 ms 18.631 ms 18.403 ms 6 ae-6.r20.frnkge04.de.bb.gin.ntt.net (129.250.6.248) 18.610 ms ae-1.r21.frnkge03.de.bb.gin.ntt.net (129.250.6.216) 24.456 ms ae-6.r20.frnkge04.de.bb.gin.ntt.net (129.250.6.248) 18.608 ms 7 ae-3.r23.nycmny01.us.bb.gin.ntt.net (129.250.3.180) 147.174 ms 147.387 ms ae-7.r22.asbnva02.us.bb.gin.ntt.net (129.250.3.20) 133.801 ms 8 ae-0.r22.nycmny01.us.bb.gin.ntt.net (129.250.3.72) 127.891 ms 130.579 ms 123.428 ms 9 ae-5.r21.sttlwa01.us.bb.gin.ntt.net (129.250.4.182) 508.142 ms 247.352 ms ae-1.r21.sttlwa01.us.bb.gin.ntt.net (129.250.4.13) 235.995 ms 10 ae-2.r04.sttlwa01.us.bb.gin.ntt.net (129.250.5.45) 255.022 ms 259.749 ms 252.401 ms 11 * ae-0.internap.sttlwa01.us.bb.gin.ntt.net (129.250.201.18) 376.347 ms 223.212 ms 12 border8.po1-40g-bbnet1.sef.pnap.net (63.251.160.18) 354.876 ms 648.917 ms 506.138 ms 13 63.251.163.200 (63.251.163.200) 511.959 ms 509.374 ms 512.301 ms PING geocaching.com (63.251.163.200): 56 data bytes 64 bytes from 63.251.163.200: icmp_seq=0 ttl=245 time=231.315 ms 64 bytes from 63.251.163.200: icmp_seq=1 ttl=245 time=218.284 ms 64 bytes from 63.251.163.200: icmp_seq=2 ttl=245 time=223.224 ms 64 bytes from 63.251.163.200: icmp_seq=3 ttl=245 time=226.252 ms 64 bytes from 63.251.163.200: icmp_seq=4 ttl=245 time=225.311 ms 64 bytes from 63.251.163.200: icmp_seq=5 ttl=245 time=221.818 ms 64 bytes from 63.251.163.200: icmp_seq=6 ttl=245 time=217.292 ms 64 bytes from 63.251.163.200: icmp_seq=7 ttl=245 time=200.838 ms 64 bytes from 63.251.163.200: icmp_seq=8 ttl=245 time=221.414 ms 64 bytes from 63.251.163.200: icmp_seq=9 ttl=245 time=191.583 ms --- geocaching.com ping statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 191.583/217.733/231.315/11.596 ms PING geocaching.com (63.251.163.200): 56 data bytes 64 bytes from 63.251.163.200: icmp_seq=0 ttl=245 time=378.121 ms 64 bytes from 63.251.163.200: icmp_seq=1 ttl=245 time=452.927 ms 64 bytes from 63.251.163.200: icmp_seq=2 ttl=245 time=398.323 ms 64 bytes from 63.251.163.200: icmp_seq=3 ttl=245 time=353.585 ms 64 bytes from 63.251.163.200: icmp_seq=4 ttl=245 time=327.212 ms 64 bytes from 63.251.163.200: icmp_seq=5 ttl=245 time=379.283 ms 64 bytes from 63.251.163.200: icmp_seq=6 ttl=245 time=437.034 ms 64 bytes from 63.251.163.200: icmp_seq=7 ttl=245 time=371.503 ms 64 bytes from 63.251.163.200: icmp_seq=8 ttl=245 time=371.667 ms 64 bytes from 63.251.163.200: icmp_seq=9 ttl=245 time=386.024 ms --- geocaching.com ping statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 327.212/385.568/452.927/35.019 ms Quote Link to comment
+Chrysalides Posted January 20, 2015 Share Posted January 20, 2015 1 XXXXXXXXX(192.XXXXXXXXX) 3.376 ms 3.894 ms 2.037 ms The 192 address is private and won't reveal anything about your home network - though it does no harm deleting it. The 2nd IP address is probably the public IP address your ISP assigned to you and is the one that should be edited for privacy. And while you're at it, take out the 3rd one as well, which is probably a regional router that's close to you. Quote Link to comment
+Homer_J_Simpson Posted January 21, 2015 Share Posted January 21, 2015 Yesterday in the evening - same procedure as every day - GC Website Response was very slow or listing pages were not displayed. For a short time, the Website seemed to work fine, I first called the GC-Map around my homezone and then a few Cache pages. Response was fine. A few minutes later, I was not able to call up anything from GC.com, even the Forum pages were not available. I don't think the reason for this behaviour is from the Internet Connection from Germany to Seattle. Calling nasa.gov or Seattle.gov or other pages from North america works fine. So I think Groundspeak runs several web Servers for load balancing (at the bottom of the source code of a page there is a comment on which web Server the page was rendered) and the Response time depends to which web Server the user is connected. Quote Link to comment
+ecanderson Posted January 21, 2015 Share Posted January 21, 2015 @Homer Are you able to identify particular gc.com servers that are causing you the delay vs. those that are not? Again, I am still not seeing delays within North America at all with the routing that is occurring here, so I cannot contribute to that analysis. Quote Link to comment
+baer2006 Posted January 21, 2015 Share Posted January 21, 2015 (edited) I'm in Germany, online via the provider "T-Online". For about a week or so, it's nearly always the same pattern (all times are CET): During the day and early evening, everything runs fine. At around 2000-2100 hrs, access to the sites (both www.geocaching.com and forums.Groundspeak.com) gets extremely slow. Loading of cache pages takes many minutes, and mostly doesn't finish at all. Usually, the problem ends some time before midnight. Staying up late is the only way for me to get anything done on the website during the week. Some observations: - The situation is close to "All or Nothing". Either the pages load really fast, or (almost) not at all. - As a consequence of the last point, the problem arises (and disappears) from one moment to the next, without any "warning" (like pages loading slightly slower, but still loading). - I don't think that the particular server makes a difference. In the current "slow period", I've seen WEB15 and WEB05 in the HTML source code. - While looking for the WEBxx server numbers, I noticed something interesting: Relatively soon after I starting to load a cache page, when there is still only the background color visible, I can already view the HTML source till the end (where the WEBxx number ist). So the HTML is apparently completely loaded but nothing is displayed by the browser. I don't have nearly enough expertise in web programming to see what this means (perhaps browser waiting for a javascript to finish??), but maybe someone who does finds this useful. Edited January 21, 2015 by baer2006 Quote Link to comment
+Chrysalides Posted January 21, 2015 Share Posted January 21, 2015 (edited) I encountered problems today around noon Pacific Standard Time from California. Main website was unresponsive. Forums was humming along fine. Edited January 21, 2015 by Keystone Removed quoted potty language. Quote Link to comment
Moun10Bike Posted January 21, 2015 Share Posted January 21, 2015 I encountered problems today around noon Pacific Standard Time from California. Main website was unresponsive. Forums was humming along fine. That was likely due to the site update that occurred around that time. Meanwhile, our IT department is continuing to investigate the slowdown reports emanating from Germany. Quote Link to comment
cezanne Posted January 21, 2015 Share Posted January 21, 2015 That was likely due to the site update that occurred around that time. Meanwhile, our IT department is continuing to investigate the slowdown reports emanating from Germany. Not only from Germany. One cacher reported about problems both from France and Austria in this thread and I also often observe a very slow site on Sunday evenings (also last Sunday) and this is the case also when I access the site via a very fast network. Quote Link to comment
Moun10Bike Posted January 21, 2015 Share Posted January 21, 2015 Sorry for not being more precise - emanating from continental Europe, and predominantly centered in Germany. Quote Link to comment
+Sherlock__Holmes Posted January 22, 2015 Share Posted January 22, 2015 That was likely due to the site update that occurred around that time. Meanwhile, our IT department is continuing to investigate the slowdown reports emanating from Germany. Thanks, this is much appreciated! Quote Link to comment
+Pinkpiggy7 Posted January 22, 2015 Share Posted January 22, 2015 (edited) Appears to be an issue with uploading found logs from australia. at the moment Edited January 22, 2015 by Pinkpiggy7 Quote Link to comment
+Mausebiber Posted January 22, 2015 Share Posted January 22, 2015 Hi, I’m located in Heidelberg, Germany; Internet provider is T-Online. For quite some time, the access to Geocaching.com and all links below behave like this: At about 19:00 local time the response time gets slower and slower and at about 20:30 pages loading extremely slow until pages not loading at all. I have tried to refresh but it just won’t connect any more. A friend of mine living close by, same Internet provider has exactly the same problem at the same time. Calling another friend, different ISP seems to have fewer problems. Other sites hosted in the US could be accessed without any problems. I have called Telekom and addressed this problem and they were looking into lines and connections and couldn’t find any problems. While I had the Hotline on the phone, I couldn’t access Geocaching.com while the technician, located in Düsseldorf (about 300km from Heidelberg) had no problem accessing Geocaching.com. The time I’m using gc.com most often is in the evenings and as it is right now, it’s completely useless and frustrating. Any help fixing this problem is greatly appreciated. Quote Link to comment
Justin Posted January 22, 2015 Share Posted January 22, 2015 Thank you all for providing the situational data in this thread. I've compiled what's been submitted here, Facebook, Twitter and conversations I've had with few of you directly so I can effectively communicate the situation with our provider. I appreciate all of your time and effort, and am terribly sorry to hear that your experience accessing our resources has been degraded in recent weeks. Painting a picture from all of the information provided, I believe ecanderson and cezanne are on the right track with there being a tier 1 ISP routing issue affecting folks in Germany and possibly other parts of central Europe. This is based on posted traceroute (tracert) output of users experiencing dramatically increased latency on middle hops and even packet loss. In all the examples that I've seen so far, the dramatic latency increases are occurring after your provider hands the packet off to a tier 1 ISP, but before it reaches our provider. So neither of our providers' networks appear directly responsible, but some of the internet backbone peers that both of our providers rely on could be. Of the slow instances that I've reviewed, the traceroute output frequently shows routes that include tier 1 network providers Cogent and NTT. I found a relevant article on backbone/peering concerning Netflix that shows Cogent and NTT with higher latency than other providers and talks about the effect of slowing during peak times. Cogent also appears to have engaged in Quality of Service traffic deprioritization that might be worth noting. Likely the best and only course of action is to draw attention to the routing issue and hope it gets resolved soon. I've initiated dialog with the network operations center of our provider, Internap, which you'll see in the last couple of hops of the traceroute output that folks have posted. I know that we utilize several BGP peers, which appear to include Cogent and NTT based on network hop naming. While many ISPs have agreements with these providers as BGP peers, it doesn't indicate if that agreement is direct or third-party, but they might have some influence in getting this resolved. I have asked for guidance on this situation and what options are available to us. With all that said, I would still like to continue collecting more positive and negative experience data from end users in this thread. For those of you including time without specified time zones I'm assuming those are UTC. Since some of you have reported slow load times on Geocaching as well as the Discussion Forums, I would anticipate that load times across all resources at our Seattle Internap facility would yield similar results. It would be helpful to know if the performance is the same on both sites while logged in or browsing as an unathenticated guest. For those that mentioned accessing and tracing seattle.gov when Geocaching was slow to respond, might I suggest tracing origin.rhapsody.com and navigating through their music catalog. Rhapsody is hosted in our space and should have a route much closer to our own. Traceroute output from positive experiences like UK user MartyBartfast reported, or anyone with a trans-Atlantic connection is also welcome. I'd also like to see output from those of you that have been using proxies or VPNs based out of different regions and are having success re-routing around some of these troubled hops/networks. Thanks again, Justin Quote Link to comment
+MartyBartfast Posted January 22, 2015 Share Posted January 22, 2015 Traceroute output from positive experiences like UK user MartyBartfast reported, or anyone with a trans-Atlantic connection is also welcome. Here you go then, performed just now. Response is almost instant and as I said previously I haven't experienced any slowness in recent months, and to me anything that takes more than 2 or 3 seconds to load would be considered slow . For completeness I'm using Firefox on Linux. $ date Thu 22 Jan 10:25:00 GMT 2015 $ traceroute forums.Groundspeak.com traceroute to forums.Groundspeak.com (63.251.163.206), 30 hops max, 60 byte packets 1 router.asus.com (192.168.1.1) 0.659 ms 0.744 ms 1.928 ms 2 cpc2-horn3-2-0-gw.6-1.cable.virginm.net (62.254.68.1) 49.730 ms 50.078 ms 51.738 ms 3 cosh-core-2b-ae8-1862.network.virginmedia.net (80.3.161.229) 11.449 ms 11.466 ms 11.452 ms 4 cosh-core-2a-ae1-0.network.virginmedia.net (80.3.160.253) 11.437 ms 11.421 ms 11.404 ms 5 brhm-bb-1b-ae15-0.network.virginmedia.net (80.3.160.246) 17.748 ms 17.734 ms 17.581 ms 6 teln-ic-1-ae0-0.network.virginmedia.net (212.43.163.250) 22.614 ms 23.361 ms 23.134 ms 7 m282-mp2.cvx3-a.ltn.dial.ntli.net (213.104.85.26) 21.842 ms 22.105 ms 21.854 ms 8 be2494.ccr42.lon13.atlas.cogentco.com (154.54.39.130) 20.679 ms 20.478 ms 20.374 ms 9 be2391.ccr21.lpl01.atlas.cogentco.com (154.54.39.150) 30.510 ms be2491.ccr22.lpl01.atlas.cogentco.com (154.54.39.117) 34.595 ms be2391.ccr21.lpl01.atlas.cogentco.com (154.54.39.150) 33.771 ms 10 be2384.ccr21.ymq02.atlas.cogentco.com (154.54.44.137) 106.114 ms be2385.ccr22.ymq02.atlas.cogentco.com (154.54.44.141) 101.405 ms 96.875 ms 11 be2093.ccr22.yyz02.atlas.cogentco.com (154.54.44.105) 103.788 ms 103.002 ms be2090.ccr21.yyz02.atlas.cogentco.com (154.54.30.205) 104.779 ms 12 be2080.ccr42.ord01.atlas.cogentco.com (154.54.42.5) 118.706 ms be2079.ccr41.ord01.atlas.cogentco.com (154.54.27.181) 118.419 ms 120.370 ms 13 be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 130.144 ms be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117) 131.680 ms 130.504 ms 14 be2130.ccr22.den01.atlas.cogentco.com (154.54.26.121) 141.047 ms 140.903 ms be2128.ccr21.den01.atlas.cogentco.com (154.54.25.173) 140.834 ms 15 be2126.ccr21.slc01.atlas.cogentco.com (154.54.25.66) 151.180 ms be2127.ccr21.slc01.atlas.cogentco.com (154.54.25.70) 153.472 ms be2126.ccr21.slc01.atlas.cogentco.com (154.54.25.66) 153.418 ms 16 be2085.ccr21.sea02.atlas.cogentco.com (154.54.2.197) 170.128 ms 169.145 ms 171.576 ms 17 be2243.rcr12.sea05.atlas.cogentco.com (154.54.6.186) 175.818 ms be2084.ccr22.sea01.atlas.cogentco.com (154.54.0.253) 171.388 ms 171.412 ms 18 te3-2.ccr01.sea03.atlas.cogentco.com (154.54.41.142) 173.806 ms 170.760 ms te2-3.ccr01.sea03.atlas.cogentco.com (154.54.1.185) 171.407 ms 19 Internap-Network-Services.demarc.cogentco.com (38.104.124.82) 171.251 ms 169.782 ms 38.122.90.42 (38.122.90.42) 166.802 ms 20 border8.po1-40g-bbnet1.sef.pnap.net (63.251.160.18) 168.065 ms border8.po2-40g-bbnet2.sef.pnap.net (63.251.160.82) 167.269 ms border9.po1-40g-bbnet1.sef.pnap.net (63.251.160.19) 161.837 ms 21 63.251.163.206 (63.251.163.206) 162.986 ms 162.533 ms 161.659 ms $ date Thu 22 Jan 10:25:12 GMT 2015 $ traceroute www.geocaching.com traceroute to www.geocaching.com (63.251.163.200), 30 hops max, 60 byte packets 1 router.asus.com (192.168.1.1) 0.634 ms 0.672 ms 1.372 ms 2 cpc2-horn3-2-0-gw.6-1.cable.virginm.net (62.254.68.1) 15.038 ms 19.667 ms 19.645 ms 3 cosh-core-2b-ae8-1862.network.virginmedia.net (80.3.161.229) 14.236 ms 14.288 ms 14.252 ms 4 cosh-core-2a-ae1-0.network.virginmedia.net (80.3.160.253) 14.757 ms 14.735 ms 14.492 ms 5 brhm-bb-1b-ae15-0.network.virginmedia.net (80.3.160.246) 20.699 ms 20.499 ms 20.553 ms 6 teln-ic-1-ae0-0.network.virginmedia.net (212.43.163.250) 25.099 ms 22.071 ms 22.030 ms 7 m282-mp2.cvx3-a.ltn.dial.ntli.net (213.104.85.26) 22.083 ms 22.062 ms 21.884 ms 8 be2163.ccr41.lon13.atlas.cogentco.com (130.117.50.202) 21.065 ms be2494.ccr42.lon13.atlas.cogentco.com (154.54.39.130) 24.308 ms be2163.ccr41.lon13.atlas.cogentco.com (130.117.50.202) 22.564 ms 9 be2491.ccr22.lpl01.atlas.cogentco.com (154.54.39.117) 28.524 ms 28.521 ms be2391.ccr21.lpl01.atlas.cogentco.com (154.54.39.150) 27.439 ms 10 be2384.ccr21.ymq02.atlas.cogentco.com (154.54.44.137) 97.797 ms 97.221 ms 97.140 ms 11 be2090.ccr21.yyz02.atlas.cogentco.com (154.54.30.205) 103.947 ms be2093.ccr22.yyz02.atlas.cogentco.com (154.54.44.105) 105.894 ms 105.590 ms 12 be2079.ccr41.ord01.atlas.cogentco.com (154.54.27.181) 120.488 ms be2080.ccr42.ord01.atlas.cogentco.com (154.54.42.5) 118.804 ms be2079.ccr41.ord01.atlas.cogentco.com (154.54.27.181) 118.750 ms 13 be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 132.229 ms be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117) 131.024 ms be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 130.897 ms 14 be2128.ccr21.den01.atlas.cogentco.com (154.54.25.173) 142.334 ms be2130.ccr22.den01.atlas.cogentco.com (154.54.26.121) 142.973 ms 142.871 ms 15 be2126.ccr21.slc01.atlas.cogentco.com (154.54.25.66) 154.674 ms 151.936 ms 151.233 ms 16 be2085.ccr21.sea02.atlas.cogentco.com (154.54.2.197) 170.382 ms 169.380 ms 168.308 ms 17 be2481.rcr11.sea05.atlas.cogentco.com (154.54.25.130) 175.906 ms be2243.rcr12.sea05.atlas.cogentco.com (154.54.6.186) 175.991 ms be2083.ccr21.sea01.atlas.cogentco.com (154.54.0.249) 175.859 ms 18 te4-3.ccr01.sea03.atlas.cogentco.com (154.54.1.209) 171.456 ms te3-2.ccr01.sea03.atlas.cogentco.com (154.54.41.142) 172.873 ms te4-3.ccr01.sea03.atlas.cogentco.com (154.54.1.209) 170.598 ms 19 Internap-Network-Services.demarc.cogentco.com (38.104.124.82) 190.023 ms 182.973 ms 38.122.90.42 (38.122.90.42) 180.162 ms 20 border8.po2-40g-bbnet2.sef.pnap.net (63.251.160.82) 180.021 ms border9.po1-40g-bbnet1.sef.pnap.net (63.251.160.19) 167.898 ms border9.po2-40g-bbnet2.sef.pnap.net (63.251.160.83) 183.958 ms 21 63.251.163.200 (63.251.163.200) 183.450 ms 172.916 ms 173.596 ms Quote Link to comment
+Homer_J_Simpson Posted January 22, 2015 Share Posted January 22, 2015 I tried to figure out if some Webservers from GS are causing the Problem but was not lucky. Sometimes, no answer Comes from geocaching.com. If I was lucky, only the Brown Background of the page is displayed but no Cache listing. Source code of the page was transmitted, I can Display it in another Window of the Browser (Right Click --> View source code) It seems that the page is transmitted, but the last few Bytes which say that Transmission is completed and page can be displayed are missing. Other pages in the US like nasa.gov or Seattle.gov are working fine. Ping Responses and Tracert protocols Show normal conditions throught the web. Also, the number of the webserver displayed at the bottom of the source code doesn't matter. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.