Hi everyone,
Started to enjoy BOA (2.0.1 HEAD, with already 2 live sites on it). After pretty steep learning curve, still some of performance questions remain.
There are plenty of performance oriented services installed with Barracuda, such as php-fpm, nginx, redis, memcached etc.
I am talking just about Drupal 7 platform, the one, which is included and updated with Octopus. One of the cool features - symlinked modules to all included platforms. There are more performance oriented included with D6, but in D7 just few.
Ones I am interrested most are (probably in order of importance):
http://drupal.org/project/apc
http://drupal.org/project/redis
http://drupal.org/project/memcache
http://drupal.org/project/filecache
If it was simple D6 installation on simple server, I would sellect just APC as opcode cache + APC as user cache and configure Boost, but now...
Questions: Since BOA is not so straightforward with configuration and pretty different from even simple Aegir installation
1. Are there some manuals and instructions, how to enable APC, redis, memcache, filecache for hosted sites?
2. Enabling included with BOA agrcache breaks site, seeing everything without css, even after clearing cache. What I am doing wrong?
3. I cannot adjust js and css aggregation settings on /admin/config/development/performance, they are constantly enabled, is it ok?
4. Which of those cache techniques should I start first, APC, redis or memcached? VPS specification: openVZ, 2Gb RAM, 1 CPU core, Debian 64bit, Percona mySQL and everything else from BOA HEAD 2.0.1 on a mediocre box, it is still a "value" type VPS.
5. Below are results from apachebench, when accesing index page in maintenance mode, as I understand from proceses seen with "top" command, top 4 of them were "php-cgi" and consumed ~90% cpu, so no cache enabled by default, right?
ab -n 1000 -c 10 http://sitename.com/
Server Software: nginx/1.0.11
Server Hostname: sitename.com
Server Port: 80
Document Path: /
Document Length: 5309 bytes
Concurrency Level: 10
Time taken for tests: 16.256 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Total transferred: 5856000 bytes
HTML transferred: 5309000 bytes
Requests per second: 61.52 [#/sec] (mean)
Time per request: 162.557 [ms] (mean)
Time per request: 16.256 [ms] (mean, across all concurrent requests)
Transfer rate: 351.80 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 3.4 0 39
Processing: 36 162 24.2 160 266
Waiting: 21 162 24.4 160 266
Total: 50 162 23.5 161 266
Percentage of the requests served within a certain time (ms)
50% 161
66% 169
75% 175
80% 180
90% 191
95% 203
98% 222
99% 227
100% 266 (longest request)
Thank you for your patience.
Comments
Found out answer to "3rd"
Found out answer to "3rd" question, but couldn't make any of the D7 cache modules to work, seems, that global config is made for D6 platform, heavily on Cache module, which does not exist for D7
Ok, if everything is that complicated, how to enable just Boost? None of procedures on drupal.org sites work this time :/
drupal+me: jeweler portfolio
We plan to add some tested
We plan to add some tested caching backends also to D7 by default and replace Cache module with Cache Backport (D7 to D6) for D6 sites. It is also possible that we will use just Redis and remove Memcached by default, because there are too many moving parts for any average BOA one-server system. However it will be probably in BOA 2.0.3, it is unconfirmed yet.
Note: you don't need filecache with BOA, since there is far better Speed Booster, enabled by default. You also don't need APC as a cache backend, because while it sits inside PHP, unlike Redis or Memcached, which always add some extra work because of the way they are connected with Drupal/PHP backend, it is not as good and reliable as Redis. Plus, adding chained caching as we do currently, with Redis/Memcached/SQL working in parallel, is good only for big sites, which really require this level of redundancy, but at cost of extra processing, because every cache record is written in three caches and only fetched from the first in the chain. We want to make it simpler and faster, hopefully by unifying D6 and D7 caching backends.
Finally, Boost works out of the box for D6 and D7 platforms. Just enable the module. Note however, that Speed Booster cache will often take precedence, so you should disable Speed Booster if you prefer Boost.
if you wish to disable CSS/JS aggregation and/or caching, there is a how-to: http://omega8.cc/node/115
You just answered most of the
You just answered most of the questions.
Also: do you have plans to make some kind of configuration to disable this cache chaining as (in my case) low-end servers simply do not need this and have an option leave for example just Speed Booster and Redis?
And what is the way to disable and uninstall Memcached and APC user caches and at the same time not ruin config?
drupal+me: jeweler portfolio
*And what is the way to
*And what is the way to disable and uninstall Memcached and APC user caches and at the same time not ruin config on PRODUCTION, not dev. sites?
drupal+me: jeweler portfolio
When simple caching (probably
When simple caching (probably just Redis) without any chaining will be introduced, it will be already as simple as possible.
Also, you can easily disable Redis/Memcache caching per site or per platform and you don't need (and you shouldn't!) uninstall anything. Juts follow the docs: http://omega8.cc/speed-booster-cache-boost-and-advagg-108 and look for
cache/NO.txtcontrol file related how-to there.The same way you can easily disable Speed Booster per site or per platform - and it is explained in the same article.
However, you can't (and there is no reason to do that) disable APC, as it is used only as a opcode cache. of course you can always disable it in
/opt/etc/php.inidirectly, but I don't see any reason to do that.Also, you can disable all caching and aggregation on the fly, without using any control files: http://omega8.cc/how-to-disable-all-caching-and-aggregation-115
Lastly, note that everything I wrote about here is explained in detail in our docs and linked in the welcome e-mail sent to your e-mail after you installed your Octopus instance. It is really a good idea to read this welcome e-mail :)