One of the issues that had plagued EvalS (an evaluation performance application/portlet) from the beginning was a performance issue. EvalS was the first jsr 286 that we wrote for the Luminis portal. During the first several releases we worked hard to improve the performance by reducing the # of queries and caching whenever possible. In the past, whenever a person would first load the portal page containing EvalS it would take about 5-6 seconds for it to finish loading the page.

This EvalS performance defect affected all users, only after their initial login. This type of performance was not something we were proud of, so over time we worked on improving the code base, and performance of the backend code. A few months ago, we dedicated some resources to finally fix the problem once and for all.

Our initial assumptions were that the EvalS specific code was slow due to it not being optimized for the number of employees and jobs at OSU. This assumption proved to be incorrect once our development environment included enough random data to match the amount of records in production. After a careful analysis of EvalS and the differences between production & development, a small piece of code external to EvalS, but which EvalS relied on was the identified as the culprit.

The problem:
When a person first accesses EvalS, the application needs to figure out the ONID username of the person. It was this piece of code causing the problem and slowing down the application for the person when they first logged into the application. We never expected this piece of code to be a problem, that’s why we didn’t look into it at first.

The Luminis portal doesn’t store the ONID’s username in the User_ table of the portal. Instead it uses a random # and stores it in the “screenName” column. This is the column where the ONID username would usually be stored. We use an sql query to translate between the random Luminis # assigned to each user and their ONID username. One of the joins this query was using didn’t contain the necessary indexes. This was making the query slow.

The solution:
The fix was rather simple once the culprit was identified. The owner of the external query created a new table that we queried instead. This table contained the necessary data along with needed indexes. EvalS now queries this table and the speed has improved drastically.

We should have challenged our assumptions when we were troubleshooting this performance issue, but we have learned some valuable lessons from our mistakes, which will be helpful in the future. In current and future projects, we now test & analyze the performance of the application early during the development stages. Our development environment now includes enough random data to match the amount of data in production and allow for growth.  Moving forward in this way allows us to demystify application behaviors.

Central Web Services in partnership with Human Resources and University Business Centers on Friday, with assistance from Enterprise Computing, deployed version 1.0.0 of the EvalS MyOSU portlet application on Friday, September 30th, 2011.  What is EvalS?  It’s an electronically-driven performance evaluation system designed to assist supervisors and employees to complete their annual goal-setting and appraisal tasks.  This project, sponsored by the Provost, was almost a 9 month effort to understand, improve and deliver efficiencies to the evaluation process of Classified Employees (not including IT Classified).  As everyone knows, it is largely a paper process, and it takes many person hours to process and work with paper documents.  This application is the first step in making that process much easier.

Now while we deployed the application, unfortunately the first feedback is for the application’s own performance to improve.  So for those seeing it on the Employee page of the MyOSU Portal, and if you have notification of something needing to be done, then it might be just a little bit slow to bring up the appraisal form.  Don’t worry though, we are investigating the problem and looking at options to boost its performance, because we know that for you this is not good enough to fully use.  The paper process per the notification in the portlet is still available to use, however, if you have the patience, you can use it electronically, until such time as we fix the speed problem.  If you do use it, please don’t hit reload multiple times, and don’t forget to save any drafts, and please be patient.

Once the application is performing, we’ll put another post out here to talk more about it and the process of development.

In the meantime, if you want to find out more about it and how to use it, visit the Evals page.