It is not possible to make specific suggestions based on the information
you've provided. The list would need to know the nature and platform of
your application, the amount and type of the traffic you see, your
current mysql vs. apache load (like queries, requests per sec), current
server config, what you mean by "choking", etc. But there are always
some general rules that apply, some of which have been mentioned...
I'll second the recommendation for the book "High Performance MySQL" by
Zawodny. It will answer many of your questions and help guide you
through this process. We have two sample chapters from the book --
Replication and Server Performance Tuning on our Developer Zone. We
also have several other great articles on performance tuning in our
articles section: http://dev.mysql.com/tech-resources/articles/
I'd also like to recommend our Consulting (Professional Services) folks,
led by Josh Chamas. You can get any kind of consulting gig, big or
small, for a very fair price -- it will save you money. These guys are
absolutely top notch and among the best in the business when it comes to
scale-out -- they do regular consulting for very well known, high
traffic sites I'm not allowed to mention. See
http://www.mysql.com/consulting/
Some general principles I go by:
- If you can, always separate http and MySQL (as in your option 2).
- If you are read heavy as you say (and who isn't?), spread that load
over one or more mysql slaves. You don't mention replication. Why not
use it?
- People tend to assume that there is nothing wrong with their
application, but everything wrong with their hardware or software. The
-first- place I look is in the slow query log, because for web
applications usually built by non-DBAs, that is so often the biggest
bang for your buck. Sometimes 20 minutes using explain to make sure you
have the right indexes in place and are not doing sub-optimal joins can
give you a 20-30% increase in application performance. Next I spend some
time in my.cnf making sure that MySQL server is making the best use of
memory.
If you give us more details I think we can probably give more specific
advice on what sort of architecture might be an appropriate fit.
--
Eric Braswell
Web Manager MySQL AB
Cupertino, USA
Elias wrote:
We are currently building a webfarm to replace our all in one box solution. We
are experiencing problems when we get linked to a site like the drudgereport
and we are seeing 1000's of hits a minute. Both apache and mysql start chocking
and we get dropped because we cant deliver content. I am trying to understand
what is the best way to redeploy our Mysql.
I am thinking of two possible designs, if feasible. The clients are read only
there is no inserting or deleting. The database is updated nightly from a
single source.
Fig 1
_____________
| http |
| Mysql |
|_____________|
_____________
| http |
_______ _____________ | Mysql | _____________
| PIX | | Load Balance | |_____________| |
|
| | ---| |------ _____________ -------|
SAN |
|_______| |____________ | | http |
|____________ |
| Mysql |
|_____________|
_____________
| http |
| Mysql |
|_____________|
In Fig 1 I am thinking that each server runs both apache and the mysql engine
and the database files will live on the SAN. Is this possible? can multiple
engines talk to one database file on the SAN?
Fig 2
_____________
| http |
| |
|_____________|
_____________
| http |
_______ _____________ | |
_____________ ______________
| PIX | | Load Balance | |_____________| |
| | |
| | ---| |------ _____________ -------|
Mysql |---- | SAN |
|_______| |____________ | | http |
|____________ | |_____________ |
| |
|_____________|
In fig 2 the 3 apache servers would query the single myql server.
All the data and scripts would live on the SAN. Or would it be better and
faster to have the data live on the mysql server and the scripts live on the
SAN?
We are going to deploy HP proliant ml 585 with quad AMD 2.2 Opterons with 12
gigs of ram. With that in mind how many mysql sessions can I be able to support?
Any suggestions, comments, thoughts of clarity would be greatly appreciated.
Regards to all,
Michael
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
