Developers, developers, developers... (Part 1)

2010-08-05, 17:13 by Jonas Wallden in Development

If you are reading this, chances are you develop web applications in RXML and XSLT. If so you are probably familiar with the XSLT profiler that was introduced in Roxen CMS 5.0, and of course the old friend Resolve Path in the Administration interface. Both are useful in debugging CMS web sites but to be truthful they also have a pretty high threshold that can prevent you from using them effectively:

  • You need access to the Administration interface.
  • You must have server console access to enable the XSL profiler.
  • Collecting many reports involes a lot of tedious copying/pasting of URLs.

Help is on the way

These drawbacks will be resolved in the following maintenance release of 5.0. To begin with, we have changed the way the XSLT profiler works. There is no longer a measurable penalty for non-profiled transformations so it can be available at all times, eliminating the need for an on/off start flag. Next, both XSLT and RXML profiling will be accessible via a new Content Editor menu command:

To use it, select the command and you'll see the Admin menu icon change to a red racing flag telling you the profiler is active:

You then collect data by simply surfing the web pages in your site. Every page you visit will be profiled and the profiler keeps the most recent log for each path. Unlike before this mode also disables the internal transformation cache so you get usable reports for every request. Choosing the Admin menu command again will turn the profiler off.

Viewing profiler reports

At any time you can go back to the Content Editor window and navigate to the corresponding pages to view the profiling reports. There will be two separate reports – one for XSLT and another for RXML:

As seen here the lines are colorized to make them easier to interpret, though the content is basically the same as described in my earlier blog post. To quickly identify the template blocks that contributed to the execution you just drag the mouse over the text:

In the RXML section there are no template blocks but I have configured it to highlight some common performance-impacting constructs such as <emit>, <cache> and <nocache> instead.

Profile reports are cached in RAM for a limited time and can be cleared individually or all at once by clicking the links in the header. At the moment there is no summary page listing all reports in one place but that is a reasonable next addition.

Resolve Path not dead yet

Speaking of limitations, this new feature does not profile anything outside of the CMS workarea filesystem module meaning that it cannot log as much as the Resolve Path wizard. For instance, you will not see redirects or post-processing modules. It currently also disables the persistent disk cache and by its nature you always run edit-area code which may differ from what external site visitors get.

More to come in Part 2

I'd be very interested in hearing what kind of developer tools that would make your life easier! More performance analysis, easier access to reference documentation, or maybe something else? In part 2 I'll describe another new CMS feature that fits in the developer tools category, one which I believe will make a lot of people happy. In the meantime, please share in the comments area below.

 

You need to log in to post comments.

 

1   Arjan van Staalduijnen

2011-01-28 09:02

This feature has proven to be very useful for our website. We used it (under 5.0) to verify the XSLT performance of a highly popular part of our site, and we were able to cut down the XSLT time by more than half. The main gain was in a few highly-ineffective template implementations in our core XSLT code which had gone unnoticed without this tool, and we gained a bit more time by rewriting some page specific template matches.

Having this feature directly available in the editor interface will allow us to bring this feature directly to the people who write the XSL, so I'm eager to see it being used there.

Thanks!

Arjan

Nov 25, 2017

Categories

Community Update (1)
Customers (0)
Development (10)
New sites (1)

Latest comments

This feature has proven to be very useful for our website. We used it (under 5.0) to verify the XSLT performance of a highly popular part of our site, and we were able to cut down the XSLT time by more than half. The main gain was in a few highly-ineffective template implementations in our core XSLT code which had gone unnoticed without this tool, and we gained a bit more time by rewriting some page specific template matches. Having this feature directly available in the editor interface will allow us to bring this feature directly to the people who write the XSL, so I'm eager to see it being used there. Thanks! Arjan