Hardware and performance

> The major things I did were:
> 1) Use eAccelerator (speed increase x3)
> 2) Switch from apache to lighttpd (similar speed, but more stable under load)
> 3) Upgrade from 1.8 to 1.9 (speed increase x2 - x3)
> 4) Upgrade the CPU to a quad core with about x3 the power

Thanks for the list, very useful.

> One of the things which I discovered was that the database (postgres) is CPU bound. Which seems strange, but when you look at the sql it's understandable. Is this a common occurance?

I too would have though the db is i/o bound. Possilbly the db is in the cache?

>> How do you solve the problem of logins?

> Not sure I understand the question, but all these urls can be reached without logging in if that was the question.

My point is, the Moodle users work after logging in. It affects the performance because now you have a whole lot of new SQL querries. Any Moodle-specific benchmarking should take that into account.

On the comparison perspective vs. your approach (http-requests):
1. yes, perspective is not coupled to Moodle code. As you say, it measures various "general" functions of the machine

Which makes http-requests method Moodle-specific, therefore you have to mention the version.

2. perspective runs in the same machine, http-requests should come from outside (not a must)

Network performance goes in to your measurement. So have to specify the link.

3. To convert the measurement into so many users, both approaches need a conversion factor. My question is, is it something as simple as, n http-requests per user?

Secondly you want to get that factor from different admins. Isn't too much guess work and extrapolations involved in that process?

May be a whole set of information per installation might be more useful. For example:
- hardware
- software stack (OS, Webserver, db, php, Moodle)
- a _set_ of hard benchmark figures
- estimated max. users and the formula