125M hits/day is approximately 1500 hits/second on average, but more interesting, what is the maximum? And are those “hits” or “page views” (i.e. does it include images and other resources)?

Those are hits (including images and other resources), so it’s probably not a particularly good stat since our redesign added a lot of images, etc. On the other hand, we’ve also unloaded update checks to another server, so those shouldn’t be counted anymore. As far as maximum, it’s close to 200M right now.

The better statistic, page views, is around 5-7M/day. This has been pretty volatile lately (probably due to the redesign) but it looks fairly consistent averaged over the past few months.

And how many of the page views can’t just be flat files served by lighttpd (i.e. all public and most of the private it seems, cause the only real difference from the public pages are the first name shown — which could just be added by javascript from a cookie or from a json-request with a long cache time and a cache-killer in a cookie)? Just curious.

Plenty of it could be, but I suspect the netscaler offers as good if not better performance than lighttpd (< -- totally unresearched claim! ). One of our obvious-in-hindsight mistakes was storing add-on preview images in the database. I think it started with the idea of just storing icons in the db (max 32x32) which wouldn't be bad. Then it somehow encompassed add-on preview images, which can be much larger, and it's slowing our queries down. A pretty bad idea, and I think it would be a perf boost to store those on disk instead of the db.

Also, regarding the javascript idea - that's actually what we did in version 2. In v3 there are more changes than just name - the menu changes depending on whether you are a developer, admin, localizer, etc. and there are some "edit" buttons if you have permission to things. Certainly possible with js, but more to think about.

I don’t know if you changed it, but last time there was talk about AMO design, it seemed like you didn’t use the most optimize schema for the translations (i.e. one general translations table, instead of a translations table for each table with data for the fields on columns instead of rows). Also, what about pre-generating translated php-files.

Like the images above, we haven’t really altered the db schema much even if we should. It’ll probably be targeted for another update (the next one being far less visual and more backend).

I don’t know if you changed it, but last time there was talk about amo design, it seemed like you didn’t use the most optimize schema for the translations (i.e. one general translations table, instead of a translations table for each table with data for the fields on columns instead of rows). Also, what about pre-generating translated php-files.

Just curious, how is this charted against the usage growth of AMO?

We started using urchin on AMO about this time last year so I don’t have numbers from before that without time consuming log crunching. I can tell you we’re averaging 125M hits per day right now, and a year ago it was 50M.