Performance issues in Webclient version 9.1

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.

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

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?

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.

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.

Hi

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

Here it is:

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

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.