SEALScript slow performance when referencing non-existing servers

[FilipSteijner]

Hi!

I'm developing a script that makes thousands of calls to sdkClient.IAdvanced.SetPropertyValue. I've noticed a significant performance issue:

• When the Value parameter (a VariablesPropertyReference) points to an existing server, the call completes in 3-5ms, even if that server is offline/unreachable.
• When the Value parameter points to a non-existent server, the call takes approximately 4500ms.

For example, with this structure:

ES
--Servers
----AS01
----AS02

• Setting Value to "/AS01/..." → Call takes 3-5ms
• Setting Value to "/AS99/..." → Call takes 4500ms

Context

My script needs to make thousands of these calls, potentially referencing about 20 different servers. In a test environment, I don't have that many actual physical test servers that i can name to match all the production server names.

I guess i could setup those servers in PCT to match the names of the real production environment, but it seems like a very tedious task to do and there should be a better alternative.

When running against non-existent servers, this adds multiple hours to the execution time, which is not feasible for testing.

Question

Is there a way to improve performance when the script references non-existent servers?

I'm looking for solutions that don't require:

1. Setting up 20 test servers with matching production names (seems like a bad practice)
2. Running in the production environment (I cannot use SEAL within the customer environment)

Has anyone encountered this issue before? Are there any configuration settings, caching mechanisms, or alternative approaches that could help reduce the execution time when referencing non-existent servers?

I understand that this limitation is probably within the SDK/API itself, and not a actual "SEAL-problem".

Any suggestions would be greatly appreciated!

[StefanLundin · Accepted solution]

Hi Filip, 

Thanks for sharing your issue with the performance when referencing non-existent servers. We've consulted with the SDK development team, and it seems the SDK performs a GetObject call before setting the property value, which takes ~2s per attempt for an unknown server, with a retry that results in the ~4.5s delay you're seeing. Unfortunately, the SDK currently lacks an API to pre-check server status, relying entirely on the EBO server response.

For now, there’s no direct workaround within the SDK to bypass this delay without setting up test servers matching the production names. Configuring those 20 virtual servers in PCT, while tedious, appears to be the only way to avoid the performance hit in your test environment. We understand this isn’t ideal, and the SDK team is exploring ways to make the SDK smarter about handling such cases, but any improvements in such case would likely be part of a future release (7.1 or later).

Feel free to share any other ideas or workarounds you come across!

[Benji]

Don't know if it would be feasible to do a getchild for /Servers at the start, create a List<string> and then only run updates for any paths starting with a string in the list... just an idea (but I assume you already thought of that :-))