Question

Magento has a compilation mode in which you can compile all files of a Magento installation in order to create a single include path to increase performance.

Links for magento compilation mode:

  1. http://www.magentocommerce.com/wiki/modules_reference/english/mage_compiler/process/index
  2. http://alanstorm.com/magento_compiler_path

In my current shop setup, I have already configured apc to be used as an opcode cache, and am leveraging its performance gains. http://www.aitoc.com/en/blog/apc_speeds_up_Magento.html

My question are the following:

1) Is there any advantage of using apc over magento compilation mode, or vice versa? I have a dedicated server for magento, and am looking for maximum performance gains.

2) Will it be useful to use both of these togather? Why, or why not?

Was it helpful?

Solution

Not the same thing, and yes you can use them at the same time.

APC stores compiled versions (as in compiled into op-code) of php scripts, thus saving time for the interpreter to compile each script first before it can be run.

Magento's compile (as you already stated) is just concatenation. It would still need to be compiled to op-code when it is run. The name 'compile' in magento is really misleading.

Using APC in conjunction would thus mean the concatenated magento classes would be cached as compiled op-code.

OTHER TIPS

As @ProxiBlue has already said in his answer, both can be used in conjunction. However, beyond that, another concern was, whether using apc would make the compilation redundant.

So I verified the scenario with some siege load tests and overall, there is definite improvement happening.

Here are the test results

siege --concurrent=50 --internet --file=urls.txt --verbose --benchmark --reps=30 --log=compilation.log

-------------|-------------------------------------------------------------------------------------------------------------------------| 
|Compilation |Date & Time         |Trans  |Elap Time  |Data Trans  |Resp Time  |Trans Rate  |Throughput  |Concurrent  |OKAY    |Failed |
-------------|-------------------------------------------------------------------------------------------------------------------------| 
|No          |2013-09-26 12:27:23 |   600 |    202.37 |          6 |      9.79 |       2.96 |       0.03 |      29.01 |    600 |      0|
-------------|-------------------------------------------------------------------------------------------------------------------------|
|Yes         |2013-09-26 12:34:05 |   600 |    199.78 |          6 |      9.73 |       3.00 |       0.03 |      29.24 |    600 |      0|
-------------|-------------------------------------------------------------------------------------------------------------------------|
|No          |2013-09-26 12:59:42 |  1496 |    510.40 |         17 |      9.97 |       2.93 |       0.03 |      29.23 |   1496 |      4|
-------------|-------------------------------------------------------------------------------------------------------------------------|
|Yes         |2013-09-26 12:46:05 |  1500 |    491.98 |         17 |      9.59 |       3.05 |       0.03 |      29.24 |   1500 |      0|
-------------|-------------------------------------------------------------------------------------------------------------------------|

There was a certain amount of variance; however, the good thing was that there was always some improvement, however miniscule be it.

So we can use both.

The only extra overhead here is disabling and recompiling after module changes.

Once the site is stable (non-frequent updates) use both, however extensions and custom code can cause incompatibilities with compilation so you need to be careful about them. On a site without any extended caching compilation helps immensely. Nothing much more to say really.

Licensed under: CC-BY-SA with attribution
Not affiliated with magento.stackexchange
scroll top