Flow/Architecture/HTML caching

Flow uses memcache to cache workflow items from the database.

The team is considering caching HTML for entire topics, and possibly entire Flow boards, for anonymous and logged-in users. Users with special rights (sysops and oversighters) would always get a special view of the board (relatively few hits for these users).

Related: store

The performance benefit is if rendering a normal page would just be get the id's, and spit out the pre-rendered html for those ids :)

We could go further and cache the entire HTM L Flow board (header + 10 topics) in Varnish HTTP proxy server if the percentage of people who edit after viewing it is low. Edit/add post means invalidating topic HTML cache and any Flow boards with that topic in the Varnish cache. Fun!

There is also the possibility of allowing Edge Side Includes from varnish to incorporate the header and ten topics. We would have to do a good bit of testing and performance checks to determine if its reasonable. A worry is that perhaps a varnish server goes from 15k requests/s down to 5k req/s because it does more processing ... but on the other hand the php servers are probably beefier and do < 50requests/s.

Concerns: Is this scalable? What about other features we have in the roadmap? Would all of those be cacheable in the same way?

Things that currently vary on each request
Caching HTML doesn't work if the desired HTML varies with user or with time. Dynamic features would have to be dropped, some re-added in JavaScript.


 * The user's username/IP appears above textareas for any reply the user makes.
 * approach: don't show these in non-JS version ({{bug|do in JavaScript, don't y


 * "A minute ago" dates
 * PHP could show fixed timestamps, JS enhancement could change these to user-friendly timestamps (needs JS implementation of getHumanTimestamp with cldr support), and move the fixed timestamp to a rollover.


 * Can only Edit your own posts (depends on Flow permissions)
 * Could have an Edit button next to Reply everywhere, in no-JS it could either fail on submit or show wikitext of item. JavaScript would hide this on the user's own posts.


 * no Thank if anonymous
 * approach: have a class="no-anonymous" on Thank that is hidden if the user is known.


 * no Thanking yourself
 * approach: have the Thank link everywhere, non-JS would submit to Thanks form and fail if thanking yourself. JavaScript could hide Thank on thanks to yourself.


 * no blue background on the user's own name
 * JS enhancement