With the recent popularity of our nVision drilling snap-on, we’ve had the opportunity to talk to many customers about nVision drilling performance, and how to improve it. Based on these discussions, I decided it was time to put a blog posting out that discusses it.
Let’s start by discussing the two settings in PeopleSoft that cause 80% of the performance issues. Many DBA’s will tell you that there is never a simple fast/slow switch that they can set (otherwise, why would you set it to slow?). We, in our infinite wisdom at PeopleSoft put this switch in place on the process scheduer and application messaging products.
Okay. That’s not very fair, because these settings were put in place for something different than nVision drilling, and drilling is merely affected by these settings. However, based on the default values of these settings, nVision drilling can have a latency of 30 seconds or more.
The two settings to look at are polling intervals of the process scheduler and the application messaging dispatcher. For each of them, the default setting is set to 15 seconds, which means that with the default settings, the process scheduler will wait 15 seconds between times it checks to see if you’ve requested a process to run (i.e. a drilldown request), and the message dispatcher will wait 15 seconds between times it checks to see if there’s a message for it to process (such as a report being completed).
Therefore, if it normally takes around 30 seconds to run a drill and you’re using the default settings, reducing them will improve your performance (but keep in mind, that the server is doing more work by checking the queues more frequently).
Other areas to look at:
There are several other things that can affect the performance of your drills:
The Anatomy of running a drill
When you run a drill in nVision (whether you run it through our snap-on, or you use PeopleSoft-delivered functionality), it does the following things:
There! All done! Wasn’t that easy and simple? So, you can see how the latency of the polling can affect how long it takes to get drill results. However, the PSREPORTS servlet, web server performance, and the performance of the REN server can also affect the delivery time.
The PSREPORTS servlet is the process that moves content into and out of the report repository. As you may notice, it is called 3 times when drilling. Once to get the report from which you are drilling, once to post the drill results to the report repository, and once to deliver the drill results to the end-user. The PSREPORTS servlet is actually a pretty small and simple program. All it does is authenticate the user, check whether he has access to the report, and copy the file.
Usually, when there are performance issues, it’s caused by the file system used by the report repository or by network performance issues between the process scheduler server and the report repository (although network performance between the end-user and the report repository can also be a culprit, you’ll see performance issues with anything you access from report manager).
Web Server Performance
The interface between the client requesting the drill and nVision is through the web server (i.e. a PIA page). If there are web server performance issues between the client machine and your PeopleSoft web server, you’ll also have performance issues with drilling.
REN Server Performance
The REN Server handles the messaging between PeopleSoft and the browser page. PeopleSoft’s internet architecture was designed to allow a stateless connection between the browser and the server. This means that all interactions between the client and the server are request / reply. In other words, you put some data in a page, post it, the server processes it, and replies with a new web page. This means that a page cannot be out there waiting for an event to occur to do something.
In comes the REN server (Realtime Event Notification). What it does is it sends a message to a specially designed page when an event occurs (and the page does processing in it). The run to window page is one of these special pages (but the multichannel pages in CRM are also other special pages).
The REN server generally isn’t a performance problem, but can be if the application server machine that it runs on gets overloaded with too much other processing.
Now that you know more than you ever wanted to know about process scheduler, REN Server, and drilling, you can impress your co-workers at your next company function (or just annoy them).