I am about to upload my website onto a VPS.
It is a classifieds website, where all data is stored in MySql and Solr.
I wonder if when using MySql:s cache, the server will slow down?
Ie, if somebody makes a search for the first time, and MySql is to cache the query, will the caching make the server slower than if it would not cache anything?
After the caching is done I know things will improve in terms of performance...
But I would like to know if I should even use the cache or not, what do you think?
Thanks
I've never run into a situation where Mysql caching was detrimental to performance. The first time a query is run there is no performance hit when the query is written to Mysql's memory cache.
The only significant resource used when query caching is memory. The more memory you configure Mysql to use the more it will cache.
But to get the real answer you need to test it. Gathering metrics is the only way to get a real answer for your particular situation.
There are a variety of caching techniques, some of which might be more useful than query caching to your particular situation.
Related
I've got a huge TTFB of around 6.5 seconds when the whole load time of my site is around 7 seconds
I've done the basics to try and reduce this - updating to the latest version of PHP, switched to https so I can enabled HTTP/2 where possible and enabling caches where possible such as OpCache which I've checked is up and running correctly with my phpinfo which you can see here
https://www.camp-site-finder.com/phpinfo.php
This and setting up caching plugins such as W3 Total Cache has reduces the issue but on search queries there still seems to a large wait
As you can see here for example if you check the Network tab of developer tools
https://www.camp-site-finder.com/?sfid=48&_sf_s=england
So my question really is how can I debug this, are there tools out there to test what is taking so long or is this a non issue? Is that wait period really acceptable? Any advice or pointing me in the direction of some research I could do I'd be hugely grateful.
If a search is slow, it is almost always a bottleneck of the database.
Which DB-Server do you use? I see MySQL and SQLight extensions active, but I guess it is the former. But do you use MySQL or MariaDB? You could try MariaDB or some other drop-in replacement for MySQL (like Percona) which should increase DB performance.
Also you should log slow queries in the DB server, so you can check which DB queries is that slow. I guess you might have to many joins. In that case you should need to restructure the database.
Additionally you could try do follow some basic db performance tips like these:
Indexing
Assigned memory
etc.
Just google for 'increase MySQL perfomance' and you should find plenty of adwise.
My server's load average shoots up to 150 (and the server is actually quite powerful 8cpus too much RAM etc), and the cause of that is MySQL taking all of my CPUs 700% !
I'm aware of Apache/MySQL tuning to meet better performance, I've done some, it worked a little bit but nowhere near the results I need.
All my problems are coming from this scenario: when website file based cache invalidates, PHP scripts run to remake those cached areas, generating MySQL queries (quite heavy queries, did some optimization on them too but they're still taxing on MySQL). That's quite normal, the problem is when a 100 people hit the website at that precise time when cache is invalid so they generate the same query 100 times - which makes MySQL sink all the way down with my server.
Are there any MySQL solutions to prevent the duplication of the same query? or is there any other technique to fix that special scenario?
I my opinion you would need another marker if rebuilding the cache is already in process, so that only one update query is done and until finished the old cache is used.
That would trigger the expensive query's just once.
For a better answer please explain how you invalidate your cache.
Whenever I needed to cache some information I relied on timestamps and MySQL, storing the data into a database and fetching it that way. I just read about APC.
APC is so much easier but is it worth converting my previous cache methods to switch to APC besides just less SQL's going through and cleaner code?
If you already have a database running and doing most of your things the first step to improve your performance is to peroperly tune the database. MySQL, properly configured, is very fast.
Obviously at some point in time it isn't fast enough anymore and one needs further caches. When caching one thing to consider is that your data might not be consistent anymore. Meaning that you might update data in your primary store (the database) but others stll read an outdated cache entry
Now you've mentoned APC as a possible solution: APC is two related but different things:
An opcode cache for the PHP scrip
A shared memorz cache for PHP user data
An opcode cache works by storing the compiled PHP script in memory. So when requesting a site the PHP interpreter doesn't have to read the file from disk and analyze the code but can directly execute it. This gives a major boost and is always a good thing.
A shared memory cache takes any PHP variable (well, there are a few exceptions ...) and stores it in shared memory in the system, so all PHP processes on the same machine might read it. So if you store the result of a database query inside APC you save time as access to shared memory is very fast compared to querying a database (sending the query to a different machine, parsing it, executing it, sending the result back ...) but as said in the begginning you have to mind that the data might be outdated. And also mind that all data is stored in memory. So depending on the amount of avilable RAM there are limitations in what can be stored. Another big downside of this is that the data is stored in memory only. This means whenerver the system goes down the cache will be empty and everything in there will be lost.
To answer literally to the question, yes. Mysql is not a cache, APC is, and thus, is better.
Mysql is an storage option to implement a cache on top of it, but you are implementing the cache with those timestamps you mention and whatever logic you are doing with them. APC is a complete implementation of a cache, both for data and for code.
Performance wise, accessing the local APC cache will always be infinitely faster than accessing a mysql database. Keyword there is local, APC is not distributed (as far as I know), so if you want to share your cache, you'll need an external cache system, such as memcached.
Generally, APC will be much, much faster than MySQL, so it's well worth the time to look into it and consider switching from one system to the other. And, as you mention, you will be firing less SQL queries to the database.
More information can be found via Google, I came across the following:
http://www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/
I'm running a php/mysql-driven website with a lot of visits and I'm considering the possibility of caching result-sets in shared memory in order to reduce database load.
However, right now MySQL's query cache is enabled and it seems to be doing a pretty good job since if I disable query caching, the use of CPU jumps to 100% immediately.
Given that situation, I dont know if caching result-sets (or even the generated HTML code) locally in shared memory with PHP will result in any noticeable performace improvement.
Does anyone out there have any experience on this matter?
PS: Please avoid suggesting heavy-artillery solutions like memcached. Right now I'm looking for simple solutions that dont require too much time to implement, deploy and maintain.
Edit:
I see my comment about memcached deviated answers from the actual point, which is whether caching DB queries in the application layer would result in a noticeable performace impact considering that the result of those queries are already being cached at the DB level.
I know you didn't want to hear about memcached, but it is one of the best solutions for what you're trying to do. Depending on your site usage, there can be massive improvements in performance. By simply using memcached's session handler over my database session handler, I was able to cut the load in half and cut back on request serving times by over 30%.
Realistically, memcached is a simple solution. It's already integrated with PHP (if you have the extension loaded), and it requires virtually no configuration (I simply had to add memcached as a service on my linux box, which is done in one or two shell commands).
I would suggest storing session data (and anything that lends itself to caching) in memcache. For dynamic pages (such as stack overflow homepage), I would recommend caching output for a couple of seconds to prevent flooding.
A decent single box solution is file-based caching, but you have to sweep them out manually. Other than that, you could use APC, which is very fast and in-memory (still have to expire them yourself though).
As soon as you scale past one web server, though, you're going to need a shared cache, which is memcached. Why are you so adamant about not deploying this? It's not hard, and it's just going to save you time down the road. You can either start using memcache now and be done with it, or you could use one of the above methods for now and then end up switching to memcache later anyways, resulting in even more work. Plus too, you don't have to deal with running a cronjob or some other ugly hack to get cache expiration features: it does that for you.
The mysql query cache is nice, but it's not without issues. One of the big ones is it expires automatically every time the source data is changed, which you probably don't want.
I've written a site CMS from scratch, and now that the site is slowly starting to get traffic (30-40k/day) Im seeing the server load a lot higher than it should be. It hovers around 6-9 all the time, on a quad core machine with 8gb of ram. I've written scripts that performed beautifully on 400-500k/day sites, so I'd like to think Im not totally incompetent.
I've reduce numbers of queries that are done on every page by nearly 60% by combining queries, eliminating some mysql calls completely, and replacing some sections of the site with static TXT files that are updated with php when necessary. All these changes affected the page execution time (index loads in 0.3s, instead of 1.7 as before).
There is virtually no IOwait, and the mysql DB is just 30mb. The site runs lighttpd, php 5.2.9, mysql 5.0.77
What can I do to get to the bottom of what exactly is causing the high load? I really wanna localize the problem, since "top" just tells me its mysql, which hovers between 50-95% CPU usage at all times.
Use EXPLAIN to help you optimize/troubleshoot your queries. It will show you how tables are referenced and how many rows are being read. It's very useful.
Also if you've made any modifications to your MySQL configuration, you may want to revisit that.
The best thing you can do is to profile your application code. Find out which calls are consuming so much of your resources. Here are some options (the first three Google hits for "php profiler"):
Xdebug
NuSphere PhpED
DBG
You might have some SQL queries that are very slow, but if they are run infrequently, they probably aren't a major cause of your performance problems. It may be that you have SQL queries that are more speedy, but they are run so often that their net impact to performance is greater. Profiling the application will help identify these.
The most general-purpose advice for improving application performance with respect to database usage is to identify data that changes infrequently, and put that data in a cache for speedier retrieval. It's up to you to identify what data would benefit from this the most, since it's very dependent on your application usage patterns.
As far as technology for caching, APC and memcached are options with good support in PHP.
You can also read through the MySQL optimization chapter carefully to identify any improvements that are relevant to your application.
Other good resources are MySQL Performance Blog, and the book "High Performance MySQL." If you're serious about running a MySQL-based website, you should be consulting these resources frequently.
mytop is a good place to start. It's basically top for MySQL, and will give you a window into what exactly your DB is doing:
http://jeremy.zawodny.com/mysql/mytop/
Noah
It could be any number of reasons, so it could take a lot of proding. A good first step would be to turn on the slow query log, and go over it by hand or with a parser. You can pick specific heavily used, slow queries to optimize (perhaps ones that hit something unindexed)