When having many (+100) drupal sites on a server with a common codebase, what is a good setup to achieve good APC performance?

a) Increase APC memory to something really large (>10GB)

b) Less sites per server

c) Drupal multisite

d) Pseudo multisite. Shared Drupal core symlinked to each site.

e) ?

I would prefer option d). Will APC cache the absolute path to each file?

  • What do you mean my "common codebase"? Do you have 100 sites with the same Drupal tree, but not actually sharing any of the files at runtime?
    – mpdonadio
    Mar 20, 2013 at 18:32
  • shared modules and theme, per site files and db Mar 20, 2013 at 19:57
  • I still don't understand your setup. Are you true multisite? Or are you trying to make that decision? Right now, this question is really close to being off topic (general server config is off topic). I'm trying to figure out if this can be made more on topic.
    – mpdonadio
    Mar 20, 2013 at 21:36
  • I'm looking for advice choosing a well performing file structure for a project where there's a lot of sites sharing exactly the same code (core, theme, modules) but with different domains/databases. Since one of the obvious choices is Drupal multi-site it felt relevant to post on drupal/stackexchange. Mar 21, 2013 at 13:02
  • 1
    Cool, when I get a chance I am going to take a pass a a rewrite to clarify this.
    – mpdonadio
    Mar 21, 2013 at 14:28

1 Answer 1


I think the key here is to limit the total number and size of your PHP scripts. You've already taken the first step by running them off a shared codebase. The next step is to make sure you're not duplicating modules or themes that are shared. For example, you should have sites/all/modules/views, not sites/site1.com/modules/views and sites/site2.com/modules/views.

Once you've done that, I can't imagine that the total size of your php files would be more than, say, 200MB.

The next step is to configure APC and figure out exactly how large all of your php scripts are. For a production server, I like to permanently cache my php scripts. Place the following in your apc.ini file:


Note the apc.shm_size=512 setting. We've purposely set it to something much larger than we think we will need. Once this is set (and you've restarted Apache), you should hit every single php script on your site so APC caches each of them. This includes the module admin page, views, theme pages etcetera for each of your sites. Once you're done with that, load up the apc.php script and see how much memory APC is actually using and adjust the apc.shm_size downward accordingly.

I have detailed instuctions on configuring APC for Drupal on Github.

  • Thanks for taking the time for such a detailed answer. My question is regarding which system design will perform better. Mar 20, 2013 at 20:13
  • 1
    Right... you say, "... 100+ Drupal sites on a server with a common codebase" which implies that you're using Drupal's Multisite functionality already. So I wasn't sure what you meant by Option C in your list. To be clear though, my recommendation is to use 1. Drupal's built-in multisite functionality, 2. An APC Memory limit of around 200MB (Or whatever is required by your total PHP Scripts) and 3. The other APC configuration params outlined above. Let me know if that helps. Mar 20, 2013 at 20:28
  • Not sure if I agree with the apc.ttl setting. APC isn't LRU, so when the cache is full, the entire thing gets emptied when it is full with this setting. Ideally, you will provision for enough memory, but periodic swells can happen.
    – mpdonadio
    Mar 21, 2013 at 14:34
  • You may also want to consider an apc.filter statement to exclude admin includes. You can save memory this way.
    – mpdonadio
    Mar 21, 2013 at 14:36
  • Agreed. A filter on certain admin-only scripts would obviously save memory. But from site to site, what qualifies as an admin script can vary and the memory savings is probably in the couple dozen megabyte range (just guessing). As far as the ttl, I've seen real gains by permanently caching everything. I'm sure you're right that there could be a periodic swell, but in the real world, I've never had that happen. At any rate, I deleted the my logic behind the settings because I realized I was getting into a server config discussion which wasn't appropriate. Mar 21, 2013 at 14:46

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.