Performance and scalability

This chapter collects the main concepts behind Sardana’s performance characteristics. It is intentionally short and only states what can be grounded in the code base and the project changelog.

Events instead of polling

Sardana relies on the Tango event system rather than on client polling. The sardana Tango devices configure their attributes for change events and push them from the server code whenever the kernel produces a new value — e.g. position updates while a motor is moving, value updates of experimental channels, state transitions, or macro output and status from a Door. Clients (Spock, Taurus widgets, the macro API acting on elements) subscribe to these events and react when something actually changes.

The consequence for scalability is that the cost of monitoring is proportional to the rate of change, not to the number of connected clients times a polling frequency: many GUIs can watch the same beamline without multiplying the load on the Pool, and updates arrive with low latency instead of at the next polling period. During fast operations the event rate itself can become the bottleneck on the client side; for example, Spock output of high frequency (100 Hz) scans can be decimated (OutputDecimation view option, disabled by default).

MacroServer startup

When the MacroServer starts (and whenever macro libraries are reloaded), it scans all macro libraries on its MacroPath. Up to Sardana 3.6 this included eager source-code introspection of every discovered macro. Since Sardana 3.7.0 the code introspection in SardanaCode and SardanaLibrary is lazy: source lines are only extracted (and cached) the first time they are actually requested, e.g. when a client asks to display a macro’s code. With large macro libraries this significantly improves the MacroServer startup time, since startup cost is reduced to importing the modules and registering the macro metadata.

Large installations

A few architectural properties matter when an installation grows to many elements:

  • The sardana server can be split. A single process may host both the Pool and the MacroServer, but they can also be deployed as separate servers, and one MacroServer can connect to several Pools (see Client-server architecture). This allows distributing hardware over several processes/hosts and isolating slow hardware in its own Pool.

  • Controllers group hardware access. Operations on multiple elements of one controller are dispatched through the grouped controller API (PreStartAll/StartAll-style interfaces), so a controller can translate, for instance, the start of many axes or channels into a single hardware command instead of one communication per element.

  • Measurement group size. The acquisition of a measurement group is orchestrated per controller, and its overhead grows with the number of involved controllers and channels. For software synchronized continuous scans, large measurement groups increase the risk that channels cannot follow the synchronization pace, requiring a larger latency time or data interpolation (see Continuous scans).

  • Continuous scans move the load off the software stack. Where step scan performance is dominated by per-point software overhead (motion start/stop, acquisition start, readout), hardware synchronized continuous scans reduce the software role to preparation and data collection (see Synchronization), including the velocity adjustment and path extension mechanics described in Continuous scans.

Todo

Provide measured figures (element counts, event rates, startup times) for representative installations. No verified numbers are available in the repository at the time of writing.