Just as a heads, we’ve run into some performance problems on with Coreapps server with a relatively large database of 250,000 patients at our hospital in Haiti. The patient search had become quite slow (up to 30 seconds or so), and, additionally, was slowing down the system overall, and spiking the CPU load up to 30 during our busiest periods.
One thing we figured might be a problem is the “autosearch” functionality when typing in a patient’s name–ie, when a user types in a name, whenever there is a 500ms delay between keystrokes it runs a search. We figured this could be a big performance hog that had little benefit, so we disabled this functionality by simply settting the coreapps.searchDelayShort and coreapps.searchDelayLong global properties to very high values (ie 999999999), which essentially means an end user needs to hit Enter to trigger a search.
We noticed drastic performance improvements from the system has a whole after making this change, so would recommend it for any implementations for large databases. Also, I’d suggest that we made the “autosearch” and “opt in” feature by setting the default values of the searchDelay global properties to high values?
How about keeping the default behavior of searching as the user types? And then we add a neat feature that times searches, if 2+ requests takes longer than a certain amount of time each, we display a hint to tell the user to tweak the GP value to boost performance
@wyclif i agree with both your submissions. I have once in a while forgotten that i have to press ENTER in order to see the results, in some applications that require it. It looks like the instantaneous Google searches have spoilt me.
@mogoodrich thanks for sharing this real-world insight. Is it something that PIH turns off on all servers, or just the one? If it usually works fine for smaller installations, I’m tempted to leave the feature turned on.
I love @wyclif’s idea of tracking the behavior and warning the admin if the behavior is usually slow.
Of course the correct solution is to fix our patient search implementation to be backed by Lucene via hibernate-search, instead of our expensive SQL queries. Let’s prioritize this too!
The downside of leaving it as-is is that Mirebalais was significantly slowed down for months without anyone realizing that was the issue. We significantly improved the user experience for for dozens of users simply by changing a global property. At our other sites, I’d rather have the inconvenience of having to hit “enter” rather than risk the database growing and running slow for months before anyone noticed it/figured it out. But that may more be a symptom of our situation where we have many servers and few people monitoring them.