Hi,

Thanks for the extra information. I assume you had a look at the Events tab of this TranslationJob. Or perhaps by looking at Organize Space Event Monitor, looking at the timestamps you could answer the below questions.

1. Is your worry the complete throughput time of this simple TranslationJob is 20 minutes? The system is asynchronous and depending on load on the server, polling rates, other jobs... it can take 20 minutes before your request is head of the queue.
2. Is your worry that once the TranslationJob is picked up the asynchronous Translation Organizer service it still take 20 minutes of calculation/CPU time? This is not about queue waiting times, but there might be something special with your xml content that causes the software to need 20 minutes. Sounds unlikely, if so, then please log a support request.

As a reminder

• TranslationBuilder Windows service polls for TranslationJob in status "ReadyForTranslation" and in turn takes care of generating the necessary target languages. It triggers and monitor a push translation for you. Once the target languages are created, it moves the status of the TranslationJob.
• TranslationOrganizer polls for TranslationJob in status "Resolved" and takes care of the exporting/importing integration towards translation management systems

Regarding scenario 1, then it is about polling times. So how often do services check for new incoming TranslationJob work. The system defaults are good for Enterprise production systems, but sometimes when people want to demo something then a default 15 minute poll cycle is considered "long". Note that polling too fast is a kind of load which also slows down the system throughput. Still, perhaps Translation Organizer common parameters or Application configuration for Translation Builder can inspire you more.

If Infrastructure-as-Code is your thing, then have a look at our PowerShell module ISHDeploy, specifically cmdlet Set-ISHServiceTranslationBuilder and Set-ISHServiceTranslationOrganizer.

Best wishes,
Dave

Hi Dave,

    Thanks for the visual above. I'm jumping in here since we are facing the same issue as Zhu above. We are moving from TD14.3 to TD15.1.2 and that's where we are noticing these issues. Our hardware setup is very similar to Zhu above but our response times for Translation jobs are even worse (in excess of 40 minutes). In TD14, it took less than 5 minutes for the same job.

    To provide some stats around the Translation job itself:

• We created a Publication with a single Ditamap which in turn references a single topic. The topic contains a title and 2 paragraphs. Sending this Translation Job to WorldServer is taking in excess of 40 min.
• Referencing your image above, most of the time (in excess of 30 min) seems to be spent on the calculating and resolving step. At the end of this stage, I can see in the event log that Translation Builder created a Baseline Report. Reaching till this step took about 95% of the time.
• With regards to the load on the system - since this system is just being tested, I am the only one on this system.
• In order to ease the wait time, I have set the polling time to 1 minute on our dev setup. Its set to the default on our prod setup.
• To investigate a bit more, I modified the NLog config of both the OWcf and TranslationBuilder to Trace. I am seeing a lot of calls being made out to "Trisoft.InfoShare.Business.PublicationOutput.SetMetadata()" each of which are taking over 3922ms. 

I have filed a support ticket and while we are being helped there, I am going to take a look at the cmdlets you mentioned above (thanks for that!). Hopefully, I find something that can help someone else facing this issue on this forum. :-) 

Hi Dave,

    Thanks for the visual above. I'm jumping in here since we are facing the same issue as Zhu above. We are moving from TD14.3 to TD15.1.2 and that's where we are noticing these issues. Our hardware setup is very similar to Zhu above but our response times for Translation jobs are even worse (in excess of 40 minutes). In TD14, it took less than 5 minutes for the same job.

    To provide some stats around the Translation job itself:

• We created a Publication with a single Ditamap which in turn references a single topic. The topic contains a title and 2 paragraphs. Sending this Translation Job to WorldServer is taking in excess of 40 min.
• Referencing your image above, most of the time (in excess of 30 min) seems to be spent on the calculating and resolving step. At the end of this stage, I can see in the event log that Translation Builder created a Baseline Report. Reaching till this step took about 95% of the time.
• With regards to the load on the system - since this system is just being tested, I am the only one on this system.
• In order to ease the wait time, I have set the polling time to 1 minute on our dev setup. Its set to the default on our prod setup.
• To investigate a bit more, I modified the NLog config of both the OWcf and TranslationBuilder to Trace. I am seeing a lot of calls being made out to "Trisoft.InfoShare.Business.PublicationOutput.SetMetadata()" each of which are taking over 3922ms. 

I have filed a support ticket and while we are being helped there, I am going to take a look at the cmdlets you mentioned above (thanks for that!). Hopefully, I find something that can help someone else facing this issue on this forum. :-)