Designing High Performance Applications
The Basic Rules
Cache Is Everything
- Cache Frequently Used Pages
- Cache Database Connections
- Cache Prepared Statements
- Cache Frequently Used Objects
- 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:
- It supports trigger based cache invalidation
- It supports two levels of cache
- 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 →
