Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Many inlines make opening dcr slow?
RonaldV
Hi,
TS65
Win2k
I've have created a dct with about 10 inline statements.
The inline commands are simple perl and should be fast. No database/file/external access etc. Simply return strings based on input-params.
Opening the dct (f.i. 'New form entry") is really slow (about 25/30 seconds). If I replace all inline's with fixed xml the performance goes up to 5 seconds.
Is this known behaviour for inlines in TS65?
Did it used to be this slow in previous versions?
Thanks, Ronald
TS552, Win2k
OD560
Find more posts tagged with
Comments
Adam Stoller
Each inline perl script requires a new perl process to be forked (actually, it might be a new shell process within which a new perl process is spawned) - and *that*'s what's causing the slow-down - the overhead of invoking additional processes.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Michael
So if you are going to have DCTs with lots of inlines perhaps it is a better approach to just have one big inline that returns everything (including your dynamic and static items) -- to avoid spawning all those iwperl.exe processes.
I thought I read somewhere there is a limitation to how much you are supposed to do in a single inline though -- anyone know anything about this?
Cheers
Michael
Adam Stoller
When inlines were first introduced I believe there was a limit of somewhere between 3000 to 4000 characters being sent back from the script.
I don't know if that ever got changed.
[trial-and-error may be the only way to find out]
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
jbonifaci
Another solution is to do all of the work your inlines would do through a single callServer.
RonaldV
Thanks all for your quick reply.
TS552, Win2k
OD560
JonathonG
I know this is a bit late, but....
We have an inline that is returning > 19,000 characters and is working fine.
We are basically generating each page of the DCT through the inline (the whole page). Performance is reasonable.
Jonathon
Interwoven Developer
Allstate, Inc.
Adam Stoller
JG - what version of TS on what platform?
I'm glad to hear it works - but I'm not sure when it was "fixed".
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
JonathonG
Yeah, environment info would be helpful....*sigh* Chalk it up to it being a while since I've posted:
TS 6.1 SP1/SP2 <- Code tested on both
Windows 2000
Jonathon
Interwoven Developer
Allstate, Inc.
shanon
it seems like there are lots of people replying ... but here's my $.02:
write a cron job that creates the xml and saves it as a flat file on your file system. just have your inline ipl read that flat file (and/or just use the cron to generate the entire DCT itself), and your performance should improve... lots of options here.
Shanon Levenherz
Mercer eBusiness Team
shanon.levenherz@mercer.com
http://www.mercerhr.com
jbonifaci
Generating your DCT with all of the values hard coded rather than populating them on every load is a good idea to improve performance. It really depends on how often those values are changing. I would suggest having an admin/master workflow that you can just kick off whenever values need to be updated that will rebuild/submit/get latest on all of your dcts. IMO, scheduling something like this doesn't really make sense unless the values are updated on a scheduled basis as well.
shanon
i see what you're saying and i could go either way but i've always opted for the schedule.... the only reason i say schedule is because that means it's automatic. if a business user owns changing certain fields and then kicking off a workflow, that's just one more step that they can forget. given, it's a short process, but i speak from experience: they're much happier to discover that it was automatically refreshed when they forget...
-shanon.
--------------------------
Sr. Solutions Engineer
Interwoven, Inc.
shanon@interwoven.com
