3 ms·

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:MD

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 https://developer.mozilla.org/en-US/docs/Project:MDN/Kuma

chad_oliver 13y ago
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.
- iagooar 13y ago
  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.
- ubernostrum 13y ago
  I think you underestimate just how fast and furious the edits can fly on MDN.
- lmorchard 13y ago
  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.
ye 13y ago
So? Render statically after each edit.
groovecoder 13y ago
Yes, that's exactly what we do: https://github.com/mozilla/kuma/blob/master/apps/wiki/models.py#L853 https://github.com/mozilla/kuma/blob/master/apps/wiki/models...
- riffraff 13y ago
  pardon me, but is that function writing to the database for each page view?
  - avidal 13y ago
    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.
    - lmorchard 13y ago
      That render() method is called only on page edits or forced refreshes, not on every page view.
  - handsomeransoms 13y ago
    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?
    - shabble 13y ago
      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.
      - lmorchard 13y ago
        Yes, you are correct. We're trying to limit the system to one rendering per page at a time.
  - shabble 13y ago
    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.

chad_oliver 13y ago

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.

iagooar 13y ago
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.
ubernostrum 13y ago
I think you underestimate just how fast and furious the edits can fly on MDN.
lmorchard 13y ago
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.

ye 13y ago

So? Render statically after each edit.

groovecoder 13y ago

Yes, that's exactly what we do: https://github.com/mozilla/kuma/blob/master/apps/wiki/models.py#L853 https://github.com/mozilla/kuma/blob/master/apps/wiki/models...

riffraff 13y ago
pardon me, but is that function writing to the database for each page view?
- avidal 13y ago
  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.
  - lmorchard 13y ago
    That render() method is called only on page edits or forced refreshes, not on every page view.
- handsomeransoms 13y ago
  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?
  - shabble 13y ago
    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.
    - lmorchard 13y ago
      Yes, you are correct. We're trying to limit the system to one rendering per page at a time.
- shabble 13y ago
  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.