Known Participant

Answered

Serious InDesign Server slow down with Catalina

Forum|Forum|5 years ago
November 16, 2020
5 replies
2630 views

We are stuck with serious performance issues with our scripts for InDesign Server (mostly Applescripts) after upgrading from Mojave (macOS 10.14.6) to Catalina (macOS 10.15.7). The problems are alike with Indesign Server CC 2019 and CC 2020.

Our current project aims at a Indesign Server solution that, when taken in production (very soon), must be able to run on a machine that demands Catalina or later. And it will rely heavily on high performance. But I’m afraid the these performance problems are deep rooted and can only be solved by Adobe and/or Apple.

We haven’t encountered any resembling performance issues with other applications than Indesign Server, or with scripts working with tasks that does not involve InDesign server on these machines or other macs running Catalina. The slow down with InDesign Server are abnormal.

The problems manifests themselves in several ways:

1. The time it takes for a script to do its tasks have raised to unacceptable levels. In the very best cases, it has more than tripled.

2. Processing time also varies a lot between executions of the same script – for no apparent reasons.

3. Processing time is often even higher when initiated by a soap call than when the same script is run from a script editor.

For evaluation I have used one and the same script working with one and the same document. The test document (relatively light in our context) is opened from a template with around 350 empty text- and image frames. The script first analyses the document, recording all frames with a certain label content and makes a setting record for those frames based on the label content. Then it imports text and place images according to those settings.

Under Mojave it takes just above one minute for the script to do the job – both when started with a soap call and directly from an editor. Processing time is varying between 1:02 and 1:12, which I consider to be a ”natural” variation.

After the upgrade, the scores for editor executions have varied between 2:08 and 3:44. Started with soap the time varies between 3:30 and above 5 minutes

In short: The increase in process time – at least 300 to 500 percent with soap calls – is of course unacceptable. Also, the large variations is also a problem in itself.

Notes:

• The process time scores above referes to the time amount from when the script starts to work with the document until it’s finished with the document (so any delays outside of the document processing is not included).

• We cannot pick out certain actions that has slowed more than other. The recording of document content is heavily decelerated – taking between 40 seconds and 2 minutes and more, compared to taking a few seconds with Mojave. Likewise, the process to place text and images, fit images to the frame and so on have slowed down to the same extent.

• Our experiences of the performance problems comes from a Mac Mini used for development, where the tests I refer to is done. To confirm the problems, we have also done the same tests on a fresh machine delivered from Apple with Catalina pre-installed, a lot of RAM and no other installations than the ones necessary for doing these tests – with the same disappointing results.

This topic has been closed for replies.

Correct answer Dirk Becker

Another idea - what is your front process? Any changes when you tell the server to activate?

D

Dirk Becker

Legend

Have you also tried to launch the script via command line, using the osascript command?

Kris has reminded me of App Nap - ESTK had some trouble with it back in 2017. Introduced with 10.9 https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_9.html , but maybe Apple has recently changed a detail? To confirm, please open Activity Monitor, CPU view. With a right click at a table column you can show an extra column "App Nap". Then watch your Server during slow execution.

To change the App Nap policy, following that page you'd use the command

defaults write "com.adobe.InDesignServer" NSAppSleepDisabled -bool YES

J

JostifyAuthor

Known Participant

I didn't try using the osascript command, since it would demand some work to simulate script arguments. And I don't have much time over because om the deley the problems have caused.

I did som tests this morning by inactivating the activate-workaround to bing back the slow performance. But the "No" in the App Nap column hav never turned to "yes" during these tests.

J

JostifyAuthor

Known Participant

@Dirk Becker. Thank you so much for your expert help in this case! Without it I doubt it would be solved in time for us, and in any case the costs in time and effort would have been much higher.

Now we have a workaround – that's a fantastic relief for me.

And, as you write, this propably gives Adobe a very good starting point for solving the problem permanently.

D

Dirk Becker

Legend

Given your "In the production context there are multiple InDesign Server processes running", it can only help one of them to activate. I'd also be careful with the parent approach to not accidentally cross processes - never tried that with any application that allows for multiple instances on the same machine. Eventually the phrase "current application" works here too?

With the limited analysis (no own experiments, no stepping around in assembler), it appears that Apple has tied a slow/secure path of script execution (involving LSCopy) to some criteria that is not always met by Adobe. Best approach would be Adobe engineering does their own confirmation of my theory and files a radar (Apple incident system) to end up with a solution - e.g. change the AppleScript plug-in or document our current findings.

J

JostifyAuthor

Known Participant

1. The activate approach actually works even when the script is run simultaneously over all the five active ports.

The process times are then 5-40 percent longer, but that's expected. And it's far better than running only one process before that change was done. So it actually seems to be enough for the scripts to tell "InDesignServer" to activate (not a specific instance of it).

2. The parent approach wasn't stable anyway. The good effect lasted just a handul of runtimes. Or maybe it did't have any effect at all – the good scores just beeing som strange overspill from the spreceding script executions with the activate approach?

J

JostifyAuthor

Known Participant

And it seems to be enough to activate InDesign Server just once, when the main script starts running.

I have not been able to disturb it by clicking aroud with other apps on the server, och by running a script that activates other apps every half second. The performance stays at the same good level.

D

Dirk BeckerCorrect answer

Legend

Another idea - what is your front process? Any changes when you tell the server to activate?

J

JostifyAuthor

Known Participant

That's an interesting hypothesis, and I will try all the things you suggest.

I apprecieate your help very much!

D

Dirk Becker

Legend

Please perform a similar Sample Process on your Mojave machine.

No need to post, just tell whether there are the same dominant sections of AE* calls going thru LSCopy* calls. If not, that would confirm my suspicion that Apple has changed that "com.apple.AE" module. The AppleScript language component - those "(in AppleScript)" calls - heavily relies on AppleEvents, implemented by the "com.apple.AE" module - the "(in AE)" calls. Nothing bad, but these presumed basic and fast operations now burn all your CPU time in "(in LaunchServices)" converting data back and forth into strings and streams. If the other Process Sample has only few string/stream operations, Apple likely has converted binary transfer into that string based approach. The occasional "outputSafeString" suggests that might be considered a security "improvement".

For another test, try to use the [ tell application "InDesignServer" ] statement rather than the … id - eventually there is a check to allow local, fast (in-program) execution based on the resulting addressing mode. When I asked for the first few lines of your script, I was thinking of that, not any more complicated artifacts of your structuring large scripts.

For completeness sake I'd also try some more ways - e.g. call via process ID - there are some fragments on the web starting from SystemEvents … .

Another one, if I remember that correctly: your script can have a property "parent" used for inheritance. When you point it to the application the script will pass unhandled requests to that parent. Eventually you'll need to combine that with "using terms from application" statement.

As you suggested on LateNightSW, execution via the Apple Script Editor is also faster. This is something an Adobe engineer could follow – watch what ScriptEditor is doing differently and adjust InDesign's "Support for AppleScript" plug-in accordingly. Or they could ask Apple … Assuming anybody from Adobe watches this thread at all. So ring a few bells - Uservoice etc.

Could you also test the terminal / command line osascript? If it works the same way as AppleScriptEditor, your soap call could eventually invoke the AppleScript via command line, or you bypass SOAP and use some web server to get there …

J

JostifyAuthor

Known Participant

There is one very puzzling thing, that we have observed after I wrote this post :
At some, very rare occasions the script suddenly runs as quick as it used to do before the upgrade – just above 1 minute.
This have happened two times – out of around one hundred tries with the same script. In both cases it was executed by a soap call (with otherwise has become the slowest method with Catalina).
Then, running the same script several times directly after such an occasion, gave us same disappointing results as usual: around 3:30 and sometimes more, from soap.
This tells me there is a potential to run InDesign Server scripts as fast with Catalina as with Mojave – but, in most cases, the script is heavily disturbed by something...

T

Test Screen Name

Legend

I have no experience with this specific issue, but if I may I will share some thoughts. Possibly, it is one specific method or action that is taking a very long time, and if so, you may be able to focus on solving a better-defined problem. If it were me, I would change the script to optionally write a detailed, timestamped, log file as it does the task. By looking at the timestamps, and perhaps comparing with a log from the best timing or another system, you will be able to identify a specific problem area. It may be quite unexpected; for example, I have seen the suggestion that running certain executables under Catalina causes the macOS system to contact Apple to check signatures, causing wild unexpected variations in run time, which Apple refused to consider a problem.

J

JostifyAuthor

Known Participant

Thanks very much for your input, Test Screen Name.

From the timestamped logging the script already do, one can se there are no eye catching time gaps between specific operations.

I have also, by logging, separated parts that contains script commands solely targeted to Indesign Server from other parts doing other stuff (like doing calculations, running shell script commands, using Objective-C code, doing file system stuff and so on).

From that I can conclude that the Indesign commands at least take their fair part in the slowdown, if not most of it. One bunch of code, for example, just collects data from the documents frames, such as object reference, object class and label content, storing it in a record to be processed later. In my test document there are 340 such text frames and rectangles – with no content yet when this data collection is done.

In Mojave that part took 1 or 2 seconds. In Catalina it takes 12-15 seconds.

Later in the process there is a long part were the script fill those frames with (mostly) pictures and (some) text, then doing som adjustments like fitting the picture to the frame. Also that part of the process consists mainly of Indesign script commands – and takes much longer time after the upgrade

I could do more work to make the script log every command, with millisecond timestamps, to see if certain Indesign commands have slowed down more than others. But anyway, it is obvious that pure indesign commands in general are affected – both those for just collecting data from the document and those for doing stuff with it (which is not to say non-indesign commands are not affected).

The delays are on the millisecond level, and everywhere. The slowdown is only shown in the sum of them.

Apples signature checking was one of the first suspicions we had (after ruling out that Catalinas new network volume security measures had something to do with that). There are ways to totally deactivate gatekeeper and something called amfi that are involved in signature checking. We tried that in the course of our troubleshooting – but it made no difference. Well, running scripts from an editor became a little bit faster, but not running them from soap calls.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded