We are running a custom theme based on zen. We installed CDN/core patch and configured for origin pull & far future expiration. The CDN is CloudFront and we are not using a CNAME in DNS.

I used www.WebPagetest.org to see how the site was loading. I found that many of our images are loading from the origin website instead of the CDN. I tracked down one of the images as an example for this issue. WebPagetest.org shows the url being accessed as: http://www.raystedman.org/sites/all/themes/raystedman/images/rss26x26.png which is the origin site. This image is a RSS symbol which we display when we have a RSS feed available. The "a" tag for this is created in template.php where the image is referenced as: 

   //create rss link for landing nodes if we have a podcast available
  $landing_rss = '';
  if($node->field_podcast[0]['value']) {
    $landing_rss .= '<a class="taxonomy-feed-icons" href="/podcast/';
    $landing_rss .= $node->field_podcast[0]['value'] . '">';
    $landing_rss .= '<img height="26" width="26" title="RSS Feed" ';
    $landing_rss .= 'alt="RSS Feed -- ' . $title . '" ';
    $landing_rss .= 'src="/sites/all/themes/raystedman/images/rss26x26.png"/></a>';
  }
  $vars['landing_rss'] = $landing_rss;

It seems that this rss image should pull through the CDN -- yet it is not. I white listed raystedman/images/* but this did not help. I look forward to having most (if not all!) of our content on the CDN.

Thanks for this module Wim! Greg

Comments

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Assigned: Unassigned » wim leers
Category: bug » support
Status: Active » Postponed (maintainer needs more info)

Before I can help you, you need to tell me if you did apply the CDN core patch for Drupal 6.

Greg Sims’s picture

Greg Sims commented
Status: Postponed (maintainer needs more info) » Active

The core patch is applied.

Greg Sims’s picture

Greg Sims commented
Assigned: wim leers » Unassigned
Category: support » bug

Here is some additional data for this issue:

http://www.webpagetest.org/result/120430_0F_45X6M/1/details/

If you look under "Performance Review", the report is showing problems with cookies. This seems to be counter to your statement in the README, "If you just use the CDN's URL (e.g. myaccount.cdn.com), all cookie issues are avoided automatically". Please recall that we are Not using a CNAME as I mentioned in #1. We are only using cookie function that is distributed with the base D6.

I hope there is additional detail in the report I posted here will help resolve this issue. Please let me know if you need additional information Wim.

Greg

PS. I'm sorry I was not clear about applying the core patch initially.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Component: Origin Pull mode » Module
Assigned: Unassigned » wim leers
Category: bug » support
Status: Active » Fixed

When the core patch is applied (and that's good!), every file URL must be created using file_create_url(). Only then, it gets rewritten. Node content is automatically parsed for URLs and these are then also passed through this function. But every file URL in the theme layer is up to the theme developer to pass through that function as well.

I had to make the necessary changes to core's Garland theme as well:


Index: themes/garland/template.php
===================================================================
RCS file: /cvs/drupal/drupal/themes/garland/template.php,v
retrieving revision 1.16.2.3
diff -u -F '^f' -r1.16.2.3 template.php
--- themes/garland/template.php	11 May 2010 09:41:22 -0000	1.16.2.3
+++ themes/garland/template.php	22 Aug 2010 17:03:40 -0000
@@ -96,9 +96,9 @@ function phptemplate_node_submitted($nod
 function phptemplate_get_ie_styles() {
   global $language;
 
-  $iecss = '<link type="text/css" rel="stylesheet" media="all" href="'. base_path() . path_to_theme() .'/fix-ie.css" />';
+  $iecss = '<link type="text/css" rel="stylesheet" media="all" href="'. file_create_url(path_to_theme() .'/fix-ie.css') . ' />';
   if ($language->direction == LANGUAGE_RTL) {
-    $iecss .= '<style type="text/css" media="all">@import "'. base_path() . path_to_theme() .'/fix-ie-rtl.css";</style>';
+    $iecss .= '<style type="text/css" media="all">@import "'. file_create_url(path_to_theme() .'/fix-ie-rtl.css') . '";</style>';
   }
 
   return $iecss;

You'll have to make similar changes.

Greg Sims’s picture

Greg Sims commented

Thanks Wim! I really appreciate your help, Greg

Greg Sims’s picture

Greg Sims commented

I decided to use CSS to display these images instead of the technique you described above. This is more consistent with the balance of the website. The changes are now in place and the results are great! Our web server is located in Dallas, TX. When I started working on this our "first view" page load time for Singapore was almost 5 seconds. Now we are seeing 2.1 seconds consistently:

http://www.webpagetest.org/result/120501_Z2_46826/

The resulting experence for our users is wonderful -- I can't image putting up with a 5 second page load time for long!

The only module we added to achieve these results is CDN, the core patch, far future expiration, origin pull and the default module settings. This is quite a testamony to your efforts Wim!!

I can't thank you enough, Greg

PS. I'm trying to figure out how to place this issue into "Gold Star" status. I guess "fixed" will need to do.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

"fixed" will have to do indeed. Thank you very much for writing #6 — it's great to get some positive feedback once in a while instead of just bug reports, support requests and complaints :)

Greg Sims’s picture

Greg Sims commented

I do have another question Wim -- I hesitate given your comment in #7 above but I can't resist the temptation of going a bit further with your CDN module!

When I review the data posted by url in #6 above, I notice that almost 50% of the page load time is as a result of fetching the html of the page from our server in Dallas -- item 1 in the waterfall. Is it possible to continue using origin pull and place some of our html files on the CDN? I know the user would have to use our domain name to access the site for the first page. What if some of the html urls in the page they fetch are encoded with the domain name of the CDN as well?

The urls for our landing pages are coded into the menus at the top of each page. It would be great to get these landing pages into the CDN. Let's take a section of our site as an example. The landing page for Ephesians is located at /new-testament/ephesians as you can see in the test run of #6 above. Let's focus on just the New Testament portion of the site for a moment. All of the landing pages of this section are located at /new-testament/*. Below these landing pages are the "leaf" pages of the site at /new-testment/*/*. For example, there are 60+ leaf pages for Ephesians at /new-testament/ephesians/* that we do Not want to place on the CDN -- for cost reasons.

Is it possible to include the html pages at /new-testment/* (all the new testament landing pages) and excluded the pages at /new-testament/*/* (all the new-testament leaf pages)? This would be a great setup for our users -- without incurring large CDN bills for us (we have 1000s of leaf pages). Our leaf pages are large pieces of text that take a long time to read/listen to. If we can make surfing through the site landing pages quick, this will be a great navigation aid for our users.

Thanks again, Greg

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

What you are describing is possible. But don't forget that whatever HTML is cached on the CDN will be served to *all* visitors, so no customization is possible.

The solution to that is Edge Side Includes, which only some fairly expensive CDNs support (Varnish supports this too) — also see http://drupal.org/project/esi. This will (or should) become trivial in D8: http://buytaert.net/the-future-is-a-restful-drupal.

It *is* possible to do this in D7, with CloudFront, with some limitations. However, that's currently not easy. I can't give you a set of steps to follow, because it's not trivial, nor easy. In the future, it should be easy :)

P.S.: serving HTML from the CDN should be *very* cheap. It's not HTML that yields large CDN bills, it's the other resources. So that's one thing I definitely wouldn't worry about.

P.P.S.: Would you mind posting your positive experience at http://wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit? :) I'd appreciate it!

Greg Sims’s picture

Greg Sims commented

Hey Wim,

I read up on esi and other topics in #9. I've been reading your code and it seems that "Anonymous CDN" might be possible -- avoiding the issues esi is addressing. Would it be possible to use the existing UI and allow content="text/html" to be loaded onto the CDN for anonymous users only? In this case the user would select the additional content using the white/black list and set Far future expiration to allow immediate content update as needed. Perhaps it would be best to add an "Anonymous CDN" select bullet in the UI that is defaults to off (the function that exists today).

This would allow the user to place additional content onto the CDN. In my case, I believe this will improve page load performance by up to 25% as user locations become further from our server.

Does this have a chance of working from a design perspective?

Thanks for dreaming with me, Greg

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

In theory it can work, but you'll have to do some careful testing. I don't have time to help you with this. So: experiment and report back! (Preferably in a new issue, since this is getting very much off-topic.)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.