Hi Clayton,
Clayton wrote:
This afternoon, the Wiki server was up and down many times. it's up and
running OK now... I tested logging out and back in several times and had
no problems. Are you still having a login problem?
It is weekend today. So, there are less traffic then last Friday.
The next Monday is coming and traffic will increase and consequently,
the problem would recur.
1. Decrease the concurrency of Apache web server.
- Tweaking the configuration settings of the Apache web server.
2. Identify what is the primary bottle neck of the system.
- Measuring the statistics of I/O, memory consumption, CPU time consumption,
the number of blocked threads and processes, ...
3. Take actions.
- Installing an additional memory.
- Tuning the configuration settings of the MySQL server.
From my experience, slightly decreasing the number of process or threads
of Apache web server might help than increasing the value of max connections
of the MySQL server. The cause of the problem might be insufficient amount
of memory.
Assume that you are at the outside of a bank and observing customer enter
to and exit from the bank.
Situations
(a) 1 customer per 1 minute comes; A teller takes 30 seconds per 1 customer.
(b) 2 customers per 1 minute comes; A teller takes 30 seconds per 1 customer.
(c) 3 customers per 1 minute comes; A teller takes 30 seconds per 1 customer.
The situations (a) and (b) have no problem while (c) makes a long waiting line.
Situations
(x) 1 customer per 1 minute comes; A teller takes 30 seconds per 1 customer.
(y) 1 customers per 1 minute comes; A teller takes 60 seconds per 1 customer.
(z) 1 customers per 1 minute comes; A teller takes 90 seconds per 1 customer.
The results might be same as (a), (b), and (c).
With the increasing popularity of OpenOffice.org, the situation around our
Wiki server goes from (a) to (b). Meanwhile, with the increasing number of
existing Wiki pages, the situation goes from (x) to (z).
Look into the inside of the bank. There are some tellers at the counter.
There is the only database manager behind the counter. There is a security
behind the manager's desk.
Increasing the concurrency of Apache and/or connections of MySQL might not
help, rather make things worse. Why? Increasing the number of Apache process
means increasing the number of desks at the counter. Increasing the number of
threads of Apache means increasing the number of tellers at a desk. Increasing
a value of max connections to MySQL is similar to increasing the numbers of
the products of the number of desks times the number of tellers per desk.
However, we can not instantly increase the number of the database manger, i.e.
MySQL. What is happening in the bank? It's so crowded with tellers. Each desk
occupies a room, i.e. consuming the certain amount of memory. Each teller
holds a tray on his/her hands, i.e. consuming memory. All tellers have been
waiting for the database manager. The database manager has a large desk that are
covered by a plenty number of trays representing each Wiki pages. If a requested
Wiki page does not exist on the desk, the database manager has to ask a staff to
take it from the security and throw one old tray on his desk away to make a room
to put the new tray. Customers have been waiting for the tellers.
Retrieving data from database is normally done with cached database file in a
system's memory. If the amount of memory is running short, physically reading a
disk device would become to be needed. It would take approx. 10 milliseconds to
position a disk head and approx. 4 ms to wait for the sector. If other
customers'
requests triggered to read data from the disk device, this customer would have
to
wait for much more time. Thus, eventually the situation (z) happens.
When a waiting line grows, the Apache Web server increases the number of process
and/or threads. That is the situation that we have been facing, I guess.
Scenario A
1. A user click on a link to browse a Wiki page
2. His browser requests a connection to the Web server.
3. The Web server accepts the connection.
4. The Web server waits for database access.
5. The database waits for a disk device.
6. The Web server eventually responds to the request.
7. The browser shows the Wiki page.
Scenario B
1. A user click on a link to browse a Wiki page
2. His browser requests a connection to the Web server.
3. The browser requests a connection again.
4. The browser requests a connection again.
5. The Web server accepts the connection.
6. The Web server immediately responds to the request.
7. The browser shows the Wiki page.
Which scenario would be better?
I think (B) would be a better choice to quickly make the Wiki server stable.
The concept here for the first action is "Don't allow customers to enter to
the inside of the bank if it is becoming crowded but wait them outside to
keep the inside tidy and clean."
"Web Caching" by Duane Wessels
http://my.safaribooksonline.com/156592536X
"Squid: The Definitive Guide" by Duane Wessels
http://my.safaribooksonline.com/0596001622
I hope those would help a little.
Regards,
Tora
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
