- page load time from browser (seconds)
- page processing time at backend (milliseconds)
- resource utilization (memory, cpu, network, disk)
Each of these metrics were measured at the beginning of the project to establish baseline values. Next the team worked to identify, diagnose, and fix areas of our site that contributed to less than desirable performance.
The JewelsBoutique.com Production Environment
The JewelsBoutique.com online store manages more than 40,000 individual online luxury items including diamonds, pave engagement ring mountings, necklaces, earrings, and bracelets. Our goal is to never make our customers wait longer than 2 seconds for pages from our site.
The production environment is deployed and managed via cloud computing, using a small instance (1.7GB memory) Elastic Compute Cloud (EC2) from Amazon. Data storage is managed via Amazon Elastic Block Service (EBS); EBS provides highly available, highly reliable storage volumes for EC2.
We noticed that disk reads/writes were sometimes quite slow. So, we made a couple of changes to improve EBS I/O:
- Reduce contention by creating separate disks for reads and writes
- Added eAccelerator cache to both reduce PHP disk I/O and boost run-time performance
Our Web Server
Next we found that our Apache configuration included several modules that JewelsBoutique.com does not use. We removed the unused modules and recompiled Apache and mod_php statically to not only reduce memory consumption, but to also improve both startup and execution time performance.
The Database
As is often the case, database bottlenecks creep in and affect web site performance. We found that some simple tuning of our MySQL database yielded significant performance gains. We adjusted our MySQL configuration based on several tips from the Tuning Primer. We also adjusted MySQL innodb_flush_log_at_trx_commit to balance the I/O ratio.
Don’t Forget the Network
Page load time is dictated by the time required to download and present all page content. To boost download performance, we added a sub-domain for skin and media files which permits the browser to download content, media files, and skins in parallel. We also used gzip to reduce size of certain “large” pages (in some cases page size was reduced to ~40% of original) which in turn lowers network load.
Finish Line
The effort and changes described above have been implemented. We compared the original baseline values against the current values and here are the results:
- average page load time is now less than 2 seconds; baseline value was more than 6 seconds
- page processing time is now around 400ms; baseline value was 635ms
- resource utilization is down more than 50% from baseline levels
We are quite happy that all gains from this “Performance Blitz” were achieved without adding or upgrading hardware! In the future, when we do add computing resources, we can be confident that will be used efficiently.
