<!--toc-->
|
|
## 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 you should
|
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 minute. This is the firs thing you should do.
|
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 find what pages are visited
|
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](/sql/cppdb) gives you both
|
for free - use it.
|
|
And the last thing of course it to cache frequently used
|
database objects that their retrial may be complex, like
|
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 solve them.
|
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 me valid only for a few requests.
|
user as it may be valid only for a few requests.
|
|
So it would be good idea to cache entire page and use
|
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 in compressed when and user specific
|
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 Java-Script code and some
|
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](/wikipp/en/page/secure_programming#Client.side.storage.considerations..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][prev]
|
| [Top](#maincontent)
|
| [Serving Static Files][next] →
|
|
[prev]: /wikipp/en/page/secure_programming
|
[next]: /wikipp/en/page/cppcms_1x_serving_static_files |
