Process Mapping Logo

Process Mapping - Forums

Sharing 19 years of knowledge and experience

Metastorm BPM forums
Sign up Latest Topics

  Author   Comment  

Posts: 16
Reply with quote  #1 
Hello all,

I'm using version 9.4.
We have some users that recently started using a process designed on MBPM. But have been experimenting a really slow rendering of forms. There are running on a rather slow connection, and opening a form sometimes takes up to 1 min.

Doing some research on forums and documentation I've applied the following change:
"The UseBrowserCache setting in the Web Client web.config file enables caching of
images and scripts from the engine eAttachmentTable on the client browser:
<add key="UseBrowserCache" value="1" />"

This does not seem to have made a difference, due to the fact that when analyzing the network only two resources seem to come from cache.

Any insight on this or if I'm missing an additional setup so that content is cache to user's browser?

Also I've performed these additional adjustments:
- Set common HTTP response Headers to expire web content after xx days
- Turned on dynamic content compression
- Enabled AJAX Compression
- Enabled HTTP Compresison

Even though performance improved a bit, it is still slow at form opening (also reviewed form design to improve rendering performance).

Any other suggestion on what else to check or what else can be modified to improve site performance?

Thanks in advance.



Avatar / Picture

Posts: 113
Reply with quote  #2 
Often issues with very slow rendering forms is due to the form design itself.

Typically if a large form is loading and has multiple dependencies then this can take a long time to load. If you actually need a large and complex form then you might want to consider breaking this into sections and using a chained action route. This way you only load the part of the form that is required.

Try to keep forms within the viewable area of the screen. This does limit the area available for the users but also concentrates the mind on the information that is actually useful and appropriate. MBPM does not typically like a large form with lots of dependencies and these can take minutes to load. Early versions we dubbed by the users as 'workslow' due to exactly this.

Lots of activity in the process on action start and on form load can slow the performance of the form render. both are performed when the action starts and the form isn't rendered until both are complete. Take a look at your process to see if there are efficiencies that can be gained there.

Biggest factor is possibly dependencies, followed by the on form load and on action start. All of these will impact performance of form rendering.

I dare say there will be other factors that are making an impact but this is where I would look first.

Posts: 16
Reply with quote  #3 
Thank you KarlD, for your input on this.

We've been checking to see how we can improve current forms, but it doesn't seem to make an impact on form rendering.

Perhaps, here is some additional information.

In current process design we have implemented chained actions to reduce the impact of big forms, also we have "search options" with few controls(in which performance is really slow as well), and we have tried to make it as simple as possible.

Also, to submit a "Comments" form it takes a bit for the form to be submitted, that is why we are trying to look into different options or aspects of the setup that we might check into, but have not been successful.


Posts: 210
Reply with quote  #4 
Any grids or drop downs on the form that return a long list?  I've seen those cause quite a performance hit on form load because it will run the queries when the form loads up.

I've had a few search options on forms that caused a long delay in form load.  By changing them out so they don't search or return 0 on load that helped out tremendously.  Example: Design the query to only return something when the search is used instead of a query that returns everything until you filter upon it to find what you're looking for.

Avatar / Picture

Senior Member
Posts: 61
Reply with quote  #5 
On the grids, are the Business Objects returning all results or the first few pages worth of data? Paged and the first page worth of data is the quickest. Are the dropdowns using Business Objects, I tend to use the Statement option containing SelectSql(null, " Sql Statement").List which I believe provides better performance since it's one less DB connection. As a general rule, I only use business objects for grids. make sure you're not using new default() as the first part of the SelectSql statement, since it needs to open a new connection for each one.

I have found Fiddler V4 on the client helps to identify if any other items are causing an issue. Someone once put a 6mb image at the top of the screen, which really slowed down the screen loading.

On the database, run a SQL profiler to see how many reads are being performed and the SQL cost.

Cheers Graham Field
Previous Topic | Next Topic

Quick Navigation:

Create your own forum with Website Toolbox!