Updated: Sep 21, 2018
by David Hallberg
In my first blog a few weeks ago about Millennium’s chart servers, I talked about the need to determine which of your chart servers is the fastest (that is, which server prints each page of your organization’s charts in the shortest period of time) and how to make a fairly simple adjustment to speed up the slower servers. By copying the configuration of the fastest server’s operating system to the other servers, the processing time from our sample site increased an average of more than 1 second per page over its five chart servers. So why don’t I move on to a new topic? Why would we do anything else to the chart servers after getting them to perform in the same manner?
As I’ve touched on in the past, a frequently misunderstood concept for tuning Millennium is that making one change will cure a problem forever (see “A Healthy Dose of Doubt”). A second misunderstanding is that good change control dictates that you only change one thing in Millennium at a time. These sound very good on the surface. After all, how often are we told to start small when making our New Year’s resolutions? If we want to lose weight, we will have better long-term success by choosing one change that we can maintain rather than a bunch of quick fixes.
With Millennium, however, things aren’t that simple. The Oracle schema (a fancy name for the way the data is held in the database) alone has more than 300 tablespaces, 4,400 tables and 11,000 indices. A system can have anywhere from a handful (say, five) of chart servers to more than 20 defined and functional chart servers. Changing one row per chart table per change request window under a system of every-other-week change control means that chart changes could take a year to complete. Why would you want your organization to suffer for that long?
I’m suggesting that you can address most of your chart performance issues in three change windows. I’ve already covered the first — making all of the chart servers have the same baseline Windows and Word image. Today I’ll help you tune some of the Oracle database tables affecting chart performance (click here for the details), and next we’ll look at ways to tune your Windows operating system just a little more.
Prognosis: A comprehensive tuning approach will increase the performance of your chart servers (much to the delight of clinicians and other chart users) and will give you a solid base from which you can monitor for future throughput issues.