-
Notifications
You must be signed in to change notification settings - Fork 538
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
default cloudformation config results in low cloudfront caching rate #32
Comments
Thanks for reporting the issue. We are investigating Cloudfront hit-rate improvement by removing 'Accept' header. Please continue to monitor the repo for updates. |
Version 3.0 resolves this issue. |
You do need the @shsenior Removing this in 3.0 breaks the |
I think the best way to solve this would be to provide some way to change the way the CloudFront cache key is generated. We can have a custom function. So for WebP support, I would write a code which generated True or False and use that in the CloudFront key instead of the whole Accept header, which as rightfully mentioned here is going to make the cache hit rate to take a toll. |
I stumbled upon Lambda triggers. I used one at the "Viewer Request" event type, which replaces the accept header to "image/webp" if it is found in the accept header else to "image/jpeg" since they are the only two that we are supporting. |
It seems the default setup that is generated by the cloudformation template for this project includes a default value for the Cloudfront distribution that has this setting: "Cache Based on Selected Request Headers" set to use the "Accept" header. I believe this is set on line 433 in deployment/serverless-image-handler.template:
"ForwardedValues": {
"Headers" : ["Accept"],
"QueryString": "false",
"Cookies": { "Forward": "none" }
},
Wouldn't this result in a much lower Cloudfront cache hit rate and thus more Lambda invocations? Since each browser can use a different Accept value in their request headers each browser version could potentially generate a different version of the same cached image.
Removing this from our Cloudfront distribution made our Cloudfront cache hit rate jump up to 75-80% from under 50% previously, and significantly lowered the number of Lambda invocation and our overall cost.
Unless this Accept header is needed I think it should be removed from the template as it needlessly increases the cost of using this solution.
The text was updated successfully, but these errors were encountered: