SystemWeaver is a high-performance infrastructure for the management of product data for complex systems with complex interactions across domains, levels and technology. It's based on a number of advanced technical solutions, integrated and optimized for over 15 years. By constantly developing, using and optimizing these solutions for the intended application - the management of product data for complex systems - Systemite can offer a product with a unique level of performance and scaleability.
As with any large modelling system, there are a number of factors that may affect performance. Below are a few guidelines we recommend that Architect users follow to ensure system performance is at its best.
Methods That can Affect Performance
The following methods are executed by the server, and can potentially affect system performance. You should only use one after verifying that it does not compromise the server operation and performance. Also, since these methods jump out of context, they should never be used when the result is assumed to be under configuration management. They should, for example, never be used in a Document script.
- Axis: back-to-part (Path Language)
- Axis: back (Path language). See /back:: vs Context:/back:: for how to use Context:/back:: instead.
- Axis: refobj-back-to-part (Path Language)
- ForEachItemReference (SystemWeaver Script Language)
Minimize Viewed Parts in Default View Setting
Give extra thought to which parts need to be "turned on" in the system's default structure tree view setting(s) since SystemWeaver caches data to the client memory for all parts that are "turned on" in the tree. Minimizing viewed parts increases performance for users. And, they can always chose to add parts to the view on-the-fly if needed.
Schedule Heavy Import Operations for Off-Peak Hours
System users have a lot to gain if heavy import operations, such as the scripted creation or modification of tens of thousands of items, e.g., test results, are scheduled for off-peak hours or outside of regular office hours. The reason being that client users working with related data may then search or pull up a structure that includes the new data and it will need to be read from the server and cached, putting additional load on the server. See our Guidelines for API Usage for recommendations with regards to API usage.
Use of Structural Parts for Nodes
The use of Structural part types rather than Simple part types should be limited to those part structures when it is necessary to create a unique part representation of each part in a specific part structure. This may be the case, for example, at the lower component level and is almost never the case at higher levels in an item structure. Structural part types create or add to a node structure and node structures can impact performance negatively for all system users, i.e., when structure part types are used, a parallel node structure exists which must be loaded along with the item structure. With overuse of structural parts, loading times can be excessive and cause performance issues for all system users.