How to specify alternate URL for static files (to serve them via a CDN instead of direct from our se

We don't see application of this, as all your content will be located on 1 server, so there won't be any impact on performance.

All our js and css are minified, so once loaded at user browser they won't be retrieved again from the server.

The same with images that are stored in user browser's cache.

If you'll have another server for such purposes, their will be application of this method, giving you less requests to your server and all content will be distributed between different servers.

In current situation, it's almost useless

Hey Stas, sorry let me explain a little better. :-)

Yes, there is indeed another server for the static stuff. It's not just a server actually, but a big network of HUGE servers optimized to serve static content fast.

They automatically download files from our server once and serve up all future requests from their network. We use MaxCDN for this: http://www.maxcdn.com/ - but same can be done with Amazon S3.

I know, we serve millions of pageviews, so we optimize stuff hard, we have to. :-)

Here's how it works: Via the method I explained - it will accomplish this goal: only a SINGLE request is served from my web server (in Virginia), and ALL the other requests (css, js, img, whatever files) are served via CDN company that has HUGE servers all over the world. When the URL request is made to our MaxCDN server URL, this happens: - if they have not yet served this particular file before, their server instantly retrieves it from our server and they serve it up to our visitor- on all subsequent requests to this URL, their global network of servers serves this file directly, NOT hitting my server (for as long as I have my MaxCDN account configured to cache the files).

So with this method, only A SINGLE request will be served from my server. ALL of the other requests (like 80) will be served from the CDN servers. That means is a HUGE improvement in speed for the visitors, and a huge load off my server. :-)

Here's a visual for you, take a look:

1.) our optimized website http://BlogSuccessJournal.comlist of all files loaded and from where, via Pingdom Tools: http://tools.pingdom.com/fpt/#!/HX1uyfyqP/http://blogsuccessjournal.com/ - in this case, only 2 files are direct hits to my server for very visitor (source: blogsuccessjournal.com) 2.) our Ask Dan & Jennifer forums - http://forums.askdanandjennifer.com/- list of all files loaded and from where, via Pingdom Tools: http://tools.pingdom.com/fpt/#!/EyvreyW8z/http://forums.askdanandjennifer.com/ - in this case, over 75 files are direct hits to my server for every visitor (source: fourms.askdanandjennifer.com) All we have to do is provide that alternate URL via a config file, so the UseResponse pages are created with that URL. the rest is done automatically by the CDN service. So that's my question... is this fairly straightforward to do - provide an alternate URL for the image/css/js file URL calls, different than the main URL of the site that's used by default. :-) Thanks!Dan

ugh, i've edited this response i made 10 times, still can't get hte formatting to look right, so please ignore the messed up formatting. the content is good. :-)

thanks.

Now I see what you mean.. Currently it's not possible with built-in functionality and we don't have plans on that in the near future, but will consider it for the middle of this year.

Great, thanks Stas. :-)

The setting for it could be as simple as a text entry box like this to enter the alternate URL - http://www.screencast.com/t/1tSqv4uQP - or heck, even i could enter it in a config file, whatever's easier for you.

I know you guys are crazy busy, but this would be a big thing for us performance wise.

Thank you!!Dan

I totally understand that it's a great thing to have in performance, but our system is much more complex than Wordpress.

If we are to make it, it would be done within system configuration, but not settings, as whole system is based on assets locations. No promises, but we'll get back to that question in Summer. Hope we'll have time :)

Hey Stas! any chance this can make it into 2.3? :-)

Thanks!!

Dan

Hi Dan,

I think we limit features for 2.3 a bit a try to release it next week, but definitely not planned for upcoming release

Hey Stas! just checking if something like this will be included in 3.0. :-)

Thanks!

Hi Dan,

We'll see what we can do, but no plans for 3.0 release. Though it will be definitely included in the list when it's time.. closer to 3.2 release

Hey Dan, Stas,

We've been struggling with this issue as well - I thought I'd share our solution, in case its helpful to either of you.

To keep things simple, we're serving the site through Amazon's CloudFront CDN, which is the same "pull type" setup that you've described. For the sake of this discussion, our UseResponse setup is hosted at http://ur.example.com, and the CloudFront CDN is at http://cdn-ur.example.com (via a CNAME record that points to their service)

I then added the following to the .htaccess file that resides in the UR root, which allows us to include arbitrary code at the beginning of every script:

1. php_value auto_prepend_file "cdn-prepend.php"

The prepended file simply contains the following:

1. if ($_SERVER['HTTP_USER_AGENT'] == 'Amazon CloudFront') {
2. function cdn_ob_callback($output) {
3. return str_replace('//ur.example.com','//ur-cdn.example.com',$output);
4. }
5. ob_start('cdn_ob_callback');
6. }

This ends up being a pretty straightforward solution: From UseResponse's perspective, nothing has changed - it's serving up requests normally. At the very last moment, all of the references to the server's content are replaced with pointers to the CDN instead.

Our CloudFront distribution is configured to use the user's individualized login cookie to calculate caches, so each user will get the dynamic content that they'd expect. We've added additional behaviors that don't forward the cookies when accessing images, scripts, etc, so that they'll be fully cached and served from the edge for everyone.

This tidily solves almost all of my problems -- there's just one thing left: Stas, is there any way to change the default cookie domain? For this to work, we need to make the cookies available to all of our subdomains. (My temporary solution was to hardcode the domain into line 78 of the IntegrationController.php script, but that's a little hacky for my tastes.)

Timothy,

Thank you for sharing the solution. In 3.x release we'll have such option available to boost system performance with CDN.

As for cookie domains.. You need to put such instruction inside application/configs/application.inc

1. $config['resources']['session']['cookie_domain'] = "domain.com";