Best Practices for Improving Windchill REST Services Performance
General guidelines on how to use Windchill REST Services (WRS) include:
• Windchill REST Services follows the OData specifications, and it is strongly recommended that you get familiar with OData. Refer to the information on the OData website at https://www.odata.org/
• Refer to the following resources for more information on OData:
• It is also recommended to read the documentation in the WRS Help Center.
• JSON is the preferred format when interacting with Windchill REST service.
The following are the best practices for improving Windchill REST Services performance:
• For GET operations, when possible, use the $select query parameter in the request. Retrieving only those attributes that are required in the response increases the performance.
• Avoid the $orderby query parameter if it is not required. Similar to SQL, $orderby in WRS is resource-intensive, as it is processed after the result set is returned.
• For large result sets, it is recommended to fetch the maximum page size (for example, odata.maxpagesize=2000) instead of looping through multiple pages. Depending on the search criteria, pagination may rerun the query for each page:
 |
While retrieving smaller result sets (for example, last 10 work items), retrieve only those number of objects that are required.
|
|
|
The max page size has a direct impact on server memory utilization. In high concurrency scenarios, setting odata.maxpagesize above 2000 can lead to slow responses and server memory bottleneck.
|
• While creating or updating multiple objects simultaneously, use the multi-object endpoints (for example, /CreateParts). Multi-object endpoints are more efficient than a batch request. The operation is similar to creating multiple objects in Windchill.
• You can use batch requests in the following cases:
◦ In high latency environment for reducing network overhead while sending multiple requests.
◦ When multiple different operations are related and should be accomplished in a single transaction (OData changeset), for example:
a. Check out the 123 document.
b. Update the working copy of the document checked out in step 1.
c. Check in the working copy of the document updated in step 2.
• To retrieve report results for large datasets, use the Query Builder utility for better performance. For information on Query Builder, refer to the Reports and Queries topic in the Windchill Help Center. You can also refer to the PTC Reporting Domain topic in the WRS Help Center to retrieve report results.
• Filtering on navigation properties, for example, $filter=Attachments/any(d:contains(d/PTC.ApplicationData/Format,'<attachmentformat>')) has negative performance impact.
◦ Filtering on navigation properties does not apply to navigations and properties that have the traversal attribute defined (for example, CreatedBy, ModifiedBy).
◦ If filtering on a navigation property is required, set the maxpagesize to a larger number for faster results overall.
• Filtering on server-calculated attributes (SCA) or non-persisted attributes (NPA) has negative performance impact. If filtering on SCA or NPA is required, set the maxpagesize to a larger number for faster results overall.
• While searching a product structure, when possible, use the GetPartStructure() or GetPartsList() action with a navigation criteria.
• Setting the disableSecureInfoProcessingOnProperties property to true can improve performance when the response includes null or non-accessible properties. When set to true, it disables the second-pass processing during serialization. Therefore, the PTC.AccessException annotation will not be present in the response. For more information, see Windchill REST Services Properties.
|
|
While it can improve performances, the client will not be able to know whether the property is null because it is not accessible or because it has no value.
|
• Subtypes
◦ Using isOf along with another filter criteria with an “or” operator has negative performance impact. For example, $filter=isof(PTC.ProdMgmt.SoftPart1) or Name eq ‘GOLF_CART’.
◦ If it is required to combine isOf and “or” for filtering, set the maxpagesize to a larger number for faster results overall.
◦ While retrieving an entity collection, if the subtype is known, call the derived entity endpoint directly, for example, /ProdMgmt/Parts/Model.ElectricalPart or /ProdMgmt/Parts/PTC.ProdMgmt.ElectricalPart.
• Conduct performance testing at scale. It will help tune the Windchill system appropriately and can help in identifying non-performant queries.
◦ If some specific searches take an extremely long time, consider these two alternatives to improve query performances:
▪ Create Query Builder reports and use the “Reporting” domain to get the report result.
▪ Create a custom OData Action or Function and write a performant QuerySpec. Windchill customization best practices apply while creating the custom Actions or Functions. The supported APIs are documented in Javadoc. You can search a Javadoc in the Knowledge Base at PTC eSupport.
|
|
Both alternatives are in disagreement with the RESTful design. However, currently, this is the best way to get the best performances for extremely specific custom queries. These implementations are static and are not future-proof or flexible. They should be evaluated on a case-by-case basis.
|
◦ WRS load testing can be done using JMeter.
• Sizing
◦ WRS requests are processed by foreground Method servers.
◦ Standard Windchill Sizing Guidelines apply.
◦ External WRS calls are required to be factored when sizing Windchill. If you have 1000 users searching and getting documents and representations through WRS, they should be added to the sizing calculator.
◦ If WRS is used for machine-to-machine communication with high-frequency service invocation, this should also be factored in.
▪ If a lot of concurrent requests are performed, it is recommended to add more Method servers, nodes in the cluster, and CPU/memory for the DBMS and Windchill.
▪ To scale up Apache, refer the following PTC technical support article: https://www.ptc.com/en/support/article/CS109573—How to increase Apache maximum connections in the Windchill PDMLink
◦ WRS leverages Windchill search:
▪ Search performance tuning practices based on usage (for example, DB indices) apply.
▪ Windchill Profiler, Windchill Configuration Assistant (WCA), PTC Performance Advisor, Windchill logs, DB performance reports are some of the tools to troubleshoot and tune performances.
Also, refer to the PTC technical support articles, https://www.ptc.com/en/support/article/CS287984 (Data to Collect for Performance Troubleshooting in Windchill) and https://www.ptc.com/en/support/article/CS153338 (Windchill System Performance Tuning).
▪ PTC Technical Support can help with troubleshooting performance issues and performance tuning.
• To implement custom services, follow the Microsoft RESTful web API design as much as possible. Avoid Actions and Functions and use HTTP verbs (GET, POST, PATCH, PUT, DELETE) when possible.
◦ Refer to the Customizing Domains, Processing HTTP Requests for OData URLs, and Examples for Customizing Domains topics in the WRS Help Center.
◦ Avoid using Info*Engine.
• Update your Windchill system regularly (for information on the latest available CPS and upgrades, refer to PTC Release Advisor).
• It is recommended to implement client-side caching to improve performances and reduce the network traffic in the following scenarios that are not related only to WRS:
◦ If the same information is consistently being fetched from Windchill (for example, Context ID and Folder ID used to create parts).
◦ If the retrieved data is relatively static (for example, type hierarchy, attributes, life cycle templates, and so on).