Azure Front Door Standard with cache enabled takes long time to respond to POST requests

Question

Azure Front Door Standard with cache enabled takes long time to respond to POST requests

Duy Nguyen 0

We are using Azure Front Door (AFD) in front of a function app that serves as the backend and accepts only POST requests. We notice that when cache is enabled on the Front Door, it makes the app very slow. The performance is only fast when we disable the cache on the Front Door.

It seems that Front Door always checks for data against its cache no matter the method of the requests. Here is the diagram we come up with:

(AFD interactions.png)

User's image The step in red adds a lot of overhead to the Front Door when getting data for POST requests. This step is mentioned in the section “Return cached content” of this article: https://learn.microsoft.com/en-us/azure/frontdoor/front-door-routing-architecture?pivots=front-door-standard-premium.

We have built a sample app to mimic the behavior of our real app so that you can check the performance between Front Doors with cache enabled and cache disabled. You can access the deployment of the sample app at https://sfa-dev-cdne-uis-bgjv5archbaz4.azureedge.net, and the source code at https://github.com/nguyenduy/afd-cache-behavior.git.

In the app, the backend which is an Azure Function App serves only one POST API via route “api/postapi” which returns the current DateTime. The front end interacts with the backend in 4 different ways:

Directly to the function app: The front end calls the API directly through the function app.
Through AFD with cache enabled: The front end calls the API through a Front Door with cache enabled.
Through AFD with cache disabled by a rule set: The front end calls the API through the same Front Door as above, but the request has a request header to signify the Front Door to disable the cache:
Through AFD with cache disabled: The front end calls the API through a Front Door that has cache disabled.

Here is the timing we recorded:

User's image

As you can see from the table above, with cache enabled, the timing is high.

One note here is we recorded the timing using the developer tool of Google Chrome under the Network tab:

User's image

So, our questions are:

Why is AFD with cache enabled very slow when handling POST requests?
Does the cache-checking step of AFD always happen for all request methods?
If question 2 is a yes, why is that true for POST requests? In the documentation about caching of AFD, it says that only GET requests are cacheable. If POST requests cannot be cached, why does AFD still check data in the cache for them?

Quote from the documentation:

User's image

(https://learn.microsoft.com/en-us/azure/frontdoor/front-door-caching?pivots=front-door-standard-premium)

Sai Prasanna Sinde 5,005 Reputation points Microsoft External Staff

2025-03-20T17:40:52.0933333+00:00

Hi @Duy Nguyen

I have initiated a private message. please check it.
Venkat V 1,390 Reputation points Microsoft External Staff

2025-03-21T10:31:31.8933333+00:00

Hi @Duy Nguyen

You can configure the settings below to bypass caching for any POST request that comes to the origin group

Rule Set Configuration

The condition "Request Method = POST" ensures the rule applies only to POST requests, preventing AFD from checking or storing responses in the cache, thus improving response times. "Override Origin Group = Yes" routes POST requests directly to default-origin-group, bypassing other routing rules. "Forwarding Protocol = Match Incoming Request" ensures AFD forwards requests using the same protocol (HTTP/HTTPS) as received, maintaining compatibility with client requests.

I hope this helps to resolve your issue. Please feel free to ask any questions if the solution provided isn't helpful.
Duy Nguyen 0 Reputation points

2025-03-21T13:53:58.1266667+00:00

Hi Venkat V,

Thank you very much for your response!

As mentioned in the original question, we have already addressed this issue by using a rule set to bypass caching on the Front Door. Here is the rule set we are currently using:

However, our main concern is understanding why this workaround is necessary. It feels like we are employing a workaround rather than resolving the root cause of the issue. If caching were functioning as expected, it should not introduce delays for POST requests. Theoretically, since POST requests are not cacheable, caching should not impact their performance.

However, as the timing table from the original question demonstrates, enabling caching consistently results in delays. We would appreciate any insights into why this behavior occurs.

Looking forward to your thoughts.
Venkat V 1,390 Reputation points Microsoft External Staff

2025-03-22T04:25:36.8733333+00:00

Hi @Duy Nguyen

Could you please share the requested details in private chat so that we can connect offline for clarification?
Venkat V 1,390 Reputation points Microsoft External Staff

2025-03-24T07:53:17.5333333+00:00

Hi @Duy Nguyen

I have tested the same scenario in my environment under both conditions, and the results are approximately the same. It is not taking significantly longer, so there is no bug. Please try clearing the cache and cookies.

Kindly test the same scenario twice on your end and observe the time latency.

Could you please share the requested details in private chat so that we can connect offline for clarification?

I hope this helps to resolve your query.
Duy Nguyen 0 Reputation points

2025-03-24T17:28:22.6966667+00:00
Dear Venkat,

Thank you for your response.

We have shared our available time slots via Microsoft Bookings in the private chat. Could you kindly review them at your convenience?

Regarding your test, we noticed that you are using a single Front Door instance to evaluate two different scenarios. We want to ensure that sufficient time was allowed when switching between enabling and disabling the cache, as these changes typically take some time to propagate.

To confirm whether the changes have been applied, could you please check the x-cache response header?

When caching is enabled, the response should be TCP_MISS:

When caching is disabled, the response should be CONFIG_NOCACHE:
Venkat V 1,390 Reputation points Microsoft External Staff

2025-03-25T03:27:33.81+00:00

Hi @Duy Nguyen

Sure, I will check and post the results here.

1 answer

Your answer

Sai Prasanna Sinde 5,005 Reputation points Microsoft External Staff

2025-03-20T17:40:52.0933333+00:00

Hi @Duy Nguyen

I have initiated a private message. please check it.
Venkat V 1,390 Reputation points Microsoft External Staff

2025-03-21T10:31:31.8933333+00:00

Hi @Duy Nguyen

You can configure the settings below to bypass caching for any POST request that comes to the origin group

Rule Set Configuration

The condition "Request Method = POST" ensures the rule applies only to POST requests, preventing AFD from checking or storing responses in the cache, thus improving response times. "Override Origin Group = Yes" routes POST requests directly to default-origin-group, bypassing other routing rules. "Forwarding Protocol = Match Incoming Request" ensures AFD forwards requests using the same protocol (HTTP/HTTPS) as received, maintaining compatibility with client requests.

I hope this helps to resolve your issue. Please feel free to ask any questions if the solution provided isn't helpful.
Duy Nguyen 0 Reputation points

2025-03-21T13:53:58.1266667+00:00

Hi Venkat V,

Thank you very much for your response!

As mentioned in the original question, we have already addressed this issue by using a rule set to bypass caching on the Front Door. Here is the rule set we are currently using:

However, our main concern is understanding why this workaround is necessary. It feels like we are employing a workaround rather than resolving the root cause of the issue. If caching were functioning as expected, it should not introduce delays for POST requests. Theoretically, since POST requests are not cacheable, caching should not impact their performance.

However, as the timing table from the original question demonstrates, enabling caching consistently results in delays. We would appreciate any insights into why this behavior occurs.

Looking forward to your thoughts.
Venkat V 1,390 Reputation points Microsoft External Staff

2025-03-22T04:25:36.8733333+00:00

Hi @Duy Nguyen

Could you please share the requested details in private chat so that we can connect offline for clarification?
Venkat V 1,390 Reputation points Microsoft External Staff

2025-03-24T07:53:17.5333333+00:00

Hi @Duy Nguyen

I have tested the same scenario in my environment under both conditions, and the results are approximately the same. It is not taking significantly longer, so there is no bug. Please try clearing the cache and cookies.

Kindly test the same scenario twice on your end and observe the time latency.

Could you please share the requested details in private chat so that we can connect offline for clarification?

I hope this helps to resolve your query.
Duy Nguyen 0 Reputation points

2025-03-24T17:28:22.6966667+00:00

Dear Venkat,

Thank you for your response.

We have shared our available time slots via Microsoft Bookings in the private chat. Could you kindly review them at your convenience?

Regarding your test, we noticed that you are using a single Front Door instance to evaluate two different scenarios. We want to ensure that sufficient time was allowed when switching between enabling and disabling the cache, as these changes typically take some time to propagate.

To confirm whether the changes have been applied, could you please check the x-cache response header?

When caching is enabled, the response should be TCP_MISS:

When caching is disabled, the response should be CONFIG_NOCACHE:
Venkat V 1,390 Reputation points Microsoft External Staff

2025-03-25T03:27:33.81+00:00

Hi @Duy Nguyen

Sure, I will check and post the results here.

Answer 1

Sai Prasanna Sinde 5,005 Microsoft External Staff

Hi @Duy Nguyen

1.Why is AFD with cache enabled very slow when handling POST requests?

Only requests that use the GET request method are cacheable. All other request methods are always proxied through the network. This means POST requests are never cached by AFD. Therefore, the perceived slowness is not due to cache lookups, but rather the fact that AFD is forwarding the entire POST request to your origin server every time.

Since AFD is always sending POST requests to the origin, the origin server becomes the bottleneck.

2. Does the cache-checking step of AFD always happen for all request methods?

While the documentation emphasizes that only GET requests are cacheable, this does not mean AFD entirely skips cache-related processing for other request methods.

AFD's architecture likely involves a stage where it evaluates requests against its routing and caching rules. This evaluation happens regardless of the request method.

The cache checking step is more of a rule's evaluation step. The front door needs to evaluate if there is any rule that applies to the request, and those rules could be related to caching, even if the request is not cacheable.

3. If question 2 is a yes, why is that true for POST requests? In the documentation about caching of AFD, it says that only GET requests are cacheable. If POST requests cannot be cached, why does AFD still check data in the cache for them?

AFD's Rules Engine allows you to define complex rules that can apply to any request, regardless of the method. These rules might include:

URL rewrites, Header modifications, Routing decisions, WAF rules

Even for POST requests, AFD needs to evaluate these rules. The cache-related checks are part of this broader rule evaluation process and for efficiency and consistency, AFD likely uses a unified request processing pipeline. This pipeline might include a stage where all requests are checked against the cache rules, even if the request method is not cacheable.

Kindly let us know if the above helps or you need further assistance on this issue.

Duy Nguyen 0 Reputation points

2025-03-18T17:49:28.9433333+00:00

Hi Sai Prasanna Sinde,

Thank you so much for your quick response and clarification! I am still confused about AFD's caching behavior.

I am somewhat unclear about your response to Question 1. If AFD always forwards POST requests to the origin without performing a cache lookup, then, in theory, the processing time for handling POST requests should be identical regardless of whether caching is enabled or disabled. In both scenarios, AFD receives the requests, performs rule evaluations, and forwards them to the origin through the same processing stages. However, as illustrated in the timing table, this is not the case. When caching is disabled, AFD processes the requests significantly faster, with an average response time of 33.6 milliseconds.

(AFD with cache disabled)

In contrast, when Azure Front Door (AFD) is configured with caching enabled, the response time increases significantly, averaging 407.9 milliseconds.

(AFD with cache enabled)

One important observation is that when a rule is set to disable caching based on a request header called cache-disabled (as mentioned in the original question), the response time remains very fast, averaging 31 milliseconds.

Additionally, when the front end sends POST requests directly to the origin—bypassing AFD—the response time is also very fast, averaging 27.9 milliseconds. This indicates that there is no bottleneck on the origin server.

In summary, it is evident that caching on AFD is the cause of the delay when handling POST requests. Whenever caching is disabled, the delay disappears.

As noted in the original question, you can evaluate the performance of our sample application at https://sfa-dev-cdne-uis-bgjv5archbaz4.azureedge.net.

The second button sends the POST request through Azure Front Door (AFD) with caching enabled, and you will notice that the request handling time is significantly higher compared to the other buttons, which either call the server directly or route the request through AFD with caching disabled.

While we understand that, by design and in theory, AFD should function as described in your response, our observations suggest a different behavior. Could this be a potential bug in AFD?
KapilAnanth-MSFT 49,276 Reputation points Microsoft Employee

2025-04-03T17:53:50.96+00:00
Hi @Duy Nguyen ,

Greetings.

I just got an update from our Product Team and please find the details below:

This is an expected behavior.

AFD Platform does not differentiate between POST and GET methods as of now

i.e., every request will be passed onto the different tiers of AFD when Cache is enabled, not just GET

This means, when there is a TCP_MISS (which always happens with POST method) - this would just add to the latency

But a GET method would result in TCP_HIT - so would improve the latency

When you disable Cache (either at Routing Rule level or using Rule Sets), there is no additional processing for cache and the requests are directly proxied to the Origin - improving the latency.

However, please note that our Product team is working to change this behavior, and the expected ETA is by August of this year.

Post which, POST requests would be directly sent to the origin irrespective of the Cache configuration.

Kindly let us know if this helps or you need further assistance on this issue.

Thanks,

Kapil

Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.

Share via

Azure Front Door Standard with cache enabled takes long time to respond to POST requests

1 answer

Your answer