Too much time to load metadata form.

For each DCR I have a ruleset defined in metadata datacapture.cfg file. In each ruleset I have 7 inline commands. Because of many rulesets
and inline commands ,metadata form loads very slowly.

But if I only have default ruleset and another ruleset for all the DCRs , in this case the form loads very quickly.

Can anyone suggest any ideas on how to improve the performance without removing the rulesets and inline commands.

And also how to write the elapsed time in nanoseconds to some log file.I mean time when metadata is triggered to time when metadata form completely loaded.

Find more posts tagged with

Comments

nipper

Is it when you load a form that has not been tagged or a form that has already been tagged ? IIRC, MT will not execute if there are tags there already. So if you can tag the DCRs in batch (via script), then the load *should* be faster.

Migrateduser

Excessive inlines can cause slowdowns due to the need to exec a process for each inline. If they can be combined or serverized, that's the best way to go.

BTW - If you're just using TagUI and not the MT taxonomy and content profiling services, then the TeamSite forums are the right place to go.

Cheers,
Clark

kisnak

Hi,

I am attaching my metadata datacapture.cfg file. The datacapture.cfg file actually has 14 rulesets, but I included only 2, just to decrease the file size.

In my investigation I came to know that it is INLINE that is killing the PERFORMANCE.

Is it possible to replace all rulesets with single inline? (OR) is there any other alternate to do this.

I would really appreciate anyone's help.

Thanks

Migrateduser

Unfortunately the DTD only allows inlines in the select, checkbox and radio elements, so you can't merge them. Also, TagUI evaluates all the inlines, then figures out which rulesets to use. I believe the order of this isn't specified, so it could change to eliminate unused computation.

The only idea I could suggest would be to pre-compile or serverize the inlines.

kisnak

Unfortunately the DTD only allows inlines in the select, checkbox and radio elements, so you can't merge them. Also, TagUI evaluates all the inlines, then figures out which rulesets to use. I believe the order of this isn't specified, so it could change to eliminate unused computation.

The only idea I could suggest would be to pre-compile or serverize the inlines.

Hi,

Could you please give some inputs on PRECOMPILING and SERVERIZING the inlines

Thanks

ISCBorisB

Hi,

Could you please give some inputs on PRECOMPILING and SERVERIZING the inlines

Thanks

You can not precompile Perl modules. "Serverizing" is simply nonsense. Whatever this ugly neologism means, TST Engine runs Inlines on
the server side anyway.

If I were you I would start to look deeper. Your seven inlines call just two ipl scripts. Chances are, only one of them
is causing your performance issues. Investigate it, use profiler if needed. When you have a better idea what's causing
delays you may start your code performance tuning.

For example, one of the mechanisms I sometimes use in Inlines is, for the lack of better term "inline cache". I keep ready
to go substitution as a File (cache) somewhere and delete it when there are changes that may affect this code. My inlines
simply return cached assets if they exist or build and return if they do not. In this way, only unlucky first user gets
delayed.

Migrateduser

precompiling - there is no requirement to use perl in inlines. IndigoStar has a perl compiler, but I'm not sure if it's not just a packaging tool that still interprets the script. There's also a "compiler" (http://www.faqs.org/docs/perl5int/compiler.html) that enables you to eliminate the time required to create the parse tree - only valuable if your perl programs are huge. My precompile comment was to suggest using C or C++ if there is lots of computation in the perl inline.

serverization - sure, it's a coined term, but English is beautiful that way. If setup time (DB connections, disk data, etc) is dominating the execution time of the inline, converting the inline to a simple service (REST is usually easier than SOAP) and calling that service using a simple inline via LWP might speed things up.

ISCBorisB

precompiling - there is no requirement to use perl in inlines. IndigoStar has a perl compiler, but I'm not sure if it's not just a packaging tool that still interprets the script. There's also a "compiler" (http://www.faqs.org/docs/perl5int/compiler.html) that enables you to eliminate the time required to create the parse tree - only valuable if your perl programs are huge. My precompile comment was to suggest using C or C++ if there is lots of computation in the perl inline.

serverization - sure, it's a coined term, but English is beautiful that way. If setup time (DB connections, disk data, etc) is dominating the execution time of the inline, converting the inline to a simple service (REST is usually easier than SOAP) and calling that service using a simple inline via LWP might speed things up.

Perhaps. Just couple notes:

None of the available Perl Compilers will work with proprietary iwperl distro.
Inline commands are rarely(never?) huge. I have yet to see a single one with a lot of computation.

As to C++ and LWP suggestions, they are formally correct. Note though that without technical jargon
what you are suggesting is "Performance is bad. Discard all you did and do it again from scratch with different
platforms/tools, it'll be better. Or not..."