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?
I completely agree! Thanks @mogoodrich for looking into this and sharing!
Agree!! I’ve implemented a similar change to enhance the performance of patient search.
Cool, I’ve added a ticket here:
Was going to go ahead and do it, but figured it would be a good intro ticket for someone new?
It depends on how critical or urgently needed it is. A few intro tickets take years to get some love.
I have no objection, but the default behavior I see for most applications is to perform searches as the user types
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!
I went ahead and turned it off everywhere, but on smaller servers it isn’t a problem.
Tracking behavior like @wyclif say sounds cool.
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.
Fair points. Let’s go ahead and turn this off everywhere by default (and
expect to restore it by default after we are using Lucene).
But let’s ensure it is documented as a common thing people may want to turn
on in the reference application docs.
-Darius (by phone)