Problem Description:
As shown below, during 18 Jun 24's performance test, we noted the middle tier (Node.js) did not return any 304s (Not Modified) but the web cache did. Should we extend the middle tier to return 304s when appropriate, we can achieve a network optimization as the associated response bodies would not have to be returned by middle tier and go through the middle tier's load balancer before reaching web cache.
Priority input: performance tests and deployments without a cache in front of the middle tier may be the only ones to benefit from this capability. LUX PROD is not expected to benefit much to any. Would unit portals also have a middle tier cache?
Expected Behavior/Solution:
Middle tier to continue to process the following requests but before sending the response, it is to compare the provided ETag to that response. If identical, return a 304. Only applicable to requests that provide an ETag.
/api/advanced-search-config
/api/auto-complete
/api/data-constants
/api/facets/:scope
/api/related-list/:scope
/api/search/:scope
/api/search-estimate/:scope
/api/search-info
/api/search-will-match
/api/stats
/api/translate/:scope
/data/:type/:uuid
Log details about requests that arrive with ETags. If such requests exist, we may want to investigate.
Requirements:
List of details required for the completion of the issue or requirements for the feature/bug. This can also include requirements that lie outside of the teams such as new design docs or clarification from an outside source.
Needed for promotion:
If an item on the list is not needed, it should be crossed off but not removed.
~- [ ] Wireframe/Mockup - Mike~
[ ] Committee discussions - Sarah
[ ] Feasibility/Team discussion - Sarah
[ ] Backend requirements - None
[ ] Middle tier requirements - See above.
[ ] Frontend requirements - Starting with the frontend and to Node.js, ETags are to accompany requests, when possible/applicable.
[ ] Are new regression tests required for QA - Amy
[x] Compels a performance test? No
[ ] Questions
List of questions for discussions. Answers should be documented within the issue.
UAT/LUX Examples:
To test, we'd need
Dependencies/Blocks:
This ticket depends on at least some requests being accompanied by ETags.
Based on a team conversation today, the decision on whether to implement this ticket is blocked on upcoming discussions on how to perform a performance test. cc: @jffcamp, @prowns, @roamye
Problem Description: As shown below, during 18 Jun 24's performance test, we noted the middle tier (Node.js) did not return any 304s (Not Modified) but the web cache did. Should we extend the middle tier to return 304s when appropriate, we can achieve a network optimization as the associated response bodies would not have to be returned by middle tier and go through the middle tier's load balancer before reaching web cache.
Priority input: performance tests and deployments without a cache in front of the middle tier may be the only ones to benefit from this capability. LUX PROD is not expected to benefit much to any. Would unit portals also have a middle tier cache?
Expected Behavior/Solution:
Requirements: List of details required for the completion of the issue or requirements for the feature/bug. This can also include requirements that lie outside of the teams such as new design docs or clarification from an outside source.
Needed for promotion: If an item on the list is not needed, it should be crossed off but not removed.
~- [ ] Wireframe/Mockup - Mike~
UAT/LUX Examples: To test, we'd need
Dependencies/Blocks: This ticket depends on at least some requests being accompanied by ETags.
Related Github Issues: Performance test comment that discusses 304s: https://github.com/project-lux/lux-marklogic/issues/181#issuecomment-2182764059
Related links: None
Wireframe/Mockup: N/A