On 09/21/2010 05:15 PM, Joe Schaefer wrote:
I don't recall the breakdown, the 10M figure counts total daily traffic. You could look at Vadim's stats for more details- the bottom line is that no app that doesn't support static exports will function as a suitable CMS for Apache, which is why we're rolling our own.
Ok, I've looked. 10M seems to be *all* requests. That number doesn't scare me. I've got a site live right now, http://www.hailmerry.com/, that is reporting 190req/s with ab(from apache http) while on localhost. That's without any fancy supercache sitting in front. This site supports online live editting of content. Anonymous users have no session, and we make a point of reducing database access for hot-points.
This is running on a single large shared iscsi disk host. The cpu node is an 8-way 2.33Ghz cpu, using xen, with the domU given 512M and a single cpu. The hosting framework is no where near what could be consider super-fast.
The main feature, that I haven't mentioned before now, that helps with this, is a thing we have designed called TTLObject. It is designed to protect method calls, by saving their results, and returning old values for a certain amount of time. It is non-blocking, uses a state engine internally. It was overhauled to follow the design patterns in Java Concurrency in Practice.
Again, I'm not afraid of those numbers. Our cms stuff(which isn't quite up to the same level of feature integration as confluence), stores most data as raw files(to allow svn/git tracking of history). The database is not used for most functions.
