Performance issues in Webclient version 9.1

Hello,

We are migrating old 7.6 processes to new 9.1 SR2 version of Metastorm and we are experiencing a MAJOR performance degrade when loading forms and trying to do database searches and displaying the result in a grid.

Searches that took 2-3 seconds to be shown in result grid before now takes 30-60 seconds to be displayed. First we thought that the bad performance could have something to do with that the code was migrated so we rewrote everything in "native" version 9 code, i.e. using new business objects. This did not help much.

It seems to be a correlation between old HW and really bad web client performance, but the problem in my case is that you don't tell a major 2500+ employee company to upgrade all their computers to be able to work with decent speed in a upgraded system that before the upgrade were quite snappy.

Our client has a mix of old and new computers running XP or windows 7, the corporate standard web browser is IE7.

My question is have not somebody else noticed this HUGE performance degrade in the web client? It's very silent in the forums.(Or it might be me doing crappy searches?)

Does anyone have any thoughts or improvements suggestions?

I will try to reach out to Metastorm support with this issue as well to see if we have done any major mistakes converting our processes.

One thing that's a lot better with version 9 though is the server side script execution, it's really fast. But that's not anything the users notice much because the rendering of client side pages take so long.

Regards,

Henrik?

Find more posts tagged with

BPM

Comments

Brian Mellert

Please keep us advised if you get more information from support, or any place else. I haven't migrated my major V7 maps to V9 solutions yet, but the plan is to do so soon ... and we have thousands of potential users so ....

Paul Lawrence

I think you will find it to be a performance issue with the new grids. We have had the same issue when migrated solutions perform dismally when compared to v7.6

I've not noticed any particular issues with te web cliet in general but if you have a form with grids and they return anything other than a small number of rows you are likely to experience problems. I did a lot of research around this and in our situation none of the infrastructure or platform components were the problem. Forms that returned a dozen or so rows performed without significant problem (although a lot slower than v7.6) but those that returned a thousand or so just resulted in a hung form. The issue seems to be that IE just bombs out the processor, not tried FF but it would be an interesting test.

I reported this to support some weeks ago but got no response.

The grids used are Telerik grids and if you research performance issues on the web you will find other that have problems with these controls.

Jerome_Pearce

Paul wrote:

I think you will find it to be a performance issue with the new grids. We have had the same issue when migrated solutions perform dismally when compared to v7.6

We have not found this to be the case, at least not when the associated Business Object is built from scratch (we do not even attempt to use the migrated Business Objects). If sensible paging is used, the results are usually very good. Overall the client can be slow, especially on opening forms for the first time, but grids do not make the forms any slower in my experience.

Jason_Broomfield

Can you try testing the same forms using IE8?

I have noticed a substantial performance increase in client side javascript code on the latest releases of IE which I believe is down to Microsoft shipping a more optimised javascript script engine in IE8 and above.

Jason

Grzegorz Lag

We have some similar problem (not with migrated processes). IE7 was the main problem for us. IE8 has much faster javascript engine, and forms works much faster.

Mike Gibson

I have recently completed re-writing a 7.6 app in version 9 and there is considerable performance issues with ie7 vs ie9. We have users all over the world and if the performance is bad here it will be worse in Paris or China. The issue is loading forms it just takes too long at this time. We are not expected to roll out ie9 as the company browser for at least a year. Right now this is a show stopper for me. Does anyone have any suggestions to get around this?

Grzegorz Lag

Hello Mike

You can split problem into two parts:

- "visual gadgets"

- big forms = big amount of data sent over network

Because Metastorm use telerik controls, there are many js client side scripts related with creating visual layout of controls. This unfortunately works very slow on IE7.

The same reason, forms with many controls sends to client big amount of data. We had some forms which send over 2MB of data every time.

You can :

- split forms into smaller (sometime impossible )

- try to switch on some optimization settings in web.config and use browser cache.

As I know there is no possibility to "simplify" visual layout of forms to work faster in IE7. Try to use FireFox ( I know that this is some time impossible ).

Brian Mellert

Mike is out -- new baby -- so responding on his behalf.

I do see that 9.1.2.2 is supposed to address a performance issue with grids, so hopefully this will help.

However, the Firm standard is IE (when dealing with PCs all over the globe, we have a locked down desktop) and IE9 will not begin to be rolled out until later this year and will extend into next year. Switching to FireFox is not an option.

Splitting the form into smaller segments (wizard like) isn't much of an option either on most of our forms -- per sponsor design. However, the one's Mike is having an issue with aren't that large in comparison, though there are lots of hidden widgets (checkboxes) on some of them to make things show/hide appropriately.

I believe we have at least the default optimization settings turned on and are using cache, though I suspect more tuning is needed though as far as I can tell not well documented.

Tony Wheeler

Hi Henrik,

Something you can try would be to uncomment the following 2 keys in the web client's web.config. I'm not sure if this would have any effect on the type of slowness you are experiencing, but it may be worth a try.

-Tony

Mike Gibson

Thanks for the info on the config settings those did help. My biggest pain at the moment seems to be how drop downs with a large amount of options opens. In IE 9 it flies and the drop down pops right open when you click the arrow. In IE7 it is very slow and clunky. We have over 3k entries in the list and they do all need to be there.

Jerome_Pearce

The IE7 issue seems to be universal. It is just slow with JScript it appears.

We have managed to get paged Business Objects working with dropdowns. It may be a solution. Let me know if it could be and I'll try to find it (it is posed somewhere here).

Graham Field

I've used Modal admin forms to provide a pop-up to select from large amounts of data, which on return updates the fields client side. You can pass in parameters to help selection. I have updated the grid selection event to take the value and pass it back. I did encounter a problem closing the form, but found if the form includes a cancel button, then I call this via buttonClick("buttonname") after setting the return value.

see http://metastorm.processmapping.com.au/post/Passing-data-back-to-parent-forms-4957667?highlight=modal

Graham

Mike Gibson

Jerome, that would be great if you could find the solution i would really appreciate it. Thanks,

Jerome_Pearce

Here it is:

http://metastorm.processmapping.com.au/post/Paged-Lists-and-Dropdowns-5619305

Grzegorz Lag

Dopdown with large amount of data is always big problem. Even if you use paging.

We have universal component to open popup with any source of data, and client side integration with MBPM. It support client side filtering, searching, and have many other features - like returning more than one value. This is propably best way if user should select any value from big amount of records.

Neil_Hudspeth

Here are a few comments and suggestions about the issues being discussed in this thread. Apologies if there is any repetition of earlier posts.

There have been improvements made to performance in every release of Version 9 so the later the version you are using, the more you will benefit from these.

As indicated elsewhere in the thread, IE7 is certainly slower than IE8 , IE9 or Firefox when rendering forms and it is down to the speed of processing scripts. Some tests that we undertook indicated that some forms with grids could be two and one half times slower.

Old hardware is also slower than new hardware (even if they have the same speed chips). If you can’t upgrade client PCs, try increasing client PCs Virtual Memory Allocation (System Properties | Advanced | Performance Settings). We have found that this can make an improvement is some cases.

There are some steps that you can take with form design to improve form rendering performance:

Make sure that Client Paging is turned on for grids. It speeds the rendering of the grid and makes it easier for the user as well.
For grids, take advantage of Business Object Page size which controls how many records are sent across the wire. These can either be set in the Business Object itself or on the Business Object instance on the form.
If you are using a dropdown to select the items to populate a grid, build the Business Object so that it only sends data back to the grid after the user has made a selection.
If you have one grid completely overlaying another and are using visibility to decide which grid to display to the user, build the Business Object so that it only returns data to the grid that is visible.
Using percent to size grid columns is significantly slower than using pixels. Improvements to performance of “percent” were made in 9.1.3 but I haven’t tested this and I suspect that while using percent will be faster, it will still be slower than using pixels.
Have the Business Object only return the data that is required. So don’t return all the columns in a table if you are only using the BO for a grid with four columns (unless you are using the other columns elsewhere on the form).
If you have dropdowns with large numbers of options, consider building two drop downs where the first one filters the list for the second one. This will speed it up and make it easier for the user.

Caching and Compression

There are a number of options available to cache items locally and / or compress data before it is sent across the wire. These are especially useful when users are accessing a server across a WAN or slow network. There is a trade-off between the processing required to compress and uncompress the data and the time saved across the wire so this is not a universal panacea.

Take Advantage of AJAX Compression (Telerik.Web.UI.RadCompression). This is documented in 9.1.3.
Consider turning on Dynamic File Compression in IIS. Static file compression is turned on in IIS by default but Dynamic File Compression is not. Much of the data sent to the client is in dynamic files.
Activate the browser cache by adding the appropriate key to the web.config file. This was added in 9.0.3.2. Check documentation for details. This causes local caching of images and scripts and saves them being repeated sent across the wire every time the user loads the form. Note you don’t see the full impact of this until the third time any particular form is opened.
Take advantage of content expiration on the web server. This minimises the number of downloads to the browser.

I hope that this helps.