Posts in category ‘Benchmarks’.
I had compared two blog systems: this one and WordPress 2.5 with a patched WP-Cache-2 addon. I used following configuration:
- Web Server lighttpd 1.4.13
- Interface FastCGI
- PHP 5.2
- Bytecode cacher: XCache 1.2.1
- Database MySQL 5.0
- Caching for WP: WP-Cache-2 with an additional performance patch
- Hardware: AMD Athlon XP 64bit, 1G RAM
- 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.more...
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.
- WordPress native plugin: 450 requests per second
- WordPress patched plugin: 720 requests per second
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 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:
- The each template variable was referenced by and integer key that was generated during compilation of templates.
- The rendering process required from the developer some kind of activity -- update content values according to requests from rendering engine.
- 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:
- Dynamic typed variable values using boost::any. They allow assigning of any kind of objects to the variables and rendering them to the templates using custom engines.
- All the variables are references by their names.
- Content now has hierarchical structure when each variable can include list of items or callbacks that allow one step template rendering.
- The design of the engine is now much more modular.
Additional features I'm still working on them are:
- Support of different filters like "html escaping", "urlizing" etc.
- Support of custom filters, including filter chains.
- Support of localization and translation.
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.
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
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.more...