Performance obviously something that everyone is interested in and there are many metrics of performance you can look at - it's not just the raw number of pages per second served that matters. As has been said already you have to look at a study like this and see the angle the originator came from. There's that old saying 'lies, damn lies and statistics' - not that i'm saying that this is what this is but merely that you need to look at how the test where done etc.
Anyway onto
PN itself - performance is a key issue we look at. Any addition to
PN is always given the proper analysis for any performance issues, any new feature is checked for any impact it may have. .750 is a good step in the right direction as far as the raw performance goes. A standard .726 install took 40+
SQL queries to render the page. A .750 base install, which contains exactly the same blocks etc. is down to around 32 queries (I can't remember the exact numbers as it's a while since I did this).
This was acheived by displaying every single query that
PN performed at
looking for ways to reduce the interaction with the
DB. This resulted in a
large rewrite of the
PN module handling routines. Take a look at
includes/pnMod.php for both .726 and .750 to see the difference. The trade off here is a little extra memory overhead since we needed to keep a few more things in memory for later reference.
This extra hit is more that offset by the use of a reference model for the
database connection is .750. In .726 each and every connection to the
DB
(
SQL call) results in a copy of the database connection object and the
tables array. In .750 this becomes a reference to the object (not quite a
pointer but similar) so we save a huge chuck of memory this way.
The next resource saving in .750 is the removal of the global extraction
code from pnAPI.php. Up to .726
PN extracted every single env/get/post/cookie/session variable to the global name space taking up a
big chunk of memory and opening the whole environment to potential security risks. .750 removes this totally. The downside here has been a few modules need a bit of attention to make sure they get thier variables in the proper way. While the average user just wants things to work and may not see it this was a necessary step to properly manage the resources used by
PN and to further secure the whole environment.
The next performance enhancement, while not appropriate for everyone, is full page caching in Xanthia. When used this feature means that the entire module code doesn't get executed if the page has already been generated. This is the closest you get to a mambo style setup. You can exclude certain modules from full page caching (say your forum). Using this feature a page render time comes down the time taken to initiialise the core and serve out the cached page. The downside of this featture is that it's dumb caching - there's no knowledge of when the content has changed.
Moving on to .8x we've saved another couple of
SQL queries along the way with a further step of optimising the core
API's and continue to look at the core closely with a view to further enhancments in both performance and functionality over time. In fact in the last coulpe of days i've re-written a couple of the core
API's with the view to making the core more efficient; not necessarily raw peformance wise but tiider, easier to debug and more consistent. This has now reduced the heart of
PN (pnAPI.php) down from 47Kb of code (.750) to 33Kb of code (.8x-CVS).
In this realease
Smarty, the template engine, plays a big part in addressing performance. With caching in pnRender the module can make intelligent decisions on caching content to prevent the module code from needing to execute. The module can also manage it's own cache ensuring that the cache is cleared when approapriate. This is more structured than the full page caching but takes module being coded to the very latest published standards.
The next performance enhancement will be ADODB query caching. This feature of ADODB caches the results of an
SQL in the file system preventing the need to go back to the
DB again for this result set. I'm currently looking at how best to extend our ADODB usage to include structured caching of queries (under control of the site admin) while ensuring time sensitive queries (sessions etc.) remain uncached.
I started by saying that raw performance is not the only metric I think it's important to recognise this. I've covered resource usage (memory) already and this is a key one. We don't want the server running out of memory with the cpu and
DB sitting there able to handle more. .750 takes steps to address this as i've outlined earlier.
The next metric for me is bandwith usage. This is an area that
PN is really not very good at. A
PN rendered page is some really bad, inefficient
HTML with poor usage of
CSS. The mix of
PHP code and
HTML makes this hard to address and it's not something that will be done for the .7x series. .8x makes sigificant strides here ensuring that the
HTML generated is as efficient as possible utilising as much of
CSS as is possible while retaining browser compatability.
A quick look at my lab site (
http://www.markwest.me.uk/pnlab/) gives an indication as to the improvements being made in this area. We're attempting to remove all tables bar those used to display tablular data. I'm not there yet on the current theme i'm using on the site - I still need to address the article templates but flip to the extralite theme for a better view. Bear in mind that you might not see the raw performance on this site as a)my host is not the fastest (it's cheap though...) and b) I generally have pnRender and Xanthia configured to force recompilation of all templates as I actively develop and test code on this site.
So as you can see performance is a key factor in the
PN development cycle and will always be that way. Is
PN all it can be? No - that's why we're at version .750. It's important to remember where we started; with
PHP-nuke and it takes time to move away for that start point in a structured, coherenet fashion while making every effort to remain backwards compatable. There have been some tough decisions about compatability already and there will be more as the code progresses however each one will be taken with due consideration but will the overall goals and roadmap in mind.
I hope people find this perspective and overview of
PN's development techniques and strategies useful and I hope that this gives everyone an idea of the priorities we make when developing new code and features for
PN.
Lastly apologies for the thesis style length of the post.... ;)
-Mark
--
Visit
My homepage and
Zikula themes.
..
Perhaps there are some features, that the faster ones don't have.
