With the current 0.3 branch now stable, work continues on improving the core performance of the basic framework as well as overhauling the main website look and content (long overdue).
A new component that will help with performance that was recently added to trunk is the systemPackager. This class, based on the Symfony 2 ClassCollectionLoader, compiles a set of PHP classes into a single file - meaning all the core classes can be bundled into a single stripped, bootstrap file - perfect for OpCode caches such as APC.
A simple config file based "bootstrap" CLI tool has been added to the main Scorpio CLI tool. This uses the systemPackager and takes a simple config file that details the correct order that the classes should be compiled. Currently two sample config files have been added to a new /data/config folder. The first, bootstrap-core.xml, contains just the core classes - basically system, systemLog, baseSet and the other classes used during the system::init() phase. The second is bootstrap-mvc.xml and this contains the most commonly used components of the MVC system.
Compiling these up creates a PHP file in the temp folder (build location is set in the config file), core totals 131KiB while MVC weighs in at 233KiB.
Now for the fun part: enabling APC and running some tests!
Now, this must be said now - this is just for a bit of fun and is in no way scientific at all (these results were run on a MacBookPro with a whole load of other processes running!), but there is some benefit in that it does show what can be achieved with a little careful planning.
The test itself used the base trunk files, with logs, temp and appropriate config files created and permissions set. Then the website was a virtual host "web.localhost" that just pointed to the base folder. The main index.php was modified to load the bootstrap-mvc.php file and the system::init() call was added below that. In the main config.xml file, production mode was set to true, logging was turned down to notices only and registration of the database and error handlers was disabled - as was log/temp permission checking. Then the MVC system was configured with the log plugin for the distributor and, finally, homeController was modified to just: die('Hello world'); in the main launch.
In terms of software, the built-in Apache and PHP were used. APC was version 3.1.3p1 with all default config except for maximum file size, which was increased to 4MB because the core bundle pushes the boundaries of 1MB and the MVC bundle smashes 3MB of APC space.
web.localhost was requested several times in a browser to make sure it was working, and that APC was warmed-up.
The test was a very simple Apache Benchmark: ab -t 30 -c 10 http://web.localhost/
Copied directly from the command prompt window:
macbookpro:ScorpioFramework dave$ ab -t 30 -c 10 http://web.localhost/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking web.localhost (be patient) Completed 5000 requests Finished 5241 requests Server Software: Apache/2.2.14 Server Hostname: web.localhost Server Port: 80 Document Path: / Document Length: 11 bytes Concurrency Level: 10 Time taken for tests: 30.008 seconds Complete requests: 5241 Failed requests: 0 Write errors: 0 Total transferred: 1610829 bytes HTML transferred: 57717 bytes Requests per second: 174.65 [#/sec] (mean) Time per request: 57.257 [ms] (mean) Time per request: 5.726 [ms] (mean, across all concurrent requests) Transfer rate: 52.42 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 1.7 0 13 Processing: 10 56 32.9 51 247 Waiting: 1 53 32.4 48 247 Total: 10 57 32.9 51 247 Percentage of the requests served within a certain time (ms) 50% 51 66% 67 75% 76 80% 83 90% 101 95% 119 98% 140 99% 155 100% 247 (longest request)
A high of 174 requests per second. Not too shabby at all - especially considering that this was on a baseline 15inch 2009 MacBookPro running ZendStudio, iTunes, Opera 10.53, MySQL 5.1.45, Skype, Adium, Last.fm and Dropbox, and who knows what other OSX processes.
Just to push things a little further, the full mvcView layer was re-enabled and of course the performance dived a bit: 130 requests per second when using straight PHP (configured via the site config.xml file) and down to 88 with Smarty. The Smarty impact is hard to understand because the ZendStudio profiling shows it as barely registering, but the isCached check does seem to be the longest part of the Smarty execution. Perhaps a RAM disk would be good there?
At any rate it would be interesting to see what a real server would produce.
On a final note, the issues with the test cases and Smarty 3rc1 have been resolved in the current Smarty trunk. As soon as the next RC or final is released, a minor release will be made including the patched files.