CppCMS Blog :: Cache

CppCMS 0.0.4 Released

Version 0.0.4 of CppCMS had released.

It includes optimizations required for using it in embedded systems.

Normal Embedded Build:

Caching is completely removed. Small memory footprint is very important for embedded system thus, caching stuff in memory is quite useless.
Zlib compression are removed – it removes dependency on boost::iostreams, zlib and bzip2 libraries.
Removed mod-prefork.
Removed dynamic templates loading — this feature requires export of symbols to binary and increases its size in order to make RTTI work. Thus, all templates should be statically compiled into the binary.

Embedded CGI Mode:

FastCGI and SCGI APIs are removed
Mod-thread and mod process are removed including all thread pool facilities
Changes in files based session backend to work properly with CGI mode including garbage collection (sessions that had time-out).

Downloads are avialable from Sf Project Page.

more...

Preparing to Beta 2...

What expected in the next beta version:

Now CppCMS is really ready for serving high load sides, thanks to new distributed cache module based on Boost.Asio.

Several CppCMS processes running on different computers can share same cache distributed over several TCP/IP cache servers.
Staticly typed template system that fully integrated with the framework that allows:
- "Django style" template inheritance.
- Powerful extendsions abilities using C++ code directly.
- Static compilation with generated templates code or loading templates as external shared objects.
- Creates a potential for future "forms/widgets" integration.
Various bugfixes and code cleanup.

Possibly included: form validation and generation modules.

to be Continued…

more...

Caching System: Internals

One of the latest implemented features of CppCMS is a caching system.

Each cached entry is stored using:

Unique key that defines the entry
An actual data
Entry lifetime period.
The set of triggers — this is a feature that is not available in many cache system like memcached.

For example: main page that displays 5 recent posts may have a key main_page and triggers: post_123, post_124, … , post_128. More then that, each time, during page build, when you fetch some cached data, like a sidebar or set of options, their sets of triggers are automatically added to the set of triggers of the page you build.

For example, when the page is created and sidebar block is fetched from cache all its triggers are automatically added: if sidebar depends of options, then trigger sidebar and options will be automatically added to triggers of main_page.

Thus, when certain trigger is risen, all pages that depends on it are automatically trashed. This makes a cache system quite powerful and easy to control correct data representation.

The developer is expected to create a rational model of data/triggers that represent the relations between parts of internal data and rise these triggers when committing changes to database.

more...

API Changes and mod-prefork

There have been lot of work in recent weeks in order to make deep internal changes in the framework. Now they include:

Transparent support of 3 web server APIs: fastcgi, cgi and scgi.
Support of new mod prefork that allows safer management of worker processes.
Implementation of a cache that is shared between forked processes.

more...

CppCMS vs WordPress

Setup

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...

Patch For WP-Cache-2 plugin

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.

Links:

N.B.: The full benchmarks coming soon

more...

The Roadmap to The First Beta Version of CppCMS

After quite a long period of development I had decided to get prepared to first public beta release of CppCMS.

The major components of this blog and the framework I want to introduce in first beta are following:

Implementation of Django style templates inheritance, filters (done 70%)
Introduce powerful cache system (done 100%)
Replace SOCI by LibDBI (done 100%)
Improve blog: true markdown, LaTeX equations, categories etc. (done 100%)
Write Documentation (done 20%)
Migrate my Hebrew blog from Word Press to CppCMS (done 100%)

There are lots of work to do, but CppCMS now looks much mature then before.

more...

Next Step - Caching

As we had seen in previous article, the benchmarks had shown an ability of CppCMS to produce about 630 compressed pages per second and an output of about 20Mbit/s. Is this enough?

For most of cases it is… But as we had seen I want to use every cycle of the CPU as smart as I can. Even, if the model I had suggested, was able to show "a prove of concept" there is an important point that was missed: "Why should I create same page so many times?"

Caching

This is the next logical step in the development of high performance web development framework.

First of all we should understand a requirements of the caching system:

Efficiency
Support of "dropping cache on update"
Support of drop the cache by timeout
Work using three models: single process cache, shared cache between processes, shared over the network.
Support of caching on entry page level and single view level as well
Transparent storage of compressed content

Lets describe each one of them:

more...

The Goals

When I started working on this project, many were (and still are) extremely skeptical about its future. Many questions were asked, like: "Are you masochist? Who you think will ever use it? The hardware is cheap, we do not need such things!" etc.

In this post I'll explain my point of view and I'll show why "C++ Web Development Framework" is more then just "yet another crazy idea of another geek"

more...