Wooo, you type faster than you think!
You call it eye candy, I call it an interesting and
potentially damn
useful feature idea. Running a web site that gets upwards of ten
thousand odd hits per second, allowing any old web user to edit it,
etc. etc. also requires resources.
Yes, this is what we constantly work on =)
How do we handle the hit rate? Caching. Squids, shared
memory caching
and opcode caching, not to mention encouraging the client side cache
where possible. Our resources evolve to meet our needs. We can adapt
to what our code base is doing.
When did you work on performance? How many of various eye candies can
be cached?
Squids can cache content for anonymous users, this is what they're
doing at the moment.
Shared memory caching isn't that much of panacea, our usual MySQL
queries are nearly as fast as memcached hits - both at single
millisecond.
It is usually used to offload processing, but you have to define a
clear case how and when to use cache.
Say for simple two-revision diff we not only cache them, but also
have great C++ written module for doing actual work.
You should note that we have zillion-revision articles, so not only
you run out of RGB, but also have quite a lot of expenses.
might turn out to be a load of bollocks. You won't
known until we've
examined it in more detail.
So performance is an issue. When is it not?
Many things we did to improve performance were based on profiling
data. And of course, common sense.
We had DifferenceEngine taking nearly 10% of our cluster cpu use,
with less than 0.5% of backend requests being diffs.
Now we're down to 2% of cluster cpu use, with less than 0.5% of
backend requests being diffs.
Add up regular page loading routines, because there's more than
DifferenceEngine for showing a diff.
So sure, lots of work has been done, it became quite efficient.
Now if we introduce task that is far more complex than two-rev diff:
a) how much of use that will get (to create an encyclopedia)
b) how efficient would it be?
Of course, if someone comes up with efficient feature, it is great.
But complex efficient feature requires complex efficient programming,
and we have just two guys who are actually doing such work (and
capable of doing it). And sure, they're both loaded with running the
site.
If anyone else wants to join the ship, of course, they're absolutely
welcome.
And people shouldn't have misconceptions that we have lots of
resources and can run anything. We're donation powered website, that
has to fix the infrastructure before autumn, because then we have yet
another surge of users.
Anyone has right to download the dump and provide nice eyecandies for
community, if they want to participate that way :) Just one important
thing to remember - don't try getting popular ;-)
Domas