nVision Drilling Performance and Latency

By Larry Grey • April 20, 2006

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.

80% Rule
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).

  • Process Scheduler Changes: The Server settings page in PIA (PeopleTools –> Servers) is where the Sleep Time is set for a given server (default is 15 seconds)
  • Application Server Config Changes: In the application server config file (or using PSADMIN), there is a Scan Interval setting in the PSMSGDSP section, which sets the interval by which the message dispatcher sleeps between picking up requests (default is 15 seconds)

Other areas to look at:
There are several other things that can affect the performance of your drills:

  1. The performance of running reports. See the following posting for more information on general nVision performance tuning.
  2. Web Server Performance
  3. The performance of the PSREPORTS servlet (which moves reports to and from the report repository).
  4. The performance of the REN server (the application server process that makes running to window possible).

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:

  1. It opens a web page that passes parameters from the report and requests the drill to be run on the process scheduler.
  2. The process scheduler picks up the request and invokes nVision and requests it to run the drill.
  3. nVision launches and calls the PSREPORTS servlet to move the report you’re looking at from the report repository to the process scheduler server.
  4. nVision selects the cell you’re drilling from, and requests the drill to be run (which opens up the drill layout, generates the SQL and runs the drill in the same way that an nVision report is run).
  5. When the report is completed, the process scheduler calls the PSREPORTS servlet to move the drill results into the report repository and publishes a message that indicates that the report is finished (using application messaging).
  6. The message dispatcher takes the message and updates the metadata in the report manager tables, so that the report shows up and is available to the right people.
  7. The REN server is notified that the report is ready to be viewed, and it notifies the browser of the person running the drill.
  8. The browser invokes the URL to view the report, which calls the PSREPORTS servlet to access the drill results and download it to the client.

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.

In closing…

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).

Labels: , ,

Stay Updated

Request a Demo