I am running a game server that uses a mysql database to store a lot of information. I also have couple of different hosts that have mysql.
So I was wondering if there are any ways of testing the connection or write speed (I am new to sql, so I am not sure of correct term for what determines speed of the database) of the databases on different hosts and see which one is better? Or alternatively if there are any ways of making the database faster with some setting.
Thanks.
Regarding question #1: Please see The MySQL Benchmarking page for assistance in benchmarking and performance tuning.
I would suggest using the benchmark tools available for download here against each of your hosts to check performance against each other.
Your second question is a book into itself and may not have an easy answer. I suggest creating a second question with specific questions about performance for better assistance regarding that question. Possibly at the dba site (link below).
Now, if your question is "What is the best way to load balance my database servers" You have an entirely different question, and one that should probably be asked on the https://dba.stackexchange.com/ site.
Related
At the beginning I would like to say that I am not expert in this domain and It is problematic to describe all nuances. I work on Rails application which uses Mysql database. Our DB has grown and now we have seriously problems with performance. In our app we have two features (for example sync with mobile) which process much data and It causes our database hang. We use newrelic to monitoring which confirmed that we have problems with those two parts of app. My main question is how to profile my app to figure out which actions make the biggest problem? Which tools I can use? Do you have any tips what I can do/configure DB to improve performance? What action I should do to find out where the problem is (next small step)? I know that those question are very general but I am junior in this domain and new in rails. I believe that more question will appear after your answers ;)
Firstly what is the size of db, like how many tables and avg no of rows per table. With the basic details available in your question, here are few steps you can look upon.
Regarding data sync with mobile. First step should be avoid heavy processing on the fly rather use background jobs to process the data and store in tables what actually needs to be sent to mobile . So in that case you will avoid multiple queries, rather 1-2 queries should fetch the entire data with minimum processsing.
I'm sure you must have applied indexing and active model relationship has been properly managed. It would actually help if you can post some models and basic relationship between them . Also explan in brief how the sync is being done and apis being handled.
Use benchmarking to figure the time to fetch data and keep a watch on the logs when processing data. There are some better benchmarking tooks available.
I have a mysql server.
And I need to run wordpress and discuz on it, there are two ways to use the mysql server:
create two databases in mysql, one for wordpress and the other one for discuz
create only one database in mysql, the two shares the database.
Which one provides better mysql performance?
Thanks!
actually as far as I can tell it's almost the same, but just a readability issue, lots of websites are hosted on a server that allows only a single db, in that case, you can use the same db with different table prefixes'for example' to enhance readability, other than that, it's almost the same, no performance issues, but on the other side, having to data bases, will allow you to track problems on the db server like overload and things like that easier since you will know already where it's coming from. I hope that's enough.
for some software engineering point of view, maybe use two databases is better.
(Ok, if there is no too much big data in your databases, it nearly make no difference but if your data is big enough it's better to seperate and manage independently. mostly good engineering work is forcast work of performance, so that's my suggestion maybe it's not a good answer.)
I am building a Mobile App which uses a backend server to store the data. If I describe it in terms of Relational DB then it is ~10K records (2 or 3 tables). Planning to use Linode VPS to host it (512 MB). I know the question is very broad, but want to get an idea about the performance under load.
Another choice is to use a NoSQL like Redis, but for that need to put up some time to learn.
I already did searching on SO, but no satisfactory answers yet.
PS: This is a side project and i expect to learn the things along the way. But some good pointers would help to speed up the process.
it appears that you'll have to work on optimizing queries more than looking for some quick fix. I have been working with plenty of projects running on virtual servers with no performance issues if you write the queries in correct manner. Have a read:
http://owaisahussain.blogspot.com/2012/06/yet-another-blog-on-query-optimization.html
Disable InnoDB, that will save you lots of RAM. To do this, have skip-innodb in your my.cnf file.
I am currently creating a site(php,css,html,ajax,MySql) which will have heavy user usage of space(regarding data). These data are quite essential and the can NOT be lost, it is really essential.
I am looking for tips on servers, languages and everything else(even theory) about distributed database systems. Any help would be really appreciated. Also it would be great if the system used mysql.
Thank you
P.S. dont link Google.com. I have done that and reached nothing but a wall :(
My guess is that you're Googling for the wrong terms. If you searched for MySql Replication you might run into this article
Database replication is what enables a "distributed database system". You should also look into clustering to see if that type of distributio/replicationn might meet your needs.
Also, you didn't specify if you were running LAMP or WAMP but here's a how-to on setting up a MySQL and Apache cluster.
The only good reference that I can find on the internet is this whitepaper, which explains what database tiering is, but not how it works:
The concept behind database tiering is
the seamless co-existence of multiple
(legacy and new) database technologies
to best solve a business problem.
But, how does it implemented? How does it work?
Any links regarding this would also be helpful. Thanks.
I think the idea of that document is you to put "cheap" databases in front of the "expensive" databases to reduce costs.
For example. Let's assume you have an "expensive" db...something like Oracle, or DB2 or even MSSQL (more realistically it's probably more of an issue with a legacy DB system that is not supported much or you need specialized resources to maintain). A database engine that costs a lot to purchase and maintain (arguably these are not expensive when you take all factors into consideration. But let's use them for the example).
Now if you suddenly get famous and your server starts to get overloaded what do you do? Do you buy a bigger server and migrate all your data to that new server? That could be incredibly expensive.
With the tiering solution you put several "cheap" databases in front of you "expensive" database to take the brunt of the work. So your web servers (or app servers) talk to a bunch of MySQL servers, for example, instead of directly to the your expensive server. Then these MySQL servers handle the majority of the calls. For example, they could handle all read-only calls completely on their own and only need to pass write-calls back to the main database server. These MySQL servers are then kept in sync via standard replication practices.
Using methods like this you could in theory scale out your expensive server to dozens, if not hundreds, of "cheap" database servers and handle a much higher load.
Database tiering is just a specific style of tiering. There are also application tiering and service tiering. It's a form of scalability.
What exactly are you asking? This question is rather vague.
This is a PDF from a course at Ohio State. What it discusses is a bit over my head, but hopefully you might understand it better.