Hacker News Reader

Comment by KaoruAoiShiho | Hacker News Reader

Isn't MDN mostly stactic content? I don't understand why it's so slow... Everything should be served off of static pages on a cdn.

View on HN

MDN is a wiki! There's a django backend which also uses a node.js web service for wiki templating features.

https://developer.mozilla.org/en-US/docs/Project:MDN/Kuma

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 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.

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

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.

So? Render statically after each edit.

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?

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.

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.

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.

Reply on news.ycombinator.com