Forum OpenACS Q&A: high peak load on openacs 325 database backed pages

1: high peak load on openacs 325 database backed pages

Posted by Henry Minsky on 06/07/01 01:07 AM

I have a project where the application is to allow people to sign up
for "first-come first-served" registration for some adult education
classes.

The current system they use for online registration is inadequately
implemented in php/mysql. The problem is that when the new courses are
announced, at a fixed time each month, they get a large peak usage as
people all try to sign up at once. They showed log files of about
70,000 page hits on their class schedule page within about 10 or 20
minutes.

They said many of these were caused by people hitting 'reload' when
the pages failed to come up in time, and the pages fail to come up
because their system gets overwhelmed and db connections are not
available or slow.

I am guessing that some combination of in-memory caching and
management of db handles will make it possible to handle this
load. But I am curious if anyone has any experience with what
the maximum load possible is, in requests per second, for a 1 GHZ
Pentium with 512 MB of RAM , for fetching a database-backed page with
one or two modestly complex queries.

2: Response to high peak load on openacs 325 database backed pages (response to 1)

Posted by Petru Paler on 06/09/01 12:29 PM

The current system's problem is probably caused by mysql's row locking. Simply switching to a versioning-based database should make things much better.

As about maximum load possible, I have one AOLserver running a custom Tcl script as the request processor. Each hit requires 2 db queries against a table with 500000 rows in it, plus incrementing about 5 nsv variables (which implies alot of locks taken). The thing does an average of 31 hits/second, with peaks jumping over 50/second. The db hit average is around 15/second, much lower than the expected 62/second, since the script uses caching (nscache).

3: Response to high peak load on openacs 325 database backed pages (response to 1)

Posted by Seth Wagoner on 06/10/01 05:50 PM

I thought mysql used page locking? Which causes more conflicts than row locking. PostgreSQL is slower again tho, isn't it? The lack of transactions means mysql can be very fast, but it has a price!

My recommendation would be to move to Postgre for the ACID compliancy, which will save you headaches even if it's a bit slower, and limit the number of people who can access the db-driven pages at any one time - each load of the schedule page could check the current database loading, and if it's too high, reroute to a static "try again in a few minutes" page.

NB: I haven't used either database very much myself, or even installed OpenACS yet, so don't ask me how to implement that 😊

4: Response to high peak load on openacs 325 database backed pages (response to 1)

Posted by Talli Somekh on 06/10/01 05:56 PM

seth, first time here, huh?

openacs *only* uses postgres because of ACID-ity. I would suggest some RTFM-ing. But welcome! It's nice to see that you're here and willing to contribute!

talli

5: Response to high peak load on openacs 325 database backed pages (response to 1)

Posted by Seth Wagoner on 06/10/01 06:29 PM

Yep, I'm new. But actually my mistake was not reading the subject line properly, rather than not doing enough RTFM - I was thinking it was a general question about "database-backed pages" rather than an OpenACS specific question. Whoops 😊

I also note from doing a bit more reading that mySQL has come along a bit since I last looked at it. Transactions, no less! Of a sort, anyway. Interesting.