Plone system resources for a small site
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).
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.
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.