Community
Select to view content in your preferred language

ArcGIS Server site: poor cache efficiency due to different "etag" header sent according to machine

420
10
2 weeks ago
NicolasGIS
by
Honored Contributor
2 weeks ago

Hello,

When refreshing my web application, I was surprised not to only hit '304 Not Modified' responses when querying my ArcGIS Server services for the layer properties with the following URL:

https://gis.company.com/arcgis/rest/services/General/Data/MapServer/86?f=json&token=Foo

What I noticed is that if you query your ArcGIS Server VM individually:

https://gisVM01.company.com:6443/arcgis/rest/services/General/Data/MapServer/86?f=json&token=Foo

https://gisVM02.company.com:6443/arcgis/rest/services/General/Data/MapServer/86?f=json&token=Foo

and compare the responses, they are identical (to notepad at least) but they both have a different "Etag" header.

NicolasGIS_0-1765724844792.png

As a consequence, cache cannot be leverage.

It looks like ArcGIS Server machine is creating the Etag header by taking into account specific properties to the VM. As I am hitting my servers in a round robin way behind a load balancer, I always have 50% layers responses with 304 Not modified and 200. 

 

Do you observe the same phenomena ?

 

Thanks

10 Replies
ArchitSrivastava
by
Frequent Contributor
2 weeks ago

@JoshuaBixby 

Completely reasonable point. I’m not saying the geodatabase type by itself is the cause. I’ve just noticed in a few environments that services backed by a centralized SDE tended to look more consistent across nodes, while file-based data deployments sometimes showed more variation. Either way, agreed it’s worth validating with a couple targeted tests.

On your question about the full REST call: yes, the REST call I meant is the basic layer resource endpoint:

https://<cname>/arcgis/rest/services/General/Data/MapServer/86?f=json&token=<token> 

For troubleshooting, it also helps to hit each node directly and compare headers:

https://<machine1>:6443/arcgis/rest/services/General/Data/MapServer/86?f=json&token=<token> 
https://<machine2>:6443/arcgis/rest/services/General/Data/MapServer/86?f=json&token=<token> 

Also, just to be clear: keeping the token stable during testing is simply to avoid changing the URL between requests (general HTTP caching behavior). I couldn’t find specific Esri documentation describing how ArcGIS Server generates ETags or whether the token is included as an input.

0 Kudos