1

I need to know the rendition time of page template that has multiple DWT`s. I just want to just my page performance.

1

I'm really only adding this for completeness, because modern logging frameworks have probably made this technique redundant, but back in the good old days, we used Sysinternals Debugview for this. This involves calling the Win32 API function OutputDebugString at relevant places in your code, using strings that will identify the locations in your code. DebugView attaches to your process as a debugger, and thereby receives all the debug strings. You can use it to log the results to a file, with timestamps. A bit of spreadsheet-fu will give you timings and statistics about what your code is doing.

It's probably too much hard work these days, but in the VbScript days, armed with a ScriptExtension DLL that allowed calls to OutputDebugView, you could settle any argument about where the code sucked, and the answer was usually embedded field collections.

This technique would certainly work with more up-to-date templating techniques, but the main takeaway is that if you can extract timestamps from running code, the rest is spreadsheet work. Any technique will do if it is sufficiently lightweight not to distort your measurements.

0
4

I disagree with Hiren - yes, Template Builder is the easiest way to get an idea of time taken by Building Block, but not the most accurate because of:

  • Network overhead (passing the package back & forth between template builder and TCM server)
  • Lack of caching
  • Different render conditions

I've done measurements in Templates in many different ways, your mileage may vary depending on what exactly you need to measure and how often (i.e., once vs constantly).

The simplest way: TcmPublisher /debug - it will log time spent in rendering to screen. If you just want to get a one time measurement, this is the best way in my view, as it is simple, non-intrusive, and it shows the server-side measurements with caching, etc.

Another way to achieve occasional measurements is to open the publishing job in the queue and look at the details - it will show time spent in resolving, rendering, transporting, etc.

The "constant measurement" way: use an event system to log start and end and measure the difference in times. I have posted a generic event system that will capture all actions and log their times and some additional data - IIRC, to a MongoDB repository, but that can probably be changed easily.

UPDATE

In SDL Web 8, you could just enable TCM Tracing, using a command like Start-Tcm-Tracing -TraceFile c:\temp\trace.etl -ProcessNames TcmPublisher

UPDATE 2

As mentioned by @Hiren in the comment, my suggested methods for 2013 SP1 will not show the granularity per DWT that you're searching for, only total time spent rendering.

2
  • I am fine with you disagreeing with me and that seems to be valid reason. However whatever suggestions that you have shared are not valid for measuring individual dwt level timing, those are valid only for overall rendering time. The biggest problem with publishing queue to check timing is, there is no rendering time.
    – Hiren Kaku
    Dec 3 '16 at 18:09
  • Valid point Hiren.
    – Nuno Linhares
    Dec 4 '16 at 1:09
2

The best way to measure time taken by each dwt is by using template builder.

Open the template builder, which is available under tools menu, load the page template for debugging, run the template, it ll ask you to select page, select a page. Template builder will show you time taken by each dwt.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.