MyBB Internal: One or more warnings occured. Please contact your administrator for assistance.
WebPagetest Forums - Is it possible to run ENTIRE site (not just images, etc) via CDN?

WebPagetest Forums

Full Version: Is it possible to run ENTIRE site (not just images, etc) via CDN?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7
Looks like it is considering your base HTML as static since you now allow that to be cached by the CDN and the CDN is sending down a "time left" from when they cached it. In the F case the HTML only has a few seconds left but in the A case it has expired and the remaining time is zero (so I consider it dynamic).

It's an edge case that you really shouldn't worry about :-)
That would make sense, however, for some reason when I re-run the "F" test, I again receive "F", and it keeps showing "2 seconds" no matter when I run the test.

It's not an issue for me, I only wanted to let you know so you know about it. It's likely something no one else is going to experience the same, so likely not worth investigating. :-)
Marvin, that seems to work really well !

I've been wanting to do this too eventually in the same way. You even selected the same anycast DNS-provider and CDN (EdgeCast ?) I wanted to use.

And I was wondering how do you tell your CDN not to cache the HTML for logged in users ?

It looks to me like you are telling the browser to always revalidate for pages and you have the CDN setup so that when the bbloggedin cookie is set to 1 the browser will always get a file from the origin server.

Is that correct ?

I think many other sites would use atleast an other domain for static files, because the cookie would prevent the static files to be cached at the CDN.

But the number of static files on your site is really low and should be cached before login so it should be fine :-)
[Image: 6735505565_7bdb02e24b_b.jpg]

The above screenshot is of a 1st and 2nd test run using the Sydney, AU test location. It illustrates the issue with the short DNS TTL of my CDN (or all CDNs?). In this case, the long DNS lookup time almost doubles the load time of my home page. I don't think there is anything I can do, and I don't think CDN providers can change the TTL. :-(
I know the DNS looks bad, but I think you have to remember that the test location in the AU is inside a Hosting provider network. The information about the CDN-nameservers isn't generally cached, that would be different on a access provider network.

The Edgecast nameservers have a TTL of 2 days, the CNAME has a TTL of 1 hour.

If you do 2 tests, with a little over an hour between them, you should see a more realistic view of what a user on an access provider network would see.
The CNAME is probably your pain point. Who are you using for your DNS and do you know if they have a wide server footprint with Anycast for the DNS?

I assume once you get comfortable with running the base page through the CDN you can bump up the CNAME TTL which will help but unless your DNS provider has servers in AU it's probably still going to take a hit every now and then.
Pat, TTL for my www CNAME is currently 86400. I'm using DNS Made Easy (Anycast). But the test results I'm referring to are those where the base html file has been cached on the CDN, so, if my understanding is correct, the CDN sends the file without even needing to check with my server (but I may be incorrect here).

In any case, would the blue line in the waterfalls represent the combined DNS lookup time for both, the 1. CDN and 2. the origin server? Or would the blue line represent just the DNS lookup time for the CDN?

Lennie, thanks for the explanation. It makes me feel a bit better :-), and also I will have to accept that there are certain things beyond my control.
Yes, it is the combined lookup. The browser requests the www and the 'recursive dns server' will usually return both results as one response (so including the IP-address and CNAME information).

A recursive nameserver would need to resolve these things if the cached is completely empty:
- ask for at the root nameservers [>]
- response: delagated to nameservers for .com [>]
- ask for at the .com nameservers
- response: delagated to nameservers of DNS Made Easy
- ask for at the DNS Made Easy nameservers
- response: CNAME of CDN
- ask root nameservers for [>]
- response: delated to nameservers for .net [>]
- ask .net nameservers for [*]
- response: delated to nameservers of CDN [*]
- ask nameservers of CDN for
- response: CNAME and IP-address

At any provider [>] would already be cached. At an access provider, the ones with [*] would probably also already be cached.

I noticed you only specified 4 out of 6 nameservers at your domain registrar, I don't think it matters much but it could have some performance impact some of the time.


Maybe you could try the tests I suggested above ?

I was thinking maybe you should test 3 times:
- first time, maybe nothing is cached and it maybe take a long time to resolve the DNS name
- second time, shortly after. (hopefully the request is send to the same nameserver). It should be fast, because it is already cached.
- third time, a little over an hour later. Only the CDN CNAME TTL should have expired and this is probably the resolve time most users would see.
Lennie, thanks for the explanation. That makes sense that it is a "combined" DNS lookup. Why did I think otherwise? LOL!!!

I'm going to stop agonizing over things I cannot improve. :-)

Here's a good place to test DNS lookup times from various cities simultaneously:!

The first run shows very good times in about 50% of the locations. And perhaps 30% are very very slow. On the second run, most of the "slow" ones are fast. I'll try to test after about 60 minutes.
Lennie, I forgot to comment on the following:

Quote:I noticed you only specified 4 out of 6 nameservers at your domain registrar, I don't think it matters much but it could have some performance impact some of the time.

My registrar allows for only 4 entries :-(

Edit: Hmm, perhaps I can email them about it.
Pages: 1 2 3 4 5 6 7
Reference URL's