OK. So here is what I think is going on with 8.2.2. And, the biggest caveat is I am not a SQL expert nor a programming expert.
Reading through the blog article is very helpful. Ignore the 3rd party stuff and just concentrate on how application caching is related to SQL is related to databases. Of course, SQL Server and the databases are one in what they call an "instance." So, instead replace SQL above with the SQL memory cache.
The speed of any AC application should be related to three things. How AC retrieves and writes information to the database. The SQL memory cache itself and the AC cache. The AC development team should control the first and third parts. SQL Server shouldn't be an issue and the queries stored in its memory aren't likely to make much of a difference. Again, IMHO.
So, first let's understand how the data in the databases on the server in the AC folder and AC works. An analogy would be say all of the information in your database was physically stored in your house. You get to your office and you open AC and a chart. Now you need data to enter into the chart. But, it's at home. So, you hop in your car, drive back home and find the data for Joe Smith and bring it back. Now, you open another chart. The data is at home. You drive home and get it. This is akin to opening a chart in AC and its going all the way to the database "hitting the database" on the hard drive on your server. Wouldn't it make more sense to bring all that data with you and load it in AC its cache. This is what it is doing when you see it preloading data for speed. But, you don't need to bring everything from your house, because you may not need it. If you do, you will have to run home and get it. But, now it will be loaded into AC's cache, so it will be faster next time. So, forgetting the analogy, a lot of data is preloaded into AC, but a lot of data is still in the database (or saved in SQL's memory cache -- but that is more complicated for now.) But, again, anything that keeps the query or the call from AC for data from hitting the database makes it faster. So, if it can use data from the SQL cache, then it is much faster. Just like the RAM in your computer is much faster than pulling data from your drive. So, keep in mind, that there is the AC cache, the SQL cache (these are different) and the physical databases on the server.
So, everytime while AC is running, that you ask for information: demographics, meds, summary of problems, etc., AC will look at the cache to see if it is right there. If not it goes to SQL and the database and gets it. That takes longer. But, now that you retrieved those summary problems or demographics which wasn't preloaded, it will be nearly instantaneous. So, do this. Go to a version which is working quickly. Open a chart of a busy patient. The chart loads relatively quickly pulling a lot of data from the preloaded cache. Now, click on Summary tab. Even in a fast version, there should be a small amount of lag. One second maybe. Now click on the demographics tab. A small lag. Now click on the summary tab again. It should be nearly instantaneous. The info is in AC's cache. Demo tab same way.
Now, here is an interesting but probably unnecessary fact. Especially on a slow program. Say you open a chart, and as we have been dealing with, it takes seven seconds. In our analogy, this would be because it needs additional data, and now you have to run home to get it. Or, go to the database. It opens, that data along with the preloaded data is retrieved and cached. Next time should be much quicker. You close it and open it again, and it is much faster. Maybe three seconds. Now click on another chart that hasn't been opened. It will not take seven seconds. (it shouldn't anyway). Why? Because some of the data you pulled from the database is common to the second chart.
OK, so you get the idea. The biggest factor here should be how AC works with the cache. My hypothesis is that somewhere in the development of 8.2.2, the way AC works with the cache both in storing data in and removing or deleting it is not optimal. Having data stored in the cache keeps you from having to grab data over the network and means less overhead for SQL. If fewer staff are using SQL and only the cache, then it will be more efficient.
The hypothesis above is hard coded. Meaning it will need to be fixed in a later version.
So, if this is the case, and AC knows it to be the case (again IF), then they know what has to be worked on. Which means we can all take a sigh of relief.
http://blog.idera.com/sql-server/pe...caching-to-boost-sql-server-performance/
