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.
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 ….
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.
> 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.
Can you try testing the same forms using IE8?
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?
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 :( ).
Mike is out – new baby – so responding on his behalf.
I do see that 188.8.131.52 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.
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.
<add key="UseBrowserCache" value="1" />
<add key="UseQuickResize" value="1" />
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.
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).
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 <a data-ignore="a/b" target="_blank" href="http://metastorm.processmapping.com.au/post/Passing-data-back-to-parent-forms-4957667?highlight=modal">http://metastorm.processmapping.com.au/post/Passing-data-back-to-parent-forms-4957667?highlight=modal</a>
Jerome, that would be great if you could find the solution i would really appreciate it. Thanks,
Here it is:
<a data-ignore="a/b" target="_blank" href="http://metastorm.processmapping.com.au/post/Paged-Lists-and-Dropdowns-5619305">http://metastorm.processmapping.com.au/post/Paged-Lists-and-Dropdowns-5619305</a>
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.
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:
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.
I hope that this helps.
You need to sign in before voting.
You need to sign in before voting.