Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a growing website which now uses a single and ordinary MySQL server for its tasks. I wonder how and when should I migrate to more powerful servers or in other words when is the best time to use mirror servers or grid or other than single serving server?

How could I find out that my web apps need a better database server solutions and configurations? I know I can study usage and server loads, but since I don't have enough experiences on managing and developing large scale websites I need some advices on how to configure MySQL server(s) for a fast growing website? what are the best practices?

share|improve this question

migrated from Jun 14 '11 at 6:22

This question came from our site for professional and enthusiast programmers.

clustering or replication – ajreal Jun 14 '11 at 6:17

The standard system metrics may give a good view of how your performance is currently constrained - but they don't measure performance directly.

For thick client solutions its rather hard to measure performance.

For embedded applications, it's easy to measure if your database is sinking data as fast as it is generated - you either get unacceptable backlogs or dropouts in the data.

And in your case, for web based applications, again measurement is simple (start logging and analysing HTTP response times - NB on Apache use %D rather than %T).

Beyond that you need to decide what level of performance you actually need - faster is almost invariably better, but this must be offset against the cost of achieving that performance.

I need some advices on how to configure MySQL server(s)

Seer Fran's reading list.

Note there's no magic bullet (although usually gives a good starter for tweaking the DBMS settings). The biggest benefits will come from good architecture/hardware design and application tuning - both of which depend on good analysis of good data.

share|improve this answer

"I know I can study usage and server loads"

You know what to do, then :)

First thing you should have in place is a proper monitoring/graphs system in order to have good visibility of the database performance. Check it from time to time, discover which is your database performance "baseline" and keep an eye on it.

Correlate those metrics with application performance, know how does database response time impacts user web interaction and processes. Once you detect that the database side is, indeed, degrading the application (profile it, discover the % of the response time is used in the database backend) then start to worry about it and take action.

Before starting to scale (up and/or out) your database server deployment try to improve the application and SQL sides. Never underestimate how much you can improve performance by tuning execution plans and (proper) indexing. It is usually faster and cheaper than scaling the infrastructure.

I recommend you to take a look at these books, they may help you:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.