System performance

The system features unique performance optimization opportunities. The platform may be compared to the fastest cutting-edge MVC frameworks and has left behind most of CMSes or CMFs, remaining flexible and both user- and developer-friendly.

How did we manage to achieve such performance results:

1. Splitting data reading and writing between models and objects has allowed to increase the database operations performance and minimize the issues due to low ORM performance.

2. Update package builder reduces the number of require instructions: 100-130 require instructions have been replaced with 3-5 packages and some classes. This boosts the performance and to add to this, the whole operation performs even faster with bytecode cache enabled.

3. We are thoroughly analysing the code execution, tracing and profiling the implementation stages, which allows us to spot and optimize the troublesome areas.

4. Powerful cache system (Memcached used as backend):

configuration files caching;

ORM object structures caching;

caching of the template output based on the data transferred;

multilevel caching of the Block manager operations:

page functioning;

blocks configuration;

data processing results;

template rendering results.

5. Trigger mechanism allows to invalidate cache, templates get invalidated automatically based on the data transferred.

6. We are using our own Tree class optimized for the fastest processing of multi-level tree-like structures.

7. Our code is laconic and specific.

8. Virtual models allow to reduce the amount of code for implementation of the data operation logic and perform standard operations.

Please have a look at the ‘Hello World’ performance test results (the test may be found in demos of the RC2 platform version and higher):

Our system performs faster in a more complicated testing environment as well:

Below are the results of the platform testing as opposed to those of other systems:

The sample ‘Blog’ test results as shown in demo-presentations by the developers of the fastest known frameworks, such as prominent YII and less well-known FatFree and DooPHP micro frameworks.

The first test revealed the weak sides of the contemporary frameworks by the number of connected files and the complexity of executable commands launching the application. Herewith, it is important to mention that the ‘Blog’ test run on DVelum is much more complicated than the same test performed on other platforms. Instead of just listing the articles, the Blog’s main page shows three posts from each of the categories, which considerably increases the load.

No cache being used has most seriously affected YII, optimized for storing cache in APC, which was not presented on the stand. We used eaccelerator instead.

Another test spotted the weakest points of the modern CMSes (LiveStreet and Wordpress), now using cache in memcached. DVelum architecture shows off its advantages, now leaving behind its rivals thanks to the Tree class and a more effective cache system.