How can we improve the early responsiveness of applications deployed to a service fabric cluster

Question

We have a system split into multiple services that are deployed as part of a continuous delivery pipeline into a service fabric cluster. We do experience an impact once deployments are complete, in that the system feels noticeably slower until everything has "warmed up".

We believe this issue to be related to the JITing of the new versions of each service within execution paths, but it may also have an element of serializer generation also.

Normally we would be looking to use ngen.exe in order to alleviate the issue associated with just-in-time compilation but we do not know how it can be achieved in connection with service fabric.

• What trust level are services within service fabric running under? As ngen requires full trust

• Is it possible to deploy the service but ngen it BEFORE requests are serviced by the new version of the service?

• If an upgrade is rolled back, is there cleanup that must be performed? And is it even possible to perform that clean up?

Many thanks for your time, if you require more information, I'd be happy to provide it where I can.

Answer 1

Q1:

What trust level are services within service fabric running under? As ngen requires full trust.

A quote from here:

By default, Service Fabric applications run under the account that the Fabric.exe process runs under.

Usually it is NetworkService.

Q2:

Is it possible to deploy the service but ngen it BEFORE requests are serviced by the new version of the service?

Yes. You can use SetupEntryPoint to execute script with ngen under elevated privileges.

Answer 2

What you could use here is one of the parameters that controls an application upgrade - HealthCheckWaitDurationSec. As per Application upgrade parameters doc -

"This duration can also be considered as the time an application should be running before it can be considered healthy"

As for permissions,

By default, Service Fabric applications run under the account that the Fabric.exe process runs under. Service Fabric also provides the capability to run applications under a local user or system account. In the application manifest, you define the user accounts required to run services or secure resources in the Principals section.

As for cleanup, it depends on what you mean by that. The code artifacts will eventually get wiped off. You could also use UnregisterUnusedApplicationVersionsAfterUpgrade parameter in the deployment script of yours to unregister any unused application versions that exist after an upgrade is finished, which should facilitate to the cleanup of stuff no more in use.