I have a web application that requests a lot of media assets in parallel using AJAX. All assets are coming from the same Cloudfront Origin, which is itself directly plugged into an S3 bucket.
I'm seeing requests from Cloudfront with TTFB of the order of seconds. Even more odd, it seems that those requests are basically queued until a previous request has been served:
Those two requests are initiated in parallel, and you can see that it's not Chrome queueing them, but Cloudfront not answering anything to the second (2KB) request until the first request has completed download. This is slowing down my application by a huge margin, and I cannot figure out what is going wrong... I see the same behavior when I check with Safari too.
Here are the two requests details
As you can see, they are also both Hit from cloudfront.
Finally, as it might be relevant, I'm using a lambda function in my Origin's behavior to add the proper Vary headers, to prevent Chrome from using cached requests without the CORS headers that will make subseqeuent CORS request fail (see details here).
Here is my complete Origin's behavior settings:
Any help is appreciated, and please feel free to ask more details if needed! Thanks a lot in advance.
Related
Users are sending requests for me for information, some times this info is personalized, and sometimes it's common to all. When it's common to all I want the CDN to cache the answer. I distinguish between the users by query params.
The problem - The problem is when I want them to stop using the cache, and each to get their personalized content.
I thought that if I'll send the response with cache flag off (max-age = 0) the user's requests won't use the cache, the requests would come to me, and I would give them their personalized answer.
But the CDN in that case doing collapse forwarding and all the users continue getting not personalized answers.
I didn't found a way to disable the collapse forwarding, and I couldn't find a way to continue serving the client personally after they start using the cache.
Any ideas?
I had the same issue and chatting with support (detailed here). It turns out that you can't stop CloudFront from sending non-personalized results just by using the Cache-Control header. Instead you have to have separate "Behaviors" and namely a CachingDisabled behavior for routes where you need personalized responses.
I have AJAX POST requests generated from my webpage, and there may be multiple post requests with the same post data. But the response may vary, and I want to make sure I am not getting cached responses to any of these requests. I need each request to hit the webpage.
Am I right in assuming that responses to POST requests will not be cached?
There is two level of caching will be involved in that process
Browser caching
Server caching
To eliminate first one you have to cheat your browser and add a fake parameter to your ajax request so it will think it's unique each time i.e
www.example.com/api/ajax?123
www.example.com/api/ajax?1234
For server level you have to make sure that no cache been added to your configuration for such link, for example some developer will cache any file ends with .json or service like Cloud Flare it will automatically cache any static content.
My Application is using CDN which is a caching server. Now when I use JMETER for recording the functional flow. Browser doesn't load any CSS,JS or image being cached at CDN server. Removing CDN is alo not good option because I need to judge performance with CDN in place. Please Guide
JMeter records only HTTP requests sent by browser, so if you have already visited this page your browser may already have these resources in its own cache therefore it doesn't send actual requests. If you want these requests to be recorded - you should clear your browsing history and especially delete cache. The procedure differs from browser to browser so check your browser documentation for details or check out How do I clear my web browser's cache, cookies, and history? article.
In general you should not be recording these calls as real browsers download these images, scripts and styles using concurrent thread pool, i.e. one main request followed by parallel requests to get the resources. The same behavior can be set up in JMeter using "Advanced" tab of the HTTP Request sampler (or even better HTTP Request Defaults, this way the setting will be applied to all HTTP Request samplers in scope)
I accepted the Security certificate for CDN server through browser only. And problem was solved.
Server push works by sending js, css, images etc. just after responding to a request, instead of waiting for the client to receive the html, parse it and request the resources, saving a round trip. But pushing js, css, images, fonts etc. for example.com/about when those same files already got downloaded by the client when it fetched example.com a minute ago is a complete waste of bandwidth, because the client already has those files.
Keeping state server-side for each request seems expensive, and that's cannot be how it's done, since HTTP is stateless. Presumably, the client would re-request the html on subsequent visits, to see if anything's changed.
How does the HTTP2-server know what files to push?
There are several techniques for that. The browser can for example reset the streams. Or cache digests can be used.
Here is more information on that:
https://www.shimmercat.com/blog/cache-digests/
Just today some people are having an interesting conversation on cache digests:
https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0371.html
I make asynchronous call for same URL for multiple times, But the response came as sequentially. Please see the attached image, The request has been started only after first request completes, the same happening for subsquent requests.
But If the URL is different the responses are not sequential. Please confirm me if one URL is being requested, wouldn't firefox make another request for same URL?
Necko's cache can only handle one writer per cache entry. So if you make multiple requests for the same URL, the first one will open the cache entry for writing and the later ones will block on the cache entry open until the first one finishes. There's work ongoing to rearchitect the cache to remove this restriction.
Generally browsers will have a limit to how many concurrent requests they will serve to a particular hostname, in the old days this was 2, but most browsers have now raised this. Defining a proxy can also affect these limits in some browsers. Again these are enforced client-side. However it should be more than one in any case. It may be possible that Firebug is also reducing the limit, check about about:config for concurrent configurations.
Are you sure you are not waiting until the callback is executed before launching the next request as given you only have one I suspect this what is really happening?