Hello,
If we get accurate statistics on what kinds of
processes these are and
what quantity of resources they consume, we might be able to integrate
these considerations into the simulation environment we'll be using to
evaluate various architechtures for distributed hosting.
We're doing some of this action for links processing, where delays
can be tolerated, but that's more for serializing pagelinks load.
Though nature of wikis does not allow lags for most operations - if
edits were async (I'd love if they could be..), multiple people would
be editing same pages and of course, getting conflicts. Async
communication for conflict resolution would be somewhat difficult.
And other actions, such as diffs, views, whatever, all need to be
synchronized. Of course, distributed caching helps a lot, and our aim
should be better efficiency of it, but still, we've got to be in sync.
As for distribution, I'd like to see some of application
synchronization primitives (like message cache state, db server lag,
etc) being pushed to app servers rather than pulled from db/memcache.
But that's already fighting miliseconds :)
As for architecture, there're not that many low hanging fruits at the
moment that would be easy to solve by distribution. If anyone sees it
otherwise, please tell :)
Domas