15

I have Drupal 7, apc with php-fpm and apache behind varnish and512 MB RAM.

I measure page execution time with devel module.

Database query time is low (62ms) compared to page execution time which is 854 ms. That means there is problem with PHP and APC settings.

My current settings are just

apc.shm_size = 64
apc.stat=1 

How I can improve?

What are the best settings for Drupal given the above configuration?

Thanks

3 Answers 3

12

We run in a SVN push environment so we only clear the apc file cache with a script.

APC settings:

apc.ttl=604800
apc.user_ttl=3600
apc.shm_size=192M
apc.include_once_override=1
auto_globals_jit=Off
apc.num_files_hint = 2048

apc.stat_ctime = 0
apc.file_update_protection = 2
apc.stat = 0

PHP Script:

<?php
$return = apc_clear_cache('opcode');
echo var_export($return);

604800 = 1 week.

After this, getting xdebug/xhprof up and running and doing a cache grind of the site should let you know what's slowing down the site. In short analyzing the cache grind output is the best way to speed up Drupal. Below I'm listing what patches and modules we use to speed it up; in your case it will be different most likely.

Drupal 6 Specific Answer Below

Once you get past this point and realize the APC isn't going to give you what your looking for, switch to pressflow and give these patches a whirl:

Also try some of these modules as they improved our sites speed in a big way:

5
3

This is one of those "how long is a piece of string questions".

What is good for a high-volume site may not be the same for a low-volume site with a lot of modules, and may not be the same for a medium-volume site with only a few modules enabled. Other sites running on the server may also be eating into the memory that APC has available.

My starting point is

apc.enabled=1
apc.shm_segments=1
apc.shm_size=64
apc.ttl=7200
apc.user_ttl=7200
apc.num_files_hint=1024
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.enable_cli=1
apc.rfc1867=1

I then adjust the settings for the server, but again, there is no one size fits all set of settings.

Find apc.php (probably located at /usr/share/pear/apc.php), and install it in the DOCROOT for your Drupal install. Lock it down to your IP address via Apache config. Edit the username/password inside, and then browse to it. You will then see your APC stats.

Reconfigure the shm_size parameter to minimize cache misses. Ideally, you want to give it just enough memory to never have a cache miss for a file, plus some additional memory for the APC user cache.

Optimize TTL to prevent cache churning. If you aren't editing files, you can bump up this number.

enable_cli is handy when you use drush a lot, so that drush uses the cached files from APC.

rfc1867 is handy for file uploads.

I also noticed the php-fpm in the title. This complicates matters, and is really beyond the scope of Drupal Answers. You may get better responses at Server Fault, as a lot of the system configuration settings don't pertain to Drupal directly.

8
  • where is some good tutorial that explains in easy language what each settings is doing, like ttl, segments, etc? how cli helps with drush?
    – john
    Commented Oct 4, 2011 at 17:11
  • Could you please explain how "traffic I get, what else is running on the server, what modules I have installed, etc." affect the settings? thanks
    – john
    Commented Oct 4, 2011 at 17:13
  • these settings above did not help a lot. Should I try xhprof to see what happens with php?
    – john
    Commented Oct 4, 2011 at 17:16
  • All of the APC settings are described at php.net/manual/en/apc.configuration.php
    – mpdonadio
    Commented Oct 4, 2011 at 17:17
  • 1
    @MPD > enable_cli is handy when you use drush a lot, so that drush uses the > cached files from APC. Actually, the cli is a separate process and doesn't share its apc cache with apache, or even between calls to drush. Commented Jan 21, 2012 at 8:31
2

APC just improves loading and parsing of PHP files. A large part is also the execution time itself. There are many factors that can increase the execution time, including bugs (especially cache related bugs), internal overhead (e.g. drupal_alter(), module_implements()) and so on.

As you asked and was already suggested by mikeytown2, I'd use xhprof (I prefer it over xdebug these days as it provides direct, quick access to the result and requires no additional tools) to find out where your bottlenecks are.

I've recently written two blog posts about using xhprof within Drupal and typical bottlenecks, which you might find interesting.

1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.