Jump to content

gc.com website slow


holbi

Recommended Posts

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]

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment

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

Link to comment

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

Link to comment

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.

Link to comment

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

Link to comment

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.

 

ldUylNU.jpg

Edited by THE_Chris
Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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/

Link to comment

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)

Link to comment

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

Link to comment

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

Link to comment

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

Link to comment

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

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.

Link to comment
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.

Link to comment
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.

Link to comment

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.

Link to comment

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

Link to comment

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

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.

Link to comment

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?

Link to comment
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.

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