Difference between revisions of "Performance Tweaks"
Jump to navigation
Jump to search
Line 19: | Line 19: | ||
<li>Run the [[Database Maintenance Script]] and consider shrinking the database.<br/> | <li>Run the [[Database Maintenance Script]] and consider shrinking the database.<br/> | ||
<i>In addition, performance can be degraded if the physical file size of the database does not fit entirely in system memory.</i></li> | <i>In addition, performance can be degraded if the physical file size of the database does not fit entirely in system memory.</i></li> | ||
<li>Turn off [[Label_Printer_Installation|bi-directional support]]. This is a setting under the Ports tab in the printer properties of each of your label printers.<br/> | <li>Turn off [[Label_Printer_Installation|bi-directional support]]. This is a setting under the Ports tab in the printer properties of each of your label printers. Similarly, the booking in screen can freeze if printing is being blocked by security, e.g. a service account being deactivated.<br/> | ||
<i>Please do not underestimate the performance impact of | <i>Please do not underestimate the performance impact of bi-directional support even if you have never heard of it before</i></li> | ||
<li>Consider whether your prescription types are set up correctly so that they [[Our prescriptions are not clearing automatically|clear automatically when finished]]. Also see [[User_Views_%26_Homepages#Actions_menu|how to clear lots of prescriptions at once]].<br/> | <li>Consider whether your prescription types are set up correctly so that they [[Our prescriptions are not clearing automatically|clear automatically when finished]]. Also see [[User_Views_%26_Homepages#Actions_menu|how to clear lots of prescriptions at once]].<br/> | ||
<i>We very frequently see PTS configured in such a way that prescription types are marked to require collection, but "collection" is never actually recorded. If and when a user view is configured to return completed, but uncollected prescriptions, this results in PTS continually trying to load a list of ever growing uncollected prescriptions until eventually the server cannot cope with the load. See [[Our prescriptions are not clearing automatically|this page]] for more.</i></li> | <i>We very frequently see PTS configured in such a way that prescription types are marked to require collection, but "collection" is never actually recorded. If and when a user view is configured to return completed, but uncollected prescriptions, this results in PTS continually trying to load a list of ever growing uncollected prescriptions until eventually the server cannot cope with the load. See [[Our prescriptions are not clearing automatically|this page]] for more.</i></li> |
Revision as of 13:26, 25 September 2024
Like all software, PTS 5 is not immune to occasional temporary performance issues.
Symptoms
Various functions of the PTS application take an unsatisfactory amount of time to load or to process.
Common causes
- The database has grown large and the data has become fragmented.
- Printer settings are not optimal.
- Prescriptions are not being cleared from users homepages and the server cannot cope with the large volume of them.
- Other software on a shared server is hogging resources.
- An unoptimised or expensive third party query is hitting the PTS database.
- A Power BI report is hammering the database server with network traffic.
- The server/s only meet the bare minimum hardware requirements.
- PTS is trying to reach tmsinsight.com for support contract and software licensing notifications, but your PTS server has no access to the internet.
Solutions
- Run the Database Maintenance Script and consider shrinking the database.
In addition, performance can be degraded if the physical file size of the database does not fit entirely in system memory. - Turn off bi-directional support. This is a setting under the Ports tab in the printer properties of each of your label printers. Similarly, the booking in screen can freeze if printing is being blocked by security, e.g. a service account being deactivated.
Please do not underestimate the performance impact of bi-directional support even if you have never heard of it before - Consider whether your prescription types are set up correctly so that they clear automatically when finished. Also see how to clear lots of prescriptions at once.
We very frequently see PTS configured in such a way that prescription types are marked to require collection, but "collection" is never actually recorded. If and when a user view is configured to return completed, but uncollected prescriptions, this results in PTS continually trying to load a list of ever growing uncollected prescriptions until eventually the server cannot cope with the load. See this page for more. - Use a resource monitor or the SQL performance dashboard to identify the application at fault and then contact the manufacturer.
- Use SQL performance dashboard to identify the expensive query and have IT or the manufacturer optimise it and/or reduce its frequency.
This issue seems to be becoming more common, please test your queries for performance at scale before rollout - This issue in particular seems to slow down Booking In, and other database inserts. While we encourage the use of external analysis tools, be sure to monitor and minimise the impact on network traffic on the PTS server/s.
- Consider upgrading your server hardware to the recommended PTS 5 specification.
- In Setup > Application Settings, locate the "skip checking if PTS is online" setting (OFFLINE) and set to Yes. This tells PTS not to attempt any remote connections.