Update on my blog about Hybris. This is the third article on the topic of caching page parts to stabilize performance under heavy traffic for an e-commerce site.
Alexey Pasynkov, thanks for the idea! It took a bit of effort to get it to work on Windows, but ultimately it was successful.
Briefly about the working principle. A reverse proxy NGINX is placed between the user and Hybris. All requests go to it, and it redirects them to Hybris if necessary. Caching means that sometimes it does not do this, so the page suddenly loads much faster.
When requesting, say, the main page, Hybris renders all components for the first time, but instead of immediately delivering the result to the client’s browser, it stores the resulting html in the cache for a specified number of seconds (depends on the cached area, set manually). Then, Hybris returns the page to the user, but all these areas with components, now in the cache, are replaced in the output HTML with special tags, which are intercepted by NGINX. If these tags reached the user’s browser, the browser would not know what to do with them, but here the gadget in the middle, through which these tags pass, comes to the rescue. Seeing the tags, NGINX requests the same cache where these fragments were stored and inserts the result instead of the tags, and the shopper’s browser sees everything as it would be without any caching. Only on average much faster. If the first time this will work a bit longer than without any caching, then on the second and subsequent times it will work significantly faster, since Hybris will no longer be formulating a good half of the page, and it will be pulled from the cache even before Hybris by NGINX.
Overall, I’ve almost told everything here, but the article contains some more details and a picture.
Erik Babadzhanov Renata Mussina Maxim Antonov Marina Zhigalova Alexey Lyubimov
Hi, I'm Rauf Aliev. 