FYI: googleapis.com is down and is adverse to TS

[DelJo63]

We all get terrible response times waiting for "ajax.googleapis.com" to timeout today 2015-06-25.

C:\Users\Jeff>ping ajax.googleapis.com

Pinging googleapis.l.google.com [216.58.216.170] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.​

This is a google issue, not Techspot.com

 

[Julio Franco]

Still going on? Didn't have the problem here but we use Google's CDN for those files assuming they won't ever have an issue, among other reasons.

 

[DelJo63]

Yes, still a problem @ 2015-06-26:07.12

C:\Users\Jeff>ping -t ajax.googleapis.com
Pinging googleapis.l.google.com [216.58.216.138] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.

 

[DelJo63]

Btw: translate.googleapis.com fails also as that's a subdomain of googleapis.com

Still going on? Didn't have the problem here but we use Google's CDN for those files assuming they won't ever have an issue, among other reasons.

hmm; perhaps but not exclusively else we would not be stalling on the ajax.googleapis.com

 

[DelJo63]

@Julio Franco
Just been reading an article re CDNs http://weblogs.asp.net/jongalloway/using-cdn-hosted-jquery-with-a-local-fall-back-copy
which notes

What about outages?

There’s one potential downside to outsourcing anything: potential outages. You might be tempted to brush that aside with “Hey, it’s run on a world-class CDN...” but it can and has happened. If your depends on jQuery, any CDN outages are essentially another outage for your site.

The outage scenario is mitigated by the fact that browsers should be using cached copies rather than contacting the CDN in most cases, but that doesn’t always work out in practice.
The simple solution: Use a fallback when the CDN’s unreachable

Here’s a general pattern for AJAX includes with a fallback: include the CDN reference, test for a key object, and if it’s undefined you can write out a reference to a copy that you’re hosting. Here’s how that looks when using the Microsoft hosted jQuery libraries with an ASP.NET MVC application:

<script type="text/javascript" src="http://ajax.microsoft.com/ajax/jquery/jquery-1.3.2.min.js"></script>
<script type="text/javascript">
if (typeof jQuery == 'undefined')
{
  document.write(unescape("%3Cscript src='/Scripts/jquery-1.3.2.min.js' type='text/javascript'%3E%3C/script%3E"));
}
</script>

Of course, the privately hosted copy invocation is very specific to the api being invoked, but you get the idea.

 

[DelJo63]

@Julio Franco you might like to see this analysis

 

[Julio Franco]

I've switched to a different CDN on the forums until Google resolves the problem. Quick question, was the slowdown problem (due to ajax.googleapis.com not resolving) only noticeable on the main site, the forum, or both?

Thanks!

 

[DelJo63]

forum->Most Recent Topics.

the DNS resolves correctly, but the access timesout, hence the stall.

 

[Julio Franco]

Should be solved now because we switched over to a combination of our own CDN and Microsoft's.

My question was because the CDN fallback (as suggested above) was already part of the forum configuration but it's not working as intended, which is also mentioned in some dev discussion boards like stackoverflow.

 

[DelJo63]

Hmm; doesn't stall, but LOOPS read,write google-analytics

 

[DelJo63]

Oops; loop was my server configuration interceding, sorry

 

[DelJo63]

Hmm, I'm still seeing r/w loops on analytics. suggest commenting that reference out until google comes online properly

 

[DelJo63]

Situation resolved 2015-06-26:12.07. Googleapis.com is online again

 

[DelJo63]

A little history on this issue.

when this all started ajax.googleapis.com was located at 216.58.216.138

Today it's at
nslookup ajax.googleapis.com

Non-authoritative answer:
Server: dns-cac-lb-01.rr.com
Address: 209.18.47.61
Name: googleapis.l.google.com
Addresses: 2607:f8b0:400e:c04::5f
74.125.25.95 <<<
Aliases: ajax.googleapis.com​

Tracert ajax.googleapis.com now shows

Tracing route to googleapis.l.google.com [74.125.28.95]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms localrouter [192.168.0.1]
2 8 ms 8 ms 9 ms cpe-75-85-0-1.socal.res.rr.com [75.85.0.1]
3 8 ms 8 ms 12 ms tge0-9-0-23.wlvgcabn02h.socal.rr.com [24.30.172.141]
4 10 ms 11 ms 11 ms agg22.vnnycajz02r.socal.rr.com [72.129.14.168]
5 15 ms 15 ms 15 ms agg29.tustcaft01r.socal.rr.com [72.129.13.2]
6 15 ms 15 ms 15 ms bu-ether16.tustca4200w-bcr00.tbone.rr.com [66.109.6.64]
7 12 ms 21 ms 12 ms 0.ae3.pr1.lax10.tbone.rr.com [107.14.19.56]
8 14 ms 11 ms 18 ms 216.156.65.225.ptr.us.xo.net [216.156.65.225]
9 14 ms 13 ms 14 ms 216.156.65.102.ptr.us.xo.net [216.156.65.102]
10 12 ms 21 ms 12 ms 64.233.174.238
11 14 ms 12 ms 15 ms 64.233.175.150
12 42 ms 40 ms 42 ms 209.85.143.150
13 42 ms 40 ms 40 ms 209.85.143.127
14 * * * Request timed out.
15 41 ms 41 ms 41 ms pc-in-f95.1e100.net [74.125.28.95]​

now NODE#9 is ~ the last node seen yesterday during the failure.

So who is 64.233.174.238

NetRange: 64.233.160.0 - 64.233.191.255
CIDR: 64.233.160.0/19
NetName: GOOGLE
NetHandle: NET-64-233-160-0-1
Parent: NET64 (NET-64-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Google Inc. (GOGL)
RegDate: 2003-08-18
Updated: 2012-02-24
Ref: http://whois.arin.net/rest/net/NET-64-233-160-0-1
OrgName: Google Inc.
OrgId: GOGL
Address: 1600 Amphitheatre Parkway
City: Mountain View
StateProv: CA
PostalCode: 94043
Country: US​

So the failure was entirely within GOOGLE - - the guys who are suppose to know how. It's interesting to see that these addresses

64.233.174.238, 64.233.175.150, 209.85.143.150, 209.85.143.127​

do not have corresponding DNS names - - it's legit (as it's internal to google) but kind of sad too.