Performance Profiling
From MovableType
Contents |
Overview
Configuration
Tests were performed on the following hardware, software and Movable Type configuration:
- Movable Type
- 1 blog
- 3 categories (with entries evenly distributed)
- 4 authors
- 10,000 entries (10 comments per entry)
- 100,000 comments
- Machine (retail value ~ $2000)
- Dual 3.2GHz Xeon w/2MB cache
- 2GB RAM
- 80GB SATA (1.8GB utilized)
- about 18 months old
- Software
- Clean CentOS 4.4 install
- Apache 2.0.52
- MySQL 4.1.20
- Perl 5.8.5
Process
Reports were generated based upon data collected from a system that ramped from one to ten threads requesting a series of pages from the application, with a new thread coming online every 60 seconds until 10 threads were all posting concurrently into the application.
Each thread requested a set of pages in serially and in sequence as quickly as possible.
What was measured
To the greatest extent possible network latency was minimized to reduce its influence over the results. Furthermore, the scripts did NOT download CSS, javascript or other static files during each request. As these assets are almost always cached by the browser it did not seem wise to include their download time in the performance metrics of the application.
Baseline
Before we can understand the performance characteristics of Movable Type 4.0, we must first establish a baseline.
Movable Type 3.35 (no FastCGI)
| Error creating thumbnail: /var/www/vhosts/wiki.movabletype.org/mediawiki/bin/ulimit4.sh: line 4: /usr/bin/convert: No such file or directory |
The red series of dots at the top represents a secondary axis for the CPU load average, with a black linear trendline.
All other multicolored dots represent individual requests being made to the application with a linear trendline showing the average response time in seconds.
- Left Y axis: Average response time in seconds
- Right Y axis: CPU Load Average
- X Axis: Unix epoch time
Movable Type 3.35 (using fcgid)
| Error creating thumbnail: /var/www/vhosts/wiki.movabletype.org/mediawiki/bin/ulimit4.sh: line 4: /usr/bin/convert: No such file or directory |
The red series of dots at the top represents a secondary axis for the CPU load average, with a black linear trendline.
All other multicolored dots represent individual requests being made to the application with a linear trendline showing the average response time in seconds.
- Left Y axis: Average response time in seconds
- Right Y axis: CPU Load Average
- X Axis: Unix epoch time