Attempted to test run Authcache on a live site as a replacement for the ESI module (https://www.drupal.org/project/esi). Using Varnish 4, ESI, Nginx. Also using the safe front controller authcache.php.
Trying to determine why the average transaction time for authcache.php is much higher than the esi_handle_component used in the ESI module code.
On average, authcache.php requires 404ms of transaction time, while esi_handle_component was at 263ms. Also in general, authenticated users are saying the site is much more sluggish. It doesn't make sense how Authcache could actually result in worse performance than having no caching for authenticated users.
Anything I could be missing that would cause such a result? Thanks.
Comments
Comment #2
znerol commentedIt is quite hard to assess performance characteristics without actually measuring what is happening. I suggest to run some tests using xhprof, this will usually lead to a better understanding of where time is lost on the critical path.
Another idea is to examine server logs for specific clients and verify that there are no repeated uncacheable requests (to pages and to page fragments) to the backend. If this is not the case then that might indicate a Varnish configuration issue.
That said, neither Authcache nor Varnish/ESI is a silver bullet. They can help to make a decent site scale out without having to add too much hardware. But neither of them can make sites faster accross the board, the odd uncached response will hamper user experience.
Also I'd like to point out that ESI is only a good solution if fragments can be reused. Either because they are displayed numerous times during a typical browser session or because they do not depend on the currently logged in user and can be reused accross multiple browser sessions. If neither is true, then ESI makes your page slower. In this case one fragment (or worse multiple fragments) will trigger multiple bootstraps for every single page request and will delay time-to-first-byte quite badly.
In general I recommend to use Ajax for low-reuse fragments (e.g., per-user). This has the benefit that those fragments will be cached in the browser and thus will not inflate Varnish cache. Also in most cases users tend to tolerate that some page elements only become visible after a certain delay if the initial page load is fast (perceived performance).
Comment #3
znerol commented