Main  /  Edit  /  History  /   /  Users Area

Designing High Performance Applications

The Basic Rules

Cache Is Everything

  1. Cache Frequently Used Pages
  2. Cache Database Connections
  3. Cache Prepared Statements
  4. Cache Frequently Used Objects
  5. If you cache more? Do it.

Most of pages displayed by any web site look the same for almost all visitors. So why should you generate them each time for every new visitor?

The page level cache is the most efficient cache. If most of your visitors are not "registered users" then the first thing you should do is:

if(!session().is_set("username")) {
  if(cache().fetch_page("/this/page/url"))
    return;

  cache().store_page("/this/page/url",300);
}

Cache the page for all non-registered visitors for 5 minutes. This is the first thing you should do.

Of course the next thing is to find what pages are visited frequently by whom and cache them.

The Database

The next stage is the data-base. Remember that databases are fast - they are designed to be fast. So it may be a very good idea to take a look on the data base query and make sure it is optimal.

Make sure that you use connection pooling and prepared statements caching. CppDB gives you both for free - use it.

And the last thing of course it to cache frequently used database objects as their retrieval may be complex, like for example global site settings.

Profile Your Application

There are many good tools like valgrind that would help you to find the heavy spots in the program.

Try to figure them out, eliminate them, optimize them or solve them.

This would help you a lot to improve the application performance.

Client Side or Server Side

Think of some stuff you can "outsource" to the client side. For example 20% of your visitors are registered users and you want to show them some user specific data.

It would not be wise to cache the entire page for the user as it may be valid only for a few requests.

So it would be good idea to cache the entire page and use some Ajax to fetch user specific data. The entire page would be cached and compressed and user specific data would be loaded separately and much faster.

You can also modify the page according to user's requirements using JavaScript code and some session information exposed to cookies.

So think what can be done on client side and what have to be done on server side, draw a line and follow it.

Remember the client side scales virtually unlimitedly.

Scaling Up

Even if you have very efficient application you will need to be able to scale horizontally at some point - add more hardware.

There are several tools that would help you.

Protocol

Modern fast web servers like nginx and lighttpd can communicate with distributed application backends using FastCGI or SCGI protocols.

It would be best choice as it would allow to spend entire CPU power of a node on the application and not on the web server.

Use Client Side Session Storage

The client side session storage is the most scalable type of session storage, it scales linearly on the size of the hardware.

Client side storage is suitable for most of cases, but you still need to remember about the replay attack. You can always switch for specific critical points to the server side and then go back to the client side once again.

Caching Server

CppCMS provides a memcached like sever cppcms_scale.

But unlike memcached, cppcms_scale has following unique features:

  1. It supports trigger based cache invalidation
  2. It supports two levels of cache
  3. It provides distributed session support as well.

Let's take a look on each point:

Triggers: CppCMS has complicated cache model were keys and triggers may be seen as bipartite graph. Usually cache can be used locally, but when you need to scale up you need to share it. cppcms_scale works as cache server and allows to share the cache over the network.

L1/L2 Cache: CppCMS allows to have both remote and local cache for frequently used items. If some item is used very frequently it can be cached on the side of the cppcms_scale client and instead of fetching entire object, it makes it possible to check if it is up-to-date. If it is only "confirmation" is sent over the network reducing the latency of the cache and the amount of work that should be done.

Session Sharing: cppcms_scale can handle distributed session storage as well making it easy to use fast server side session storage.

So if you need to scale up use cppcms_scale for this purpose.


Secure Programming with CppCMS | Top | Serving Static Files

About

CppCMS is a web development framework for performance demanding applications.

Commercial

CppCMS is available under Open Source and Commercial Licenses.

For more details, visit our website: commercial.cppcms.com

Support This Project

SourceForge.net Logo

Поддержать проект

CppCMS needs You


Navigation

Main Page



Valid CSS | Valid XHTML 1.0