Optimising Paloose Performance
Optimising Paloose Code
To start with I produced a non-cached version of Paloose with no comments. As I suspected this gave little or no advantage over the cached version.
The next trial was to remove the Logging — certainly a little dangerous on a development system but possibly an allowable risk on a mature system when speed is essential. The result of this was illuminating. The speed increase was substantial.
The main reason for this is the amount of code needed to be included from the log4php system. In particular every time a require_once statement is invoked it degrades the performance, not unexpected.
There were very few other optimisations that gave the same improvement of speed.
Using a Data Cache
The final way I tried with the caching was a data cache within the pipeline. The current version (after 1.3.0) has this scheme in some of the generators and transformers. The theory is that each stage is responsible for maintaining a cache of the data that it outputs. In the case of a transformer the output is taken from the cache dependent on several things: the input DOM being valid, the XSL file being up to date and the parameters being valid. Valid implies that there has been no change since the last access. I am not wholly convinced that the system is useful except in cases where there are a large amount of transformations to be done — either as a number of sequential transforms of a single large one. For example I tried loading my Hop Vine site catalogue page on a local server and which uses up to 6 transformers to run. The results are relatively encouraging:
However I am not sure whether the added complexity is worth it: any thoughts from anyone out there?
Conclusions for Paloose Web Site Design
So what is the best way to proceed? If you want huge speed increases that Tomcat/Apache give you then use them not Paloose. However it is possible to provide some guidance on small sites.
- Do not use sub-sitemaps unless there is a real necessity. Each time a new sub-sitemap is mounted it must be parsed. Not a huge overhead from experimental evidence but one nonetheless.
- Do not declare more components in the sitemap than you need. Each component requires some PHP code to be included (the Component class and its subsidiary classes). As we have seen this is the biggest overhead.
- Use a "delogged" version of Paloose. A little dangerous but it does give a good increase in speed. The question is: how do you get a version of Paloose without the logging? Each release of Paloose contains both a full (logging) version, together with a compacted version (no logging/comments) — treat with caution.
Reflections on Current Performance
Time and technology have moved on since the above performance graphs were produced. New results (2023) show a considerable improvement over those results (15 years difference). The test was run on this Paloose site running on a commercial ISP host. The graph below shows the comparison with the "old" system — the results are impressive.
