Home  /  RSS  /  RSS Comments  /  RSS for Benchmarks  /  Enter

Posts in category ‘Benchmarks’.

CppCMS vs WordPress

Monday, June 9, 2008, by artyom ; Posted in: Benchmarks, Framework, Cache; 7 comments


I had compared two blog systems: this one and WordPress 2.5 with a patched WP-Cache-2 addon. I used following configuration:

  1. Web Server lighttpd 1.4.13
  2. Interface FastCGI
  3. PHP 5.2
  4. Bytecode cacher: XCache 1.2.1
  5. Database MySQL 5.0
  6. Caching for WP: WP-Cache-2 with an additional performance patch
  7. Hardware: AMD Athlon XP 64bit, 1G RAM
  8. OS: Linux, Debian Etch 64bit.

I prepared two blogs that were filled up with 1000 articles each. Each article had 10 comments, all the articles were organized in 10 categories in each blog.


Patch For WP-Cache-2 plugin

Friday, June 6, 2008, by artyom ; Posted in: Benchmarks, Cache; 0 comments

I'm going to run a heavy benchmarks comparing WordPress -- the blog system I know very well, with CppCMS based blog -- the system I had written.

The new caching system that was developed for CppCMS is quite smart, it stores the entry pages twice: original and gzip compressed. On heavy loads, this allows serving pages significantly faster because only thing that should be done is to push html or compressed html page directly from the cache. Otherwise, gzip compression (even fastest) would take lots of resources and reduces a preformace of the system.

When it comes to benchmarks, I had discovered that WP-Cache-2 plugin does the job well, but it caches only html version of the file, thus, even if the page is cached it still must pass a compression by Apache's mod_deflate or by PHP engine itself.

I had patched this plugin and now it stores two versions of same page: an original and compressed. and was able to get 60% performace improvement.

So after this patch I can feel that the benchmarks would be proper, because without it this would be incorrect to compare time required for fetching a cache with the time required for compressing entry page.


N.B.: The full benchmarks coming soon

New Templates System

Sunday, March 23, 2008, by artyom ; Posted in: Progress, Benchmarks, Templates; 8 comments

New templates system was introduces to the CppCMS framework. It is based on ideas of dynamic typed languages inside static typed C++.

The original template system had several problems:

  1. The each template variable was referenced by and integer key that was generated during compilation of templates.
  2. The rendering process required from the developer some kind of activity -- update content values according to requests from rendering engine.
  3. The values of the entries where limited to string, integer and boolean values.

In any case, the design of the first template system was just unacceptable, thus new template system was build.

It introduced following features:

Additional features I'm still working on them are:


SOCI or DBI, stage 2

Monday, March 10, 2008, by artyom ; Posted in: Storage, Benchmarks; 2 comments

Discussing soci performance with its developers I had found that soci is compiled without any optimizations by default.

So, after recompiling soci with -O2 option I've got much better results. Simple comparison of dbixx and soci had given very close result. I had run my tests once more and got following results -- pages per second (no gzip): DB soci dbixx -------------------- MySQL 710 800 Sqlite3 550 410 PgSQL 385 430

We can clearly see that for MySQL and PostgreSQL dbixx is still faster in about 10% however in case of Sqlite3 dbixx is significantly slower (25%).

So it seems to me that both solutions are quite reasonable to use without clear advantage of one over another.


Saturday, March 8, 2008, by artyom ; Posted in: Storage, Benchmarks, Berkeley DB; 8 comments

One of the problematic issues in writing cross-SQL code is an API that differs from one SQL to another.

There are two open source libraries that provide unified API

  1. soci -- C++ library.
  2. dbi -- C library.

At the first point I had chosen soci as native solution of C++ programmer. After running some benchmarks on the new version of this blog I had found 20% performance reduction for MySQL database. But I also remembered that there should be negligible difference between MySQL and Berkeley DB. This was mostly due to incorrect design of my BDB database layout I had done.

That had seem to be strange and I stared benchmarking the system more and more.


next page

next page