While using master, it has been observeed that the following applications in OSCAR require speed optimization: the eChart, Inbox, Tickler list, Consultation List and OSCAR Messages. Additionally McMaster is moving to using the mysql cluster for OSCAR's database. In order to use clustering for Oscar, some changes have been required.
The change to casemgmt_note table reflects the ability to stripe data across data nodes. In this case each demographic's notes will be stored on one data node. For example, demographic 1's notes will be on node 1 and demographic 2's notes will be on node 2 and so on. This is accomplished by using the primary key for notes to include the unique note id and the demographic_no. This change will have a neutral impact on InnoDB and MyISAM storage engines.
The other changes to code and queries will noticeably improve performace for any storage engine. The inbox has been streamlined as well as the loading of consultation lists and tickler lists. The queries for OSCAR messages have been optimized.
Inbox, messages, demographic information, general database changes
This is a fairly wide-ranging change but the integration points are largely very small and easily checkable.
Oscar users will be unable to use MySQL clustering, key parts of the system will be slower than necessary.
Conduct thorough testing on inbox and messaging (run different views and ensure all items are correctly listed). Review labs and ensure they are displaying patient names correctly. Open the JSPs which have been modified and ensure the correct information is being displayed for the lines that have been modified.
No user-facing changes.
Completed.
Commit: https://source.oscartools.org:8080/#/c/13873/
Excellent idea.
More efficient code is very much needed and will alone speed up Oscar.
I’m curious how quality assurance was maintained during development. Did you develop a JUnit test case for each class before the change was performed and then ran it to ensure the method outputs are the same? This is very important because history has proven that performing User Test Cases at the User QA level for massive code changes is not sufficient.
It says below that development is complete. What is the release time frame for these changes? Will all the code be committed only to master and then reviewed for inclusion in the next Oscar Release candidate ( i.e.: Oscar 18 )? In other words, I don’t think anyone is ready for changes this extensive to be introduced into Oscar 15 Beta right now.
Also.
This feature request sounds like there may be an additional goal to optimize Oscar so that it can be served as a highly efficient ASP option - which is the only time Oscar fits one of these MySQL Cluster candidates. Not a problem if this is the case - but the benefits should be outlined.
A: Ideal applications include:
High volume OLTP
Real time analytics
Ecommerce and financial trading with fraud detection
Mobile and micro-payments
Session management & caching
Feed streaming, analysis and recommendations
Content management and delivery
Massively Multiplayer Online Games
Communications and presence services
Subscriber/user profile management and entitlements
Isn’t MySQL Clustering overkill for clinic hosted server where the bottleneck usually exists in the network?
Do you have any hard data to prove that implementation of MySQL Cluster - with out a doubt - improves Oscar performance for an average clinic hosted server?
Can the clustering option be disabled? And if so, does the absence of this option have any adverse affect on Oscar’s functionality?
Dennis Warren
Consultant
Colcamex Resources
dwarren@colcamex.com
778.386.9264
Related
Feature Requests: #1421
Diff: