I have now documented the core classes and functions of Wiccle on a general level to help users and developers get a grip on what's going on under the hood. Have a look at the new tutorial and give your feedback!

• Wiccle System Architecture - Core Class and Function Overview

This information should be sufficient to give developers a general orientation on what's where, and why. I will go into more detail on all this in upcoming tutorials. In the meantime, if you have any questions on how to work with Wiccle Core and how to extend your system, please don't hesitate to ask.

For those who are interested in looking under the hood of Wiccle Web Builder, please don't forget the debug terminal available by adding &debug=on at the end of any page's URL. One useful aspect to be gleaned from the data there are the contents and call locations of all MySQL queries of the page.

With another step towards optimizing the system, I have extended the debug terminal data to include interval timestaps to each MySQL query to see where the system takes longer to process — those are the places that need to be optimized. Here is a screenshot of the microtime extension that will be available with the next version upgrade, taken from the media portal page of our online demo.

The format of the debug data following the query is as follows:

1. Class::function from which the MySQL query was called.
2. Line @ Filename where the function calling the MySQL query was called.
3. Time from script start to query in microseconds.
(Note that template processing happens.after the query, so time spent processing that hop is the offset of this time to the time of the following entry.)

For those interested what's actually happening above, here are the queries in order of apperance.

• Get requested layout data, based on $_GET['show'] in the page URL (0.006 sec)
• Get columns and units for the requested layout (0.013 sec)
• This is the redundant duplicate query I still haven't snipped out. (0.013 sec)
• Get 10 posts from the Video module (0.032 seconds)
• Get 10 posts from the Gallery module (0.084 seconds)
• Get 10 posts from the Audio module (0.155 seconds)
• Get 10 posts from the Downloads module (0.167 seconds)
• Increment layout view counter (0.199 seconds)

And then the page processing from live data to templates and HTML output stops at exactly 0.200 seconds, memory usage 2048 KB, peak memory usage 2304 KB.

The main increase in possible processing time comes from dynamic data that's parsed into templates. The specific CPU usage depends on the amount of posts (or other dynamic content) fetched, and the template snipped used as the data format (more tags = more processing).

The above represents a good overall system resource imprint reference point, based on which you can make your own performance tests and experiments with different content combinations and template formats.

If you happen to keep debugging on and want to pitch in to make iWiccle/Wiccle a little bit faster still, you can keep your system in debug logging mode whenever you're editing around, and report to us if you see a CPU time spike anywhere in the logs.

If you're a developer and want to track your performance in batches, you can also edit variables.php and flip the following switch on:

• $core['sys']['page_history_tracking'] = 0; // tracks page history and performance -> may cause a rapidly growing database table!

And really, if you're a responsible developer, it's practically your duty to keep an eye on system performance, and monitor the effects of the modifications you work on. Since you are now doing it, please also let us know if you spot something consistently lagging.

For more information on accessing and understanding the page history performance logs, please see iWiccle/Wiccle Resource Tracking.