Jump to content

gc.com website slow


holbi

Recommended Posts

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? :P

 

holbi

 

ps: The forum is very slow, too

Link to comment

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

Link to comment

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 by ecanderson
Link to comment

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 by ecanderson
Link to comment

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!

Link to comment

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.

Link to comment

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?

Link to comment

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

Link to comment

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.....

Link to comment

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.

Link to comment

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.

Link to comment

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 :(((

Link to comment

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 by Keystone
Link to comment

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.

Link to comment

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 2

1 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 by pri0n
Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment

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.

Link to comment

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 by baer2006
Link to comment

 

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.

Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

 

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 :ph34r:. 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

Link to comment

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.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...