On a new project with lot of traffic, we are thinking on how to structure our Symfony2 app to take advantage of caches, and be ready to be more aggressive in the future. I'd love to know your opinion.
Let's say a user requests a page a list of places. This page has:
- list
- common data (title, author, description)
- user data (the user likes the list + other data)
- first 20 places
- common data (title, photo of each place)
- user data (the rates of the user for those places)
The HTML could be like:
<html>...
<body>
<header>
...
<!-- Embed the top user menu -->
<esi:include src="http://example.com/profile/menu" />
...
</header>
<content>
...
common data of the list
...
<!-- Embed the common data of the first 20 places, the same for everyone -->
<esi:include src="http://example.com/lists/17/places" />
...
<!-- Embed the user data of the list (used in JS) -->
<esi:include src="http://example.com/lists/17/user" />
...
<!-- Embed the user data of the list of places (used in JS) -->
<esi:include src="http://example.com/lists/17/places/user" />
...
</content>
</body>
</html>
The HTML will be cached on the gateway (Symfony or Varnish). The list of places will be cached most of the time on the gateway too. The user data requests will be the ones which are called and not be cached (not initially at least).
Questions:
- How do you feel about this structure?
- If the user is anonymous, can I avoid making the esi-includes for the user data? Also if I have a cookie for the anon user? How?
- Does the esi-include for the user menu makes sense?
- Or should we forget about ESI and go always through the controller (caching the rendered view of the common data for example)?
- Should we move the 2 ESI-requests that ask for user data to be AJAX-calls, instead of waiting on the server?
- Is this a good approach to scale if we need to do it fast? What would be best?
thanks a lot!