Positron Startup Time - Corp Environment

[bombri]

We have been working hard to improve the startup time of Positron + R over the past few weeks within our corporate environment. Our environment includes both CyberArk EPM and Windows Defender. My Positron startup time has dropped from 120 seconds to somewhere between 20 seconds (only if I'm lucky) to 80/90 seconds by adding exceptions to CyberArk, then removing CyberArk altogether and then modifying settings.json.

I'm wondering what else can be done to fix the startup time of the IDE. I'd really hope that with proper file permissions and defender exceptions that the startup time would be somewhere down in the <10 second range as we launch new instances of the IDE frequently throughout the day.

I have included both my settings.json and my Developer:Runtime Startup Diagnostics via text files to help with diagnosis.

Any advice that can be offered would be much appreciated.
Settings.JSON.txt
PositronRunTimeStartupDiagnostics.txt

[jmcphers]

Thank you for including the startup diagnostics; they're very helpful.

adding exceptions to CyberArk

Just to be clear, is this startup profile from CyberArk with exceptions, or CyberArk disabled? You might want to ensure you have an exception for Positron's kcserver.exe (the process that manages R and Python sessions).

Can you grab the full kernel supervisor logs from a session with a slow startup? They're in the Output panel under "Kernel Supervisor". The startup diagnostics report (for brevity) doesn't include the whole thing, but based on your perf marks I think the supervisor may be starting up too slowly or not at all on the first attempt (perhaps due to AV).

[bombri]

Good morning, thank you for your response.

That startup diagnostic is already witih CyberArk disabled (uninstalled entirely from the machine). I did a fresh launch of positron this AM and I've attached both the Runtime Startup Diagnostic and the Kernel Supervisor logs.

Thanks again for your help,
BB

KernelSupervisor_2.txt
PositronRunTimeStartupDiagnostics_2.txt

[jmcphers]

Thanks! This is a pretty interesting log. It looks like the problem is in the handoff between the supervisor and Positron. The supervisor writes connection information to a temporary file, e.g.:

C:\Users\c037655\AppData\Local\Temp\kallichore-f1263239-56752.json

but your AV scanner appears to be holding that file for a long time before it is made visible to Positron, so long that Positron gives up and tries again (twice in the logs above).

Is there any way you can configure AV/Defender so that JSON files in %TEMP% don't get quarantined?

Can you also try bumping this value? It defaults to 15. If you set it to 60 on your machine, startup should succeed the first time around (even if it is slow) so you won't have the delay induced by multiple retries.

[jmcphers]

Honestly, the best way to speed this up would be for us to stop using tempfiles to pass this information between processes and choose some other form of IPC. I've written that up here: #13388

[bombri]

@jmcphers - I apologize for the long delay. Our team has worked with corporate security over the past month and added a bunch of exceptions so that our antivirus and cyberark stop scanning one another. Additionally, we've added exceptions as suggested for Positron.exe and Kallichore.exe or KCServer etc... The startup time is now around 20 seconds (which is a lot longer than the 2 seconds on my home local machine). But we still have odd intermittent delays and errors that are making the IDE almost impossible to use for regular work. Additionally I'd like to get the startup time down under 5 seconds which seems mroe reasonable when users open the app many times throughout the day.

1 - When simply trying to manually execute commands, the IDE often pauses and doesn't respond for 10-20 seconds. It's unclear to the user whether the command was received by the IDE or whether ctrl+enter needs to be hit again. Eventually the command runs but its very unclear what's causing the delay
2 - We've been getting a lot of timeout errors while running code "connect ECONNREFUSED 127.0.0.1:12345" which simply cause R to crash. Exit Code -1073741819

I'm not sure where to go from here. I do believe that all the temp files you reference above are problematic in our environment and likely many other corp environments as well. The IDE in combination with a coporate security environment seem to be at odds with one another.

Thanks in advance for any further suggestions you have,
BB

[jmcphers]

There is a known issue wherein the IDE can look hung if the R or Python kernels are slow to check statements for completeness. I would guess that's what you are seeing, based on the second error you shared. #10411

Can you say any more about the networking situation in your environment? Positron connects to R and Python kernels over ZeroMQ which in turn is TCP based, so every time you need to run code it needs to make a couple round trips over local TCP. Does any software run locally that might slow that down or interfere?