Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I'll to my best to help here. The MysqlTuner report implies that you have 4GB of RAM in this VPS, so my suggestions are based on that.</p> <p><b>query_cache_size</b> - This is the amount of RAM MySQL can use to cache the results of database queries. Results stored in the query cache are returned much faster than normal selects, so this variable can significantly speed things up (more so than any of the other suggested changes). </p> <p>Exactly what the correct value is for you will take some experimentation. You currently have this set to 8M. If you have 4GB of RAM in this box I'd start at 64M, increasing to 128M and then 256M if required. After each change, leave things for a few days and then run MysqlTuner again and compare the percentage for 'Query cache efficiency' to what it was before. For a server mainly hosting 5 Wordpress blogs I doubt you'd see any improvement beyond 256M, and I wouldn't recommend going beyond an eighth of your total RAM.</p> <p>Personally I find Munin (a free server monitoring tool) quite handy for keeping an eye on this sort of thing, as it will graph the cache hits vs. other queries.</p> <p><b>tmp_table_size</b> - for some complex queries (particularly those using GROUP BY or complex sorting), MySQL needs to first create a temporary table containing the data and then run some operations on it in order to create the result set. It will try and create these temp tables in memory, as this is much faster than creating them on disk; but for large result sets this isn't always possible. tmp_table_size controls this threshold.</p> <p>I can't imagine Wordpress is doing any hugely complex queries so I wouldn't go overboard with this one. MysqlTuner is suggesting a value greater than 32MB, so start with 64M and see how this affects the 'Temporary tables created on disk' value after a few days. Set max_heap_table_size while you're at it as it suggests.</p> <p><b>thread_cache_size</b> - Wordpress doesn't use persistent connections by default (which is good), so each request is making a new connection to your database and then closing this once the page has been generated. This overhead is not significant, but using thread_cache_size allows MySQL to reuse these connection threads which will help a little. </p> <p>I'd go with the suggested value of 4 which I'd imagine will be fine unless you get a high number of concurrent users.</p> <p><b>table_cache</b> - I'm a little hazy on this one, it seems to relate to MySQL's cache of table structure. I'd go with 128 for this.</p> <p><b>innodb_buffer_pool_size</b> - this is the amount of memory MySQL can use to cache indexes and data for InnoDB tables. This one puzzles me a bit as I don't think Wordpress uses InnoDB at all - do you have some other sites on this server as well? </p> <p>To answer your other questions, the configuration after <code>[mysqld_safe]</code> only apply to the MySQL daemon in safe mode, rather than MySQL overall, so that's why some of the variables are duplicated. If you do change innodb_buffer_pool_size, you'll want to change the first one. The variables not in the file you can add, yes, but add them above the [mysqld_safe] block for the same reason.</p> <p>Lastly, since you're in the mood for optimising, if you are not already using a PHP bytecode cache such as <a href="http://www.php.net/apc" rel="nofollow noreferrer">APC</a> then this is worth exploring. APC can give some significant speed improvements to PHP apps without any negative effects.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload