Architectural overview
In this article we are going to focus on three different hardware configurations. For each configuration, we estimate the maximum performance you can expect from a similar hardware configuration. These results are only estimates. For accurate performance statistics, you must test your own equipment and eZ Publish installation. If you want to test performance in a clustered environment but do not have one available to you, eZ systems or one of eZ's hosting partners can provide rental access to a testing environment.
Test methods
In testing these configurations, we used a standard out-of-the-box 3.8.1 eZ Publish installation loaded with 100 000 objects. We tested serving an article list from a folder containing 5 000 articles. The results show the last 10 articles sorted by publishing date. Each new request to the server instantiates a new session. (In real-world usage, returning visitors would slightly improve the performance results.)
In our tests, view cache was both enabled and disabled ("dynamic" in the performance diagram). The same tests were also done when we had heavy write load on the system ("view cache load" and "dynamic load" in the performance diagram), inserting articles at the rate of three to five articles published per second. Delayed search indexing was enabled.
Hardware
The servers used in our testing were identical Dell 1U servers with the following configuration:
- Dual Xeon 3.1 Ghz
- 4GB RAM
- 100GB SATA drives
- 2 x 1000Mb network cards
- Internal Gigabit switch in the rack setup
The picture below shows the hardware used for testing installed in a standard 19" rack.
The diagram below shows the results from our testing. The results show that eZ Publish scales almost linearly in a clustered environment. The difference between a single server and a cluster consisting of one database server and one webserver is minimal, but would nevertheless be noticeable under load.
Clustering performance chart
Interpreting the results
These test results show the number of pages served per second for several hardware scenarios. The numbers are the absolute maximum that the server can process. Therefore, to estimate performance in real-life scenarios, we need to make some calculated assumptions.
The information that is important for doing a performance estimate includes publishing frequency and the percentage of pages served cached versus un-cached. If we take the scenario with a single server and assume that 50% of the pages are served cached and 50% un-cached, we end up with a number: 19.23 pages / second (p / s).
Normally the publishing frequency of an eZ Publish site is much lower than the load that we tested (3-5 articles per second). Even very heavily loaded sites with active forums publish messages more like every minute or every 5 minutes. But if we take the numbers under extreme heavy load we get an average of 11.17 p / s. We can therefore assume that the actual number is somewhere between 11 and 19 p / s. Therefore, we will use 15 p / s as our estimated load that reflects realistic heavy usage.
15 p / s over a period of 24 hours is 1 269 000 pageviews per day. This number assumes that the server is running at peak capacity for 24 hours, instead of the normal pattern of peak capacity only during specific periods. For example, if a site is primarily used regionally during business hours, the site is probably only under load during 8 hours of the day. For such a scenario, we would estimate 432 000 pageviews per day (that is, one-third of 1 269 000). This translates to 12.96 million pageviews per month on a single server.
If we apply the same estimates to a configuration of four servers, we end up with 70 pages per second, a total of 2 million page views per day and 60.5 million pageviews per month. (These performance numbers are probably lower than what would be seen on a real site, as a site with heavy traffic would normally serve more cached pages than a low-traffic site.) In both situations we calculated with 50% of the pages dynamically generated.
These assumptions and estimates are, of course, theoretical. To get accurate statistics, you must test your own installation. In addition to hardware and eZ Publish software variations, other system activities (such as background jobs, backups, statistics systems and other processes) can add load to the server that affects performance.
This section describes the architecture for hosting one eZ Publish installation on one server. It assumes that the complete software stack is installed on the same server, including:
- Linux
- MySQL
- Apache
- PHP and APC
- eZ Publish
This is currently the most common environment for hosting eZ Publish solutions and can handle sites with fairly high traffic (even without using techniques like static caching or Squid caching). The diagram below shows this setup.
Single-server environment
This section describes the architecture for eZ Publish running on one webserver and one database server. This is a similar configuration as that used for clustering, except a clustered environment has more webservers.
In this configuration, the webserver runs the following software:
- Linux
- Apache
- PHP and APC
- eZ Publish
The database server runs the following software:
Dual-server environment
This is the architecture used for clustering eZ Publish. The architecture is similar to the dual-server environment, but has more webservers and a dedicated server for load balancing.
The load balancer has the following software installed:
- Linux + LVS patch
- Keepalived
Webservers have the following software installed:
- Linux
- Apache
- PHP and APC
- eZ Publish
The database server has the following software installed:
Conclusion
This article used the results of eZ Publish performance tests to predict the performance of eZ Publish installed on several different hardware configurations. This should provide you with an idea of the performance increases you can expect by scaling your site. Also, the article described the architecture of the scaling configurations that are most common and easiest to set up with eZ Publish version 3.8 and newer.