Hi Meteorers,
I am running www.SkyRooms.io and users can now upload a profile photo. It sends the file to my S3 bucket. Great.
Then I have CloudFront to pull and host on a CDN.
It’s REALLY slow. It takes about 5 minutes for the file to pull from S3 in to CloudFront. What? This is blowing my mind. Am I missing something here? When I google “S3 CloudFront slow” there’s pages of results with no answers.
Any one else have some suggestions? At this point I’m thinking about moving another platform 
How big are your files? “Then I have CloudFront to pull and host on a CDN.” I don’t know if I understand this, you are using two CDNs? Or just CloudFront? What is your request rate on S3? Are you approaching the soft limit AWS imposes on S3? did you check your CloudWatch metrics? What does your CloudFront configuration look like?
Edit: What region are you in? What region is your client in? What region is your S3 bucket in? What’s your TTL on your CloudFront objects? Are you using Transfer Acceleration? TA is often slower depending on where you are pulling from.
So I put in a question at Stack Overflow and got an answer! This is a very highly ASKED question based on my Googling, but with no real answer.
So here it is with a solution!
Uploading to the S3 bucket is very quick. Fantastic.
Now, when you use CloudFront to try and view that image, it’ll pull from the S3 bucket. This is supposed to be instantaneous. For what ever reason, it takes FIVE MINUTES by default. What’s the story here?
So, after trying to access a file with a 404 error on CloudFront, CloudFront will cache that result for 5 minutes by default. It’s very strange the after a successful upload, requesting that file does indeed return a 404. After 5 minutes, the file shows up.
So you can change the 404 timeout on CloudFlare caching with this: http://stackoverflow.com/questions/35534233/amazon-cloudfront-latency/35541525#35541525
Your first result still shows a 404, but the next attempt shows the image. It’s a strange problem with Meteor, because of the reactive data.
My Meteor Solution is:
Priming the cache. Before I update the collection pointer to the file, I’m going to send an AJAX request to the CloudFront and make sure it pulls back a file. If it does, then update the collection. Once that collection is updated, any data on the screen should be OK to pull back a real file.
Good luck to future AWS S3 and CloudFronters. It wasn’t easy.
**PreCaching the Image works by calling it via Ajax real quick 
**
We’ve needed no such tricks to get things working right with CF. Maybe check your configuration.
I can confirm I faced this 5 minute thingy and it was quite frustrating and I had moved out of CF.
I didn’t notice the 5min delay because of the way I wrote my service. We needed image resizing on demand and the usual services that do this are pretty costly. So I wrote a simple resizer that pulls the src image from S3 and will resize and serve the image.
I then added this app as the origin in CF and also set CF to cache the query string. Now the first time an img is requested, it will get served from S3 and cached. Including the resized versions.
I don’t know, maybe because of this extra redirection, we never see a delay even for images never loaded before. And its running on a $5 DO droplet with no issues.
Hi @SkyRooms: I know this is a super old thread, but I am wondering if this kind of “trick” is still required nowadays? My plan is to setup a CDN in front of my Meteor app that serves files from a) the public folder, b) an S3 bucket, and maybe c) Meteor’s static CSS and JS. Galaxy is not involved in my case, I’m hosting my app on EC2 using mup.
Hey I for sure solved the issue. I use my own file uploader to push files out of Meteor all together. Do NOT use the /public folder, that’s for static resources that are distributed with your app package, think on a mobile device for example.
So what ya wanna do is have cdn.yourdomain.com and have files upload through meteor upload to /var/www/myapp/_processing for example, then have a cron job to compress and push files to /var/www/cdn.myapp/www/ where they can be referenced by your meteor application.
You can choose to use some other storage solution but they’re all really expensive IMO. This is cheap, dirty, and it works.
Thanks for your response! In the meantime, I have switched my app to CloudFront as well, but did not notice any delays. I am using it in combination with slingshot to upload to S3 directly.