Rendition service question

RE: Rendition service question

Andrew Edge — Tue, 28 Jun 2016 14:53:31 GMT

This was answered in the other forum, but I'll echo it here. When installing iCS for PDF V8i, a choice is given between a standard orchestration or a custom orchestration. A standard orchestration configures one of each of the three primary iCS for PDF processes: one extractor (responsible for copying out documents from ProjectWise), one InterPlot processor (responsible for launching MicroStation and creating PDF(s)), and one ProjectWise processor (responsible for uploading to the destination datasource). That's in addition to the various dispatcher processes that tie everything together.

iCS for PDF can definitely benefit from more RAM and additional CPUs on the server. A custom installation allows you to define additional extractors, InterPlot processors, and/or ProjectWise processors depending on your needs and the server capabilities.

Optimizing the processor counts is both art and science. On a quad-core server, I would start with a 2/3/1 setup. The three ProjectWise processors mentioned in the other forum is unncessary, I think, unless source files are being distributed. It's unlikely that three InterPlot processors could generate PDFs fast enough to keep three ProjectWise processor queues full.

Adding additional servers to the orchestration may also be used to increase throughput, but adds to license usage.

After installing, the processor counts on the server may be changed by running RendsvcConfig in the product directory. But best practice is do so during product installation.

Be aware that jobs submitted from ProjectWise Explorer are given higher priority than jobs submitted from iCS for PDF Administrator or Windows Task Scheduler. That is, when each processor/dispatcher looks at its queue, it will pull a message associated with a PWE-submitted job (if any are present in the queue) before pulling a message associated with a stored job. Thus, if you have large jobs you submit from PWE (for convenience) on a regular basis, and they are blocking small jobs submitted from other PWE users, then you could consider defining that large job in iCS for PDF Admin and scheduling it. If it and a job from PWE are submitted at the same time, both will progress through the system simultaneously, but the PWE-submitted job will generally finish first.

RE: Rendition service question

Luc Poulin — Mon, 27 Jun 2016 19:48:26 GMT

After reviewing and further investigation from our side we were asking us this question....could multiple core help speed things...then you reply and you mention «...All the InterPlot processor queues could be busy at a particular time....»

How can we assign multiple core/processor ? what should we look in the ICS setup to archive this?

OR did I miss read your answer?

If you want to reply here...

communities.bentley.com/.../123154

Thank you

RE: Rendition service question

Andrew Edge — Thu, 23 Jun 2016 17:28:04 GMT

A rasterized PDF normally takes much longer to produce than a non-rasterized PDF, so if the DGNs in question contain any shaded content or point clouds, that's a likely explanation.

Beyond that, jobs in iCS for PDF can be delayed by activity for other jobs, depending on how the server is configured. All the InterPlot processor queues could be busy at a particular time. Perhaps documents from other jobs are having to be renditioned in rasterized mode, ahead of non-rasterized PDFs that would otherwise be quick to complete. Some iCS for PDF tasks, such as processing an incremental stored job with a very large input set, can take a long time to clear the PreProcess dispatcher and thus temporarily block other jobs from starting. There's no one standard answer for how long a given document will take to process on an iCS for PDF server.