4 ms·

> Between 2-4% of requests can’t be served via our caches, and there are users who always need to be served by our main (uncached) application servers. This inc

by Shish2k 12y ago

> Between 2-4% of requests can’t be served via our caches, and there are users who always need to be served by our main (uncached) application servers. This includes anyone who logs into an account, as they see a customized version I run a similar site (95% read-only), and have been pondering whether it would make sense to use something like Varnish's Edge Side Includes (Like SSI, combining cached static page parts and generated dynamic page parts) -- I wonder if they've considered that and what the results would be like?

dugmartin 12y ago
I've played with this configuration but never put it into production: Varnish (with ESI enabled) -> Nginx (with memcached module enabled) -> PHP-FPM. Most of the page is served with Varnish with the ESI directives hitting the Nginx server which serves the fragments from memcached if present, otherwise the PHP-FPM server is hit which then returns the results and sets the fragment in memcached with a low ttl.
aonic 12y ago
I've run into a similar case. In my case using ESI defeated the whole purpose of the Varnish implementation because the dynamically generated portion of the page had to rebuild the user session and bootstrap the framework, which, while faster than doing it for the entire page, was still not as fast as I would have liked to deliver the content to the browser. In the end I ended up placing special HTML tags where the ESI tags would have been placed, and then making AJAX calls (on dom ready) to swap out the static content with the dynamic user-specific content. It worked well for our needs.
MatmaRex 12y ago
There is an old proposal to use it, but it seems that not much effort was put into it. https://phabricator.wikimedia.org/T34618 https://phabricator.wikimedia.org/T34618 https://www.mediawiki.org/wiki/Requests_for_comment/Partial_page_caching https://www.mediawiki.org/wiki/Requests_for_comment/Partial_... Personally I doubt that it would help much – there are hardly any non-dynamic parts of the page in MediaWiki. (Everything is customizable using server-side configuration, modifying magical pages, or both; or dependent on user permissions or preferences; or both.)

by Shish2k 12y ago

dugmartin 12y ago

I've played with this configuration but never put it into production: Varnish (with ESI enabled) -> Nginx (with memcached module enabled) -> PHP-FPM. Most of the page is served with Varnish with the ESI directives hitting the Nginx server which serves the fragments from memcached if present, otherwise the PHP-FPM server is hit which then returns the results and sets the fragment in memcached with a low ttl.

aonic 12y ago

I've run into a similar case. In my case using ESI defeated the whole purpose of the Varnish implementation because the dynamically generated portion of the page had to rebuild the user session and bootstrap the framework, which, while faster than doing it for the entire page, was still not as fast as I would have liked to deliver the content to the browser. In the end I ended up placing special HTML tags where the ESI tags would have been placed, and then making AJAX calls (on dom ready) to swap out the static content with the dynamic user-specific content. It worked well for our needs.

MatmaRex 12y ago

There is an old proposal to use it, but it seems that not much effort was put into it. https://phabricator.wikimedia.org/T34618 https://phabricator.wikimedia.org/T34618 https://www.mediawiki.org/wiki/Requests_for_comment/Partial_page_caching https://www.mediawiki.org/wiki/Requests_for_comment/Partial_... Personally I doubt that it would help much – there are hardly any non-dynamic parts of the page in MediaWiki. (Everything is customizable using server-side configuration, modifying magical pages, or both; or dependent on user permissions or preferences; or both.)