Introduction

This article explains what kind of system resources are needed to run small Plone sites, specifically running a small site with few content objects and no dynamicity, e.g. a static company web site and not many hits. 

Content management system Plone and its application server Zope are designed for scalability and flexibility, so fixed resource costs per Plone site might be high compared to other solutions (ASP, PHP).

I am running few Plone sites myself. They are hosted on a virtual Xen server with a real server shared between three clients) Example sites used in this how to are www.redinnovation.com, www.opensourceusabilility.com. The server has one "decent" dual core CPU, 512 MB RAM + 1024 MB swap allocated for Plone usage. The operating system is Ubuntu Server 6.06 Linux distribution.

Basic Plone system resources

To run Plone web site you need

• Some kind of machine (preferably Unix server, Windows works too) which is connected to Internet 24/7
  

• Ability to run arbitary daemon (background) processes on the server
  
• Ability to open arbitary ports. Zope wants to open its own port for incoming requests.
• Shell account for installing Plone + Zope and running control software
  

One could say that you need server root privileges to run Plone, though it's technically possible without root privileges if the web hosting provider co-operates with you. Also, Plone gulps quite much RAM memory. Read more about it below. You might want to use virtual server, real server or Zope specific host company to run Plone web site, since most low end web hosting solutions don't provide enough flexibility to run Plone. Google for "plone hosting" or "zope hosting". One example company providing resourceful Zope hosting in Europe is Nidelven IT.

Plone performance measuring and caching

Plone doesn't use any CPU when no pages are being loaded (in idle state).

When a page is being loaded, CPU usage maxes out to 100% per thread.

Because Plone CPU usage varies with the load, it's useful to requets per seconds metric instead of CPU usage % to measure how much load the system can take.

Caching

Caching means that instead of regenerating the web page for each individual request, an old copy is kept lying around in memory/on disk and is served for consequent requests. Since the same once generated data is recycled, we improve performance by not going a long process of fetching data from a database, fitting it into page templates and finally converting to HTML.

Without caching, Plone is not suitable for heavy traffic sites (more than few visitors per minute).

Static caching

Here I use term 'static caching' for a method where the whole site is kept in the cache and real-time modified content is available for certain users only. This method is suitable for company web pages and other, closed, non-interactive content.

Pros

• Very easy to set-up
• Very efficient

Cons

• The site cannot have dynamic content (e.g. discussion) or other content which anyone could update

The easiest way to do static caching is to put a front end server at the front of Plone. The front end server takes all requests and caches them over a certain time period until it fetches new content from the server.

The most popular ways are using Apache web server's mod_proxy module and Squid proxy.

With Apache 2 caching site content using mod_proxy, speed increase drastically (x 100). This is because pages are served directly from memory cache, instead of being regenerated each time a request is made. You should find plenty of tutorials from plone.org/documentation and Google how to put Apache 2 to the front of Zope to cache requets.

Also, Apache's mod_deflate plug-in can used to GZip compress HTML, JS and CSS code before sending it over the wire. Most of desktop web browsers support GZip'ed content. This decreases bandwidth requirements, since HTML and other text based content compresses well.

Dynamic caching

Plone 2.5 ships with an add-on product called Cache Fu. Cache Fu allows fine tuned control of caching

• Caching only static items with a front end cache (Apache/Squid)
• Increasing Zope database performance by tuning internal database object caches
• Setting HTTP headers so that user web browsers itself cache the content propeply

Pros

• Propeply set up Cache Fu ensures that live content is always up-to-date (thus, the name dynamic caching), but static content is served at the maximum possible speed

Cons

• Setting up Cache Fu needs insight to HTTP request mechanisms and Plone internals
  

For more information see the documentation supplied with Cache Fu.

Performance numbers

Here are some statistics how many requests per seconds Plone can serve. Note that the statistics below are for the front page HTML code only - No images, CSS or Javascript loading included. Following statistics are generated with ab web server load tool (shipped with Apache 2).

Concurrency level 1 (only 1 simultaneous connection):

No cache whatsoever

Time taken for tests:   19.85032 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      1648900 bytes
HTML transferred:       1613400 bytes
Requests per second:    5.24 [#/sec] (mean)
Time per request:       190.850 [ms] (mean)

Concurrency level 10 (10 simultaneous connections)

No cache whatsoever

Concurrency Level:      10
Time taken for tests:   22.606570 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      1648900 bytes
HTML transferred:       1613400 bytes
Requests per second:    4.42 [#/sec] (mean)
Time per request:       2260.657 [ms] (mean)
Time per request:       226.066 [ms] (mean, across all concurrent requests)
Transfer rate:          71.22 [Kbytes/sec] received

Statically cached page with Apache mod_proxy

Concurrency Level:      10
Time taken for tests:   0.836417 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      1946264 bytes
HTML transferred:       1896900 bytes
Requests per second:    119.56 [#/sec] (mean)
Time per request:       83.642 [ms] (mean)
Time per request:       8.364 [ms] (mean, across all concurrent requests)
Transfer rate:          2271.59 [Kbytes/sec] received

Plone memory footprint

Plone is a complex (due to flexibility) system, involving a lot of code. Unlike PHP solutions, Plone needs to have Zope running all the time as a background process with all classes and default objects loaded into memory. When typical PHP CMS memory usage is 8-30 MB (+ MySQL memory footprint), Plone and Zopes takes whooping 70 MB just to load. This is one reason why web hosting companies don't like Plone.

Plone memory footprint = fixed footprint + marginal cost/new content object * content object count + memory reserved for caching

Where

• Fixed foot print = ~70 MB (Plone 2.1.x). This goes 50/50 with fixed the Python objects of Plone and compiled Python code.
  
• Marginal cost/new content object = Few KB + object data size
  
• Cache memory reserve = few megabytes, depending on the set up

Example report produced by ps command. Plone 2.1.3 reserves about 100 MB memory for a two small Plone site (one Zope can contain many Plone instances).  Zope is listed many times int the report because it's spawn several threads - Memory is shared between threads.

> ps - A v

 9618 ?        S      0:14      0   815 112780 102300 19.8 /usr/bin/python /usr/lib/zope2.8/lib/python/Zope2/Startup/run.py -C /et
11948 ?        S      0:00      0   815 112780 102300 19.8 /usr/bin/python /usr/lib/zope2.8/lib/python/Zope2/Startup/run.py -C /et
11949 ?        S      1:08      1   815 112780 102300 19.8 /usr/bin/python /usr/lib/zope2.8/lib/python/Zope2/Startup/run.py -C /et
11950 ?        S      0:53      1   815 112780 102300 19.8 /usr/bin/python /usr/lib/zope2.8/lib/python/Zope2/Startup/run.py -C /et
11951 ?        S      1:05     14   815 112780 102300 19.8 /usr/bin/python /usr/lib/zope2.8/lib/python/Zope2/Startup/run.py -C /et
11952 ?        S      0:53      0   815 112780 102300 19.8 /usr/bin/python /usr/lib/zope2.8/lib/python/Zope2/Startup/run.py -C /et

Note that Zope doesn't reserve all memory on boot up. You need to browse around the site to make page loads and you can see memory usage increasing (until every page is load).

Spikes and Python memory management

When you upload a big content object (e.g. a high resolution image) Python memory usage spikes up since Python needs to allocate memory for processing the image. This image might not never freed back to the system and thus task manager utilities like top report Python to plenty of memory. However, this memory is not actively used and it's swapped out. Read more about Python memory allocation.

Zope packing

Zope database stores information for all object revisions (each edit, delete) for undoing changes. Unless you want to have ability to track down each change, you can pack Zope database now and then to decrease it's size. It can be done via Zope management interface control panel.