Venue: Breakaway 2
Initial Thoughts
- Creating a 2-million patient test data set to stress test OpenMRS
- Having an OpenMRS release focused solely on performance improvement
- How many data clerks & managers can access the system at once
- Using replication to offload reporting from the "operational" system
- Optimizing Tomcat configuration
- Look at notes from How to Start an Implementation
Goals
- How well is OpenMRS currently performing?
- What are hardware requirements?
- For people using low-power systems, how far can they go?
- How much bandwidth is needed to do data entry via the internet?
- Can OpenMRS have a chance at scaling?
- How do you optimize MySQL configuration?
- How is OpenMRS' performance affected by different databases (e.g., SQL Server 2008)?
- What global properties exist for performance tuning?
Notes
Current performance
- With large implementations, it can take 15 seconds or more to find a patient and 30-60 seconds to load the patient dashboard
- Pentium 4 w/ 256 MB was slow managing 700,00 patients
- What are hardware requirements?
- Most systems are using at least 4 GB of RAM, some on a server and others on a desktop
- Performance Testing
- Saptarshi blogged about this
- Glassfish may be more scalable than Tomcat
- What global properties exist for performance tuning?
- patient.identifierPrefix - change from % to blank (empty)
- patient.identifierRegex - change from % to blank (empty)
- patient.identifierSuffix - change from % to blank (empty)
- patient.searchMaxResults - set to maximum matches you think a person would be willing to search through (e.g., 100 or 1000)
Are we over-AJAXed?
Do we*really need interactive search?
-
- Could we make the search delay duration a global property? And make AJAX real-time patient search optional via global property?
How many users of the system
- AMPATH has ~25 data entry users working concurrently
- Even 6 active users can be slowed if the same system is being used for reporting (cohort builder or data exports)
- Avoiding power outage issues
- ExtraDB is an alternative to InnoDB that handles crashes better and performs better
TODO
- Make a ticket for Fix the patient search widget faster
- Make AJAX real-time search optional & delay time settable via global properties
- Avoid downloading all patients
- Fix the patient dashboard
- Lazy loading of data