gc.com website slow

5.7k · May 29, 2015

BTW, their main office is just about 60 miles south of me. Would you like for me to go down and kick someone in the shins for you?

July 2, 2015

Still problems with API and Website from Germany.

Via VPN:

Routenverfolgung zu www.geocaching.com [63.251.163.200]

über maximal 30 Hops:

1 18 ms 16 ms 20 ms 10.9.0.1

2 * * * Zeitüberschreitung der Anforderung.

3 16 ms 26 ms 29 ms ae-1.gw-prtr-a0308-a.kw.nbz.fr.oneandone.net [19

5.20.243.67]

4 16 ms 16 ms 16 ms vl-1960.gw-distp-a.kw.nbz.fr.oneandone.net [195.

20.243.93]

5 21 ms 15 ms 15 ms ae-2-0.bb-a.bap.rhr.de.oneandone.net [195.20.243

.8]

6 15 ms 27 ms 16 ms ae-2-0.bb-a.tp.kae.de.oneandone.net [212.227.120

.44]

7 25 ms 18 ms 20 ms xe-1-0-3.bb-a.fra3.fra.de.oneandone.net [212.227

.120.182]

8 18 ms 19 ms 18 ms xe-1-2-0.mpr1.fra4.de.above.net [80.81.194.26]

9 17 ms 20 ms 19 ms ae8.mpr1.fra3.de.zip.zayo.com [64.125.26.233]

10 30 ms 27 ms 26 ms ae4.cr1.ams5.nl.zip.zayo.com [64.125.32.106]

11 28 ms 31 ms 26 ms ae0.cr1.ams10.nl.zip.zayo.com [64.125.27.62]

12 125 ms 134 ms 125 ms v142.ae29.cr2.ord2.us.zip.zayo.com [64.125.30.17

0]

13 122 ms 117 ms 118 ms ae11.cr1.ord2.us.zip.zayo.com [64.125.20.245]

14 164 ms 171 ms 161 ms v11.ae29.mpr1.sea1.us.zip.zayo.com [64.125.31.50

]

15 159 ms 159 ms 172 ms 208.185.125.106.IPYX-072053-008-ZYO.above.net [2

08.185.125.106]

16 160 ms 163 ms 163 ms border9.po1-40g-bbnet1.sef.pnap.net [63.251.160.

19]

17 169 ms 159 ms 174 ms www.geocaching.com [63.251.163.200]

Via KabelBW/Unitymedia:

Routenverfolgung zu www.geocaching.com [63.251.163.200]

über maximal 30 Hops:

1 <1 ms <1 ms <1 ms 192.168.1.1

2 16 ms 11 ms 11 ms HSI-KBW-109-193-160-001.hsi7.kabel-badenwuerttem

berg.de [109.193.160.1]

3 18 ms 10 ms 17 ms 172.30.9.61

4 8 ms 7 ms 7 ms 84.116.190.21

5 13 ms 18 ms 13 ms 84.116.190.2

6 19 ms 13 ms 23 ms ae-10.r03.frnkge03.de.bb.gin.ntt.net [80.81.192.

46]

7 11 ms 12 ms 10 ms ae-6.r20.frnkge04.de.bb.gin.ntt.net [129.250.6.2

48]

8 118 ms 111 ms 112 ms ae-7.r22.asbnva02.us.bb.gin.ntt.net [129.250.3.2

0]

9 125 ms 117 ms 115 ms ae-0.r23.asbnva02.us.bb.gin.ntt.net [129.250.3.8

5]

10 174 ms 175 ms 175 ms ae-3.r21.sttlwa01.us.bb.gin.ntt.net [129.250.3.5

1]

11 176 ms 186 ms 174 ms ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.4

5]

12 184 ms 180 ms 180 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.25

0.201.18]

13 179 ms 172 ms 175 ms border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.

83]

14 185 ms 174 ms 175 ms www.geocaching.com [63.251.163.200]

July 3, 2015

The problem is also with geocachers with provider Ziggo from the Netherlands. It is a topic with discussions on facebook. Ziggo is the major (cable) internet provider in the Netherlands. The problem is especially big in the evening when many users are logging their finds. It seems to me that Groundspeak is not capable of handling peek internet traffic from the major internet providers in Europe.

6.2k · July 3, 2015

It seems to me that Groundspeak is not capable of handling peek internet traffic from the major internet providers in Europe.

I think it's been established in the previous posts that the issue is with the network providers is SOME parts of Europe (it's fine in the UK), you can't hold Groudnspeak responsible for that.

July 3, 2015

It seems to me that internet traffic is handled via different routes depending on the provider on the user side.

6.2k · July 3, 2015

It seems to me that internet traffic is handled via different routes depending on the provider on the user side.

Not really, the first few hops will be different depending on the ISP, then the ISPs end up going through a trunk provider - which is where the problem seems to lie for those having problems.

July 3, 2015

MartyBartFast, thank you for your simple and clear explanation. So this "trunk provider" is the key problem then...

July 8, 2015

What I have seen is that the connection is extremely slow (unusable) as soon as "ntt.net" (Frankfurt->NYC->Seattle) appears in the TRACERT list. This always happens to me when connecting from my home PC (Cablecom Switzerland).

..snip..
ae-10.r03.frnkge03.de.bb.gin.ntt.net
ae-1.r21.frnkge03.de.bb.gin.ntt.net
ae-3.r23.nycmny01.us.bb.gin.ntt.net
Timeout
Timeout
ae-2.r04.sttlwa01.us.bb.gin.ntt.net
ae-0.internap.sttlwa01.us.bb.gin.ntt
border8.po1-40g-bbnet1.sef.pnap.net
www.geocaching.com

However, when using geocaching.com from my office (at the very same time via VPN) everything is quite fast and my route is using zayo.com for crossing the atlantic ocean - ending up at a different gateway of pnap.net.

..snip..
xe-1-2-0.mpr1.fra4.de.above.net
ae8.mpr1.fra3.de.zip.zayo.com
ae4.cr1.ams5.nl.zip.zayo.com
ae0.cr1.ams10.nl.zip.zayo.com
v142.ae29.cr2.ord2.us.zip.zayo.com
ae11.cr1.ord2.us.zip.zayo.com
v11.ae29.mpr1.sea1.us.zip.zayo
208.185.125.106.ipyx-072053-008
border8.po2-40g-bbnet2.sef.pnap
www.geocaching.com

Seems that the guys at pnap.net should talk to their peering partner ntt.net...

July 10, 2015

What I have seen is that the connection is extremely slow (unusable) as soon as "ntt.net" (Frankfurt->NYC->Seattle) appears in the TRACERT list. This always happens to me when connecting from my home PC (Cablecom Switzerland).
..snip..
ae-10.r03.frnkge03.de.bb.gin.ntt.net
ae-1.r21.frnkge03.de.bb.gin.ntt.net
ae-3.r23.nycmny01.us.bb.gin.ntt.net
Timeout
Timeout
ae-2.r04.sttlwa01.us.bb.gin.ntt.net
ae-0.internap.sttlwa01.us.bb.gin.ntt
border8.po1-40g-bbnet1.sef.pnap.net
www.geocaching.com
However, when using geocaching.com from my office (at the very same time via VPN) everything is quite fast and my route is using zayo.com for crossing the atlantic ocean - ending up at a different gateway of pnap.net.
..snip..
xe-1-2-0.mpr1.fra4.de.above.net
ae8.mpr1.fra3.de.zip.zayo.com
ae4.cr1.ams5.nl.zip.zayo.com
ae0.cr1.ams10.nl.zip.zayo.com
v142.ae29.cr2.ord2.us.zip.zayo.com
ae11.cr1.ord2.us.zip.zayo.com
v11.ae29.mpr1.sea1.us.zip.zayo
208.185.125.106.ipyx-072053-008
border8.po2-40g-bbnet2.sef.pnap
www.geocaching.com
Seems that the guys at pnap.net should talk to their peering partner ntt.net...

From what we've observed recently, the routes from our infrastructure to the client are actually more valuable for troubleshooting this issue. Outbound connections over NTT are typically quite good, and with regard to the Deutsche Telekom users previously having issues in this thread--we were able to determine that connections over GTT and ATT were problematic.

A workaround has been put in place to avoid those peers for the DT network ranges we've observed complaints on, but it has to be applied via CIDR notation for each network specified. Right now we've applied the workaround for 7 of the largest CIDRs announced by DT, which covers ~25 million of the 34.3 million addresses announced via RIPEstat.

Those ranges currently avoiding ATT and GTT are:

79.192.0.0/10 (79.192.0.0 - 79.255.255.255)

84.128.0.0/10 (84.128.0.0 - 84.191.255.255)

87.128.0.0/10 (87.128.0.0 - 87.191.255.255)

91.0.0.0/10 (91.0.0.0 - 91.63.255.255)

93.192.0.0/10 (93.192.0.0 - 93.255.255.255)

217.0.0.0/13 (217.0.0.0 - 217.7.255.255)

217.224.0.0/11 (217.224.0.0 - 217.255.255.255)

217.80.0.0/12 (217.80.0.0 - 218.95.255.255)

Are you observing this slowness around the window of 18:00-20:00 CET or can you give an estimate? Do you know if your cablecom.ch IP is static or typically operates in the same CIDR? RIPEstats for your ISP do not appear complete, so I would have a hard time isolating possible networks for a workaround based on that information.

July 14, 2015

Is there any way to get help with the slowness I am experiencing?

I've outlined here:

Currently on a netblock: 176.61.64.0 - 176.61.95.255

The site is unusable from about 1700hrs UTC daily until next morning.

July 14, 2015

hmm i think last post might have got caught as spam. lets try again.

Is there any way to get help with slownesses i am experience. It's quite frustraing that I can not use the site from 1700hrs UTC til the next day.

3.|-- 109.255.254.29 0.0% 20 12.4 12.1 10.0 18.3 1.8

4.|-- 84.116.238.70 0.0% 20 24.6 24.3 19.7 30.7 2.8

5.|-- 84.116.137.74 0.0% 20 20.3 21.6 16.6 39.5 4.6

6.|-- 84.116.133.18 0.0% 20 20.9 24.1 20.9 32.7 2.7

7.|-- 195.66.236.138 0.0% 20 20.8 22.9 18.3 39.9 5.4

8.|-- 129.250.4.85 0.0% 20 21.1 24.6 20.5 46.3 5.4

9.|-- 129.250.3.126 0.0% 20 125.2 122.0 112.9 146.4 9.0

10.|-- 129.250.4.13 20.0% 20 197.8 202.2 195.5 214.4 6.4

11.|-- 129.250.5.45 0.0% 20 198.6 199.2 194.6 207.1 2.6

12.|-- 129.250.201.18 0.0% 20 178.2 164.4 155.8 178.2 5.2

13.|-- 63.251.160.82 5.0% 20 163.1 182.0 160.0 317.7 37.8

14.|-- 63.251.163.200 5.0% 20 154.7 162.3 153.1 173.1 5.6

ISP using at least this netblock: 176.61.64.0 - 176.61.95.255

July 14, 2015

Are you observing this slowness around the window of 18:00-20:00 CET or can you give an estimate? Do you know if your cablecom.ch IP is static or typically operates in the same CIDR? RIPEstats for your ISP do not appear complete, so I would have a hard time isolating possible networks for a workaround based on that information.

Thank you for your investigations! Right now, it's about 23:30 CET and the webpage is still unreachable. That's why I'm currently using a VPN connection (via UK) to write this reply.

Problems usually start in the region of 17:00-17:30 (CET) on working days and won't recover during the entire evening. On weekends, problems arise even earlier during the afternoon. We have a large number of users here, who are reporting the same issues in the Swiss Geocaching Forum. Most of them are Cablecom customers.

My IP is not static but operates in the same CIDR:

inetnum: 178.82.0.0 - 178.83.191.255

netname: CABLECOMMAIN-NET

descr: Cablecom GmbH

descr: DHCP Scopes

descr: Zuerich

country: CH

remarks: *************************************************

remarks: For spam/abuse, please contact abuse@cablecom.ch

remarks: E-mails to the persons below will be IGNORED!!

remarks: *************************************************

admin-c: LGI-RIPE

tech-c: LGI-RIPE

status: ASSIGNED PA

mnt-by: MNT-LGI

created: 2010-03-08T08:50:17Z

last-modified: 2012-07-03T08:10:21Z

source: RIPE # Filtered

Greetings

Ralf

July 14, 2015

I have a user from the Netherlands with this issue. His ISP is #Ziggo. https://twitter.com/WalsjeWouter/status/620695006240751616. I'm adding this since he can't access the forums. Let me know if there is more info I can gather.

July 15, 2015

Have noticed that website has been degraded for a log time. Yes... the brown background is present.

My Browser shows the issue is to 3 party cookies...

The browser stops when trying to load to get cookies from 3rd parties:

google

cloudfront (amazon)

If one site is down from your 3rd or 4th party sites.. geocaching.com will not work.

I have observed this for the last several years.

elemate the outsourced so you have a compliant HTTPS inbound source.

July 15, 2015

Hi Justin

I've got all IP-Blocks of the Swiss Cablecom ISP here - a total of 63 (!) ranges registered at RIPE with netname CABLECOMMAIN-NET.

Since I don't want to blow up this thread, shall I send this to you by mail?

Greetings

Ralf

July 15, 2015

Hi Justin.

Major problems have surfaced in Ireland this week. We've always had a slow site in the evenings and at weekends but from late last week (around the 10th I guess) the GC site (and associated sites, API, forums) have been completely unresponsive in the evening, or at best diabolically slow. They're fast early morning, but bog down late in the evenings, usually around 6pm GMT. It is ONLY on the UPC Ireland ISP, every UPC customer I know has problems. 4G and other providers never slow down. UPC are aware but are hopeless at customer support. [All other websites work fine by the way]

We've independently come to the same conclusion as you guys, that a node halfway along the Tracert 'list' is to blame. I have been using Pingplotter to traceroute over time, and get an idea of the packetloss going on. The packetloss from the server at fault is usually between 20 and 50%, but in the evenings goes right up to 100%, and the site doesn't work.

nl-ams02a-rd2-xe-5-1-1.aorta.net at 84.116.130.33 is the troublemaker. Heres some pics from Pingplotter.

Edit: Aorta servers are one of UPCs backbones.

Edited July 15, 2015 by THE_Chris

July 15, 2015

We've independently come to the same conclusion as you guys, that a node halfway along the Tracert 'list' is to blame. I have been using Pingplotter to traceroute over time, and get an idea of the packetloss going on. The packetloss from the server at fault is usually between 20 and 50%, but in the evenings goes right up to 100%, and the site doesn't work.

Packet loss at a single hop in the trace with no loss after it is not indicative of a fault.

The router is doing its job, passing packets back and forth. Responding to traceroutes is right at the bottom of its priority list. If it has better things to do (like, say, routing packets) then your traceroute gets ignored.

The fact that there is zero loss after that hop confirms that there is not a problem there at all. The packets are getting through just fine. If the loss started at one hop and continued in multiple subsequent hops, then it would indicate a problem.

July 16, 2015

Hi Justin

I've got all IP-Blocks of the Swiss Cablecom ISP here - a total of 63 (!) ranges registered at RIPE with netname CABLECOMMAIN-NET.

Since I don't want to blow up this thread, shall I send this to you by mail?

Greetings

Ralf

I've requested a shunt to avoid ATT, Cogent and GTT on your CIDR. This should be active now, so please let me know if your experience has improved on your next attempt at browsing the site during a previous slow period.

178.82.0.0/16 will now only use NTT, Qwest, XO or Zayo. You can view your outbound route from our infrastructure by visiting http://tracer01.Groundspeak.com

I'm preparing a post so we can start collecting more evidence of the slowdown and identify which peer(s) is responsible for those of you affiliated with UPC.

July 16, 2015

hmm i think last post might have got caught as spam. lets try again.

Is there any way to get help with slownesses i am experience. It's quite frustraing that I can not use the site from 1700hrs UTC til the next day.

3.|-- 109.255.254.29 0.0% 20 12.4 12.1 10.0 18.3 1.8

4.|-- 84.116.238.70 0.0% 20 24.6 24.3 19.7 30.7 2.8

5.|-- 84.116.137.74 0.0% 20 20.3 21.6 16.6 39.5 4.6

6.|-- 84.116.133.18 0.0% 20 20.9 24.1 20.9 32.7 2.7

7.|-- 195.66.236.138 0.0% 20 20.8 22.9 18.3 39.9 5.4

8.|-- 129.250.4.85 0.0% 20 21.1 24.6 20.5 46.3 5.4

9.|-- 129.250.3.126 0.0% 20 125.2 122.0 112.9 146.4 9.0

10.|-- 129.250.4.13 20.0% 20 197.8 202.2 195.5 214.4 6.4

11.|-- 129.250.5.45 0.0% 20 198.6 199.2 194.6 207.1 2.6

12.|-- 129.250.201.18 0.0% 20 178.2 164.4 155.8 178.2 5.2

13.|-- 63.251.160.82 5.0% 20 163.1 182.0 160.0 317.7 37.8

14.|-- 63.251.163.200 5.0% 20 154.7 162.3 153.1 173.1 5.6

ISP using at least this netblock: 176.61.64.0 - 176.61.95.255

Tracing from your client to our infrastructure does not appear to be fruitful in this situation. Please run a trace from our network to your client IP by visiting http://tracer01.Groundspeak.com during a slow period. You can either reply with the output in this thread or if you prefer to not share your IP, submit it to the Customer Management team via http://support.Groundspeak.com/index.php?pg=request with ATTN: Justin.

Once I've gathered more data, I'll request shunts for your network/ISP and you can determine if the situation has improved.

July 16, 2015

We've independently come to the same conclusion as you guys, that a node halfway along the Tracert 'list' is to blame. I have been using Pingplotter to traceroute over time, and get an idea of the packetloss going on. The packetloss from the server at fault is usually between 20 and 50%, but in the evenings goes right up to 100%, and the site doesn't work.

Packet loss at a single hop in the trace with no loss after it is not indicative of a fault.

The router is doing its job, passing packets back and forth. Responding to traceroutes is right at the bottom of its priority list. If it has better things to do (like, say, routing packets) then your traceroute gets ignored.

The fact that there is zero loss after that hop confirms that there is not a problem there at all. The packets are getting through just fine. If the loss started at one hop and continued in multiple subsequent hops, then it would indicate a problem.

EngPhil is correct. What you're seeing here is ICMP deprioritization and it has caused a lot of confusion for users trying to troubleshoot the issue from their end. When "packet loss" is present at one hop and doesn't persist from source to destination, it means that that router had more important obligations and was saving its resources for its primary networking functions.

We need to gather data from users during the slowdowns so we can identify which of our 7 available BGP peers is responsible for this problem. You can participate by providing traceroute data from our network back to your client by visiting http://tracer01.Groundspeak.com

In the case of Deutsche Telekom users, we were able to identify poor experiences using ATT or GTT. I suspect we might find a similar pattern with users on your ISP, but we need to collect more samples to be sure. There are some recent publications that could possibly address what we've seeing:

http://blog.streamingmedia.com/2015/06/isps-not-causing-network-slowdowns.html

http://money.cnn.com/2015/06/25/technology/slow-internet/

July 17, 2015

Have noticed this issue for 1.5 years. My browser tells me that it a 3rd party site that cannot deliver content. AKA: cloudfront, googleanalytics.

These sites are heavily used will degrade the GC site.

On a side note, Images from the gallery will not display sometimes. Don't know where they are hosted now (probably cloudfront)

July 17, 2015

Have noticed this issue for 1.5 years. My browser tells me that it a 3rd party site that cannot deliver content. AKA: cloudfront, googleanalytics.

These sites are heavily used will degrade the GC site.

On a side note, Images from the gallery will not display sometimes. Don't know where they are hosted now (probably cloudfront)

That might be... however, when accessing www.geocaching.com via VPN at the very same time (Office), the site is quite responsive but won't come to an end at home...

July 17, 2015

I've requested a shunt to avoid ATT, Cogent and GTT on your CIDR. This should be active now, so please let me know if your experience has improved on your next attempt at browsing the site during a previous slow period.

178.82.0.0/16 will now only use NTT, Qwest, XO or Zayo. You can view your outbound route from our infrastructure by visiting http://tracer01.Groundspeak.com

I'm preparing a post so we can start collecting more evidence of the slowdown and identify which peer(s) is responsible for those of you affiliated with UPC.

Hi Justin

I've got all IP-Blocks of the Swiss Cablecom ISP here - a total of 63 (!) ranges registered at RIPE with netname CABLECOMMAIN-NET.

Since I don't want to blow up this thread, shall I send this to you by mail?

Greetings

Ralf

Wow... it's 17:53 and everything's quite fast - didn't have this for weeks. :rolleyes: Will keep monitoring...

July 17, 2015

Have noticed this issue for 1.5 years. My browser tells me that it a 3rd party site that cannot deliver content. AKA: cloudfront, googleanalytics.

These sites are heavily used will degrade the GC site.

On a side note, Images from the gallery will not display sometimes. Don't know where they are hosted now (probably cloudfront)

I don't believe your issue is related to what the others in this thread are experiencing.

Images are hosted via Amazon S3 and backed by the Cloudfront CDN service to cache them at different edge locations. The Google Analytics code has been present for several years.

I would suggest that you try using the latest Chrome and Firefox browsers to see if the problem persists. If it does, I would modify your DNS settings from the default that your ISP provides to either 8.8.8.8 (Google Public DNS) or 206.67.222.222 (OpenDNS). Give that a try and if you still continue to have problems, submit a ticket to the CM team and feel free to reference that I helped you in the forums. http://support.Groundspeak.com/index.php?pg=request

July 17, 2015

I've requested a shunt to avoid ATT, Cogent and GTT on your CIDR. This should be active now, so please let me know if your experience has improved on your next attempt at browsing the site during a previous slow period.

178.82.0.0/16 will now only use NTT, Qwest, XO or Zayo. You can view your outbound route from our infrastructure by visiting http://tracer01.Groundspeak.com

I'm preparing a post so we can start collecting more evidence of the slowdown and identify which peer(s) is responsible for those of you affiliated with UPC.

Hi Justin

I've got all IP-Blocks of the Swiss Cablecom ISP here - a total of 63 (!) ranges registered at RIPE with netname CABLECOMMAIN-NET.

Since I don't want to blow up this thread, shall I send this to you by mail?

Greetings

Ralf

Wow... it's 17:53 and everything's quite fast - didn't have this for weeks. Will keep monitoring...

Good stuff!

I suspect the issue is related to the work being done by GTT represented in this article: http://blog.streamingmedia.com/2015/06/isps-not-causing-network-slowdowns.html

Our ISP's peering technology is failing to dynamically prioritize the optimal route, so in this instance we are manually avoiding ATT, Cogent and GTT. It's quite cumbersome to get these shunts in place, but I'll continue to do so as necessary.

5.7k · July 17, 2015

The Google Analytics code has been present for several years.

While not usually a problem on this site, there ARE times when the "Waiting for..." in the lower left corner indicates that it is not geocaching.com that is holding up the show, but rather, a 3rd party site is creating the issue..

Part of the way that you can help in avoiding this is organizing web pages such that all of your own primary content will be loaded before any 3rd party content that may, for whatever reason, have severe latency issues. There have been times where even the google analytics site has been so slow that I've relegated it to 127.0.0.1 in my hosts file just to get pages to load in a timely fashion. Since the analytics redesign, google isn't nearly the sort of problem it once was, but it can still cause issues, and is only one of many sites that web designers seem to have to 'preload' before their content is completed.

July 18, 2015

The Google Analytics code has been present for several years.
While not usually a problem on this site, there ARE times when the "Waiting for..." in the lower left corner indicates that it is not geocaching.com that is holding up the show, but rather, a 3rd party site is creating the issue..

Part of the way that you can help in avoiding this is organizing web pages such that all of your own primary content will be loaded before any 3rd party content that may, for whatever reason, have severe latency issues. There have been times where even the google analytics site has been so slow that I've relegated it to 127.0.0.1 in my hosts file just to get pages to load in a timely fashion. Since the analytics redesign, google isn't nearly the sort of problem it once was, but it can still cause issues, and is only one of many sites that web designers seem to have to 'preload' before their content is completed.

I'm not a web developer, but there might be some pagespeed prioritization tasks beneficial to the site. Waterfalls show Google Analytics content loading fairly late in the process from my observation, but perhaps it can be deferred until all content is loaded. Thanks for bringing this up, I'll share it with the appropriate team.

5.7k · July 24, 2015

I was going to take a close look at the html for the main gc.com page and a cache page, but (of course) hit the server at the precise time it decided to go for a Friday afternoon beer break >> http://forums.Groundspeak.com/GC/index.php?showtopic=333761

Anyway, it's up again now, so ...

Main Page:

I liked the resource you pointed to in your post. It talks about css and deferred Java timing. Of course, those are both employed as resource calls in the first two real lines of code at https://www.geocaching.com/ ! However, that isn't what we were talking about. 3rd party content on the main page isn't too bad at all, with googletagservices and google-analytics, along with a couple of quantserve.com and w3.org items. Still, optimization of their location on the page is always welcome.

Cache Page:

Well nuts .. stalling at geocaching.com again.

{wait wait wait}

Up again.

First thing on cache page is lots of js, and some css.

But third party here, again, is googletagservices, google-analytics, w3.org, quantserve.com, and of course google.com/maps or whatever mapping system winds up being chosen.

So as such things go, 3rd party issues shouldn't be much of an issue here, which is good. As noted, most of google's older problems are water under the bridge now, though there are still the possible issues with any of these external resources. As speed goes, all of the js on cache pages probably makes a difference.

July 28, 2015

Hello, I am also from Germany and in the evening nothing works for me. Not only on the Website I have this problem, it won´t work on apps further.

So, I gave my friend my password to log for me, because he has no problems, but he still can´t do it with my account.

Maybe there is something with specific accounts...

Flops

August 4, 2015

i also have Problems since some weeks with GC.com website in switzerland. i cannot see the pictures anymore from a cache description(http://www.geocaching.com/geocache/GC5W72Y_back-to-school), just getting an error. how should i solve a riddle like that?! this is with all caches with downloadable content.

-----------------------

Version 44.0.2403.125 m

Google Chrome ist auf dem neuesten Stand.

---------------------

Diese Webseite ist nicht verfügbar.

ERR_CONNECTION_TIMED_OUT

Neu ladenDetails ausblenden

Google Chrome konnte die Webseite nicht laden, weil d1u1p2xjjiahg3.cloudfront.net zu lange zum Antworten benötigt. Möglicherweise ist die Website inaktiv oder es gibt Probleme mit Ihrer Internetverbindung.

----------------------

PS C:\> tracert www.geocaching.com

Routenverfolgung zu www.geocaching.com [63.251.163.200] über maximal 30 Abschnitte:

1 <1 ms <1 ms <1 ms router[xxx]

2 5 ms 9 ms 9 ms 217-162-204-1.dynamic.hispeed.ch [xxx]

3 8 ms 8 ms 7 ms xxx.static.cablecom.ch [217.168.54.125]

4 129 ms 130 ms 126 ms 84.116.200.237

5 130 ms 128 ms 127 ms 84.116.138.141

6 29 ms 30 ms 31 ms 84-116-130-57.aorta.net [84.116.130.57]

7 129 ms 129 ms 129 ms us-was03a-rd1-xe-0-3-0.aorta.net [84.116.130.66]

8 128 ms 129 ms 127 ms nl-ams04a-ri2-xe-9-2-0.aorta.net [84.116.130.174]

9 201 ms 129 ms 128 ms dcp-brdr-03.inet.qwest.net [63.235.40.105]

10 239 ms 228 ms 227 ms sea-edge-13.inet.qwest.net [67.14.41.66]

11 206 ms 203 ms 205 ms 63-235-80-54.dia.static.qwest.net [63.235.80.54]

12 193 ms 193 ms 193 ms border8.po2-40g-bbnet2.sef.pnap.net [63.251.160.82]

13 192 ms 192 ms 193 ms www.geocaching.com [63.251.163.200]

Ablaufverfolgung beendet.

PS C:\>

---------------------

and the website goes very slow after 20h local time, take 2min to load the page.

please fix that!

Edited August 4, 2015 by Lukkar

August 7, 2015

i also have Problems since some weeks with GC.com website in switzerland. i cannot see the pictures anymore from a cache description(http://www.geocaching.com/geocache/GC5W72Y_back-to-school), just getting an error. how should i solve a riddle like that?! this is with all caches with downloadable content.

-----------------------

Version 44.0.2403.125 m

Google Chrome ist auf dem neuesten Stand.

---------------------

Diese Webseite ist nicht verfügbar.

ERR_CONNECTION_TIMED_OUT

Neu ladenDetails ausblenden

Google Chrome konnte die Webseite nicht laden, weil d1u1p2xjjiahg3.cloudfront.net zu lange zum Antworten benötigt. Möglicherweise ist die Website inaktiv oder es gibt Probleme mit Ihrer Internetverbindung.

----------------------

PS C:\> tracert www.geocaching.com

Routenverfolgung zu www.geocaching.com [63.251.163.200] über maximal 30 Abschnitte:

1 <1 ms <1 ms <1 ms router[xxx]

2 5 ms 9 ms 9 ms 217-162-204-1.dynamic.hispeed.ch [xxx]

3 8 ms 8 ms 7 ms xxx.static.cablecom.ch [217.168.54.125]

4 129 ms 130 ms 126 ms 84.116.200.237

5 130 ms 128 ms 127 ms 84.116.138.141

6 29 ms 30 ms 31 ms 84-116-130-57.aorta.net [84.116.130.57]

7 129 ms 129 ms 129 ms us-was03a-rd1-xe-0-3-0.aorta.net [84.116.130.66]

8 128 ms 129 ms 127 ms nl-ams04a-ri2-xe-9-2-0.aorta.net [84.116.130.174]

9 201 ms 129 ms 128 ms dcp-brdr-03.inet.qwest.net [63.235.40.105]

10 239 ms 228 ms 227 ms sea-edge-13.inet.qwest.net [67.14.41.66]

11 206 ms 203 ms 205 ms 63-235-80-54.dia.static.qwest.net [63.235.80.54]

12 193 ms 193 ms 193 ms border8.po2-40g-bbnet2.sef.pnap.net [63.251.160.82]

13 192 ms 192 ms 193 ms www.geocaching.com [63.251.163.200]

Ablaufverfolgung beendet.

PS C:\>

---------------------

and the website goes very slow after 20h local time, take 2min to load the page.

please fix that!

I've submitted your CIDR (217.162.128.0/17) for the work around to avoid GTT on the route from our infrastructure back to your client. Hopefully this will be in place in time to test later today.

August 9, 2015

Does not work, still endless loading pics. this WE i was on 3200m and was using my phone to load a pic in cgeo and this was working.

August 10, 2015

Does not work, still endless loading pics. this WE i was on 3200m and was using my phone to load a pic in cgeo and this was working.

That's a different issue than what the others in the thread have experienced. Does this occur at all times during the day or is it isolated to a certain window? What is 3200m?

6.8k · August 10, 2015

Does this occur at all times during the day or is it isolated to a certain window? What is 3200m?

I'd say 3200 is the altitude above sea level.

Today I experienced problems with photos in the morning, some hours later when I tried again and now also in the evening.

5k · August 10, 2015

[...] What is 3200m?

An elevation given in meters. :rolleyes:

Hans

1.3k · August 10, 2015

I experienced problems with photos

gc.com slowness shouldn't affect this since the photos are now hosted by a third party, no?

6.8k · August 10, 2015

I experienced problems with photos

gc.com slowness shouldn't affect this since the photos are now hosted by a third party, no?

I do not know - somehow the behaviour was strange and not like when a hosting site is not reachable or slow to respond.

August 10, 2015

I experienced problems with photos

gc.com slowness shouldn't affect this since the photos are now hosted by a third party, no?

Yes, that cloudfront URI is the caching service we use in front of the Amazon S3 buckets that host the images. His ISP has been having issues with GTT interchange bandwidth, so it's possible access to those endpoints is affected also.

August 10, 2015

[...] What is 3200m?

An elevation given in meters.

Hans

That was the obvious answer, but "on 3200m" made me question if it was some cellular provider that I wasn't familiar with. Hence, why I asked for clarification.

6.8k · August 10, 2015

That was the obvious answer, but "on 3200m" made me question if it was some cellular provider that I wasn't familiar with. Hence, why I asked for clarification.

I guess the on comes from translating from German language.

August 11, 2015

correct the problem still persists. only with my cellphone and far away from home on moount "titlis" it was possible to see the pictures.

with this, its not possible to solve mysteries..

August 11, 2015

ah mom..right now, it works.

gc.com website slow

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation