Most of our clients know at least one place in their Siebel solution, where they can click and then go grab some coffee while waiting for a response. Perhaps, there are such places in your Siebel system as well? Are users telling you that Siebel is slow? And do you know how to approach those issues?
Here I will try to cover most of the common solutions or approaches that could be taken in order to tackle the slow performance. I will base my suggestions on the experience that I have gained in ten or so different Siebel engagements, as well as performing quite a few configuration reviews. Having been reviewed by some of my colleagues with significant experience in this area, this article became a comprehensive summary of performance-related Siebel knowledge – something you are likely to benefit from, right away!
“Everything in Siebel is slooow” – that’s one of the most common complaints you hear, but this statement is seldom true. More often than not, some follow-up discussion would reveal that in fact only some areas appear to be slow, but those areas are typically used on a daily basis – hence the perception. The best way to approach this is to ask users – and not the only one who complained, but a few from different roles: “What are the three most annoying places, where you routinely see performance issues?” In their replies, you will most certainly see a pattern; what you need to do now is to address the highlighted areas, and then repeat the question again after a few months, in order to check the results and reveal the next set of pain points.
In most of the cases, however, the identified areas will fall into one of the categories:
Cause: large amount of data. Typically you would know the areas, where you have most of the records in the database. If you don’t, check with your database administrators, as they could provide you with a good insight about the amount of data, as well as its growth trends. If there are such “heavy” entities, then there are multiple approaches to tackle that. Check the underlying configuration – could it be that it is not optimal? Perhaps, some of the data that currently resides in those large tables could and should actually be separated from the main entity – identifying it would also help! This could turn out to be a quite significant change, because in an established solution multiple things are tied together; however, despite the potential complexity, in some cases this could turn out to be the best option on the table.
How to proceed:
Note that the above applies to issues introduced through configuration. There is, however, one extra case – and that case is Scripting. Applicable to almost any of the scenarios above, heavy scripts with additional queries or calculations on events like PreQuery, ChangeRecord or PreCanInvoke (this one runs most frequently, since it is checked on any change of each of the controls) that can severely impact your application are a definite subject for checking with your configuration team. I have seen cases when it is not possible to avoid using such heavy scripts, but either way those should be used with care.
All of the above relates to the navigation within the Siebel solution; there is, however, one typical area that has most of the performance issues, as stated in the beginning of the article: “press a button and get some coffee”. Sometimes those are processes that are triggered on a change or some other event; but the majority of such issues still are a result of a “button” being pressed.
Most certainly, if you have a button that takes a few minutes before it yields control back to the user, you need to tackle that one way or the other. You have more than one option: running the process in the background, re-thinking what the underlying process does and whether that is an optimal solution, checking the configuration – is it built according to the best practices? Are you using the full range of Siebel capabilities in this case?
Take your configuration team and check with them, what are the things that take so much time in the process, and try to optimize exactly that.
In the end, I would like to say that most performance problems will start showing up only when you accumulate more data, i.e. the solution gets used by more users, so be ready to review and improve the performance repeatedly, on a continuous basis. If you are facing performance issues developing a new solution, sit down with your development team and talk! You need to find the causes and solutions, as the performance will only get worse, so be sure to start tackling problems with as much handicap as you can possibly get!
Need assistance with configuration review and performance problem analysis? Give us a hint, we can help! And check out this slide deck for some more info:
|About the author: Guntis Valters has been with Idea Port Riga since March 2011, working with Oracle Siebel CRM for more than 8 years since the beginning of his career. Currently he specializes in configuration reviews, business analysis and engagements where quick understanding of customer business and issues is required.|