Since most pages would be read far more often than they are written, you could probably get good results by 'compiling' the page to a static cache after each edit.

I think you underestimate just how fast and furious the edits can fly on MDN.

I would go that way too. Static content export, put a CDN in front of it, and response times will get < 100ms, even < 80ms.

I have done some experiments with static exports using dynamic frameworks like Rails, and man, it really makes a huge difference. Of course, if your content is mainly static.

Rendering page content after edits is exactly what we do. Most page views are served up from a pre-built cache, either from a straight caching HTTP proxy or from a single DB column.

Yes, that's exactly what we do:

https://github.com/mozilla/kuma/blob/master/apps/wiki/models...

pardon me, but is that function writing to the database for each page view?

No, only views which hit a stale copy of the rendered page and have to call that render() function. Normal views would (I imagine, I haven't traced it back) use the get_rendered() instead, which checks that the cached version is current and schedules a re-rendering (which obviously requires DB writes anyway) if necessary.

Yeah - looks like it's emulating a lock so only one page can be rendered at a time (plus the overhead for database IO to maintain the lock). Is this really the best way to go about this?

Unless I'm missing something important, it's locking so the same page can only be rendering once at a time; if another request that would cause a rebuild comes in while a previous rebuild is still in progress, it gets bounced.

Yes, you are correct. We're trying to limit the system to one rendering per page at a time.

Seems to me it's actually writing to the database twice for each page view; once to update the render_started_at property on #845, and once again on #881.

That render() method is called only on page edits or forced refreshes, not on every page view.

So? Render statically after each edit.