Slow Response Issue

Slow Response Issue

Old forum URL: forums.lhotka.net/forums/t/7386.aspx

mafaraz posted on Sunday, August 02, 2009

Hi All,

We have developed an in-house product using the CSLA framework. It’s an enterprise level application with 500 users and around 300 plus screens. Its an N-tier application with winforms is used as frontend; dataportal is at the middle tier and Oracle 9i is used as the database.

The Dataportal & Database servers are hosted in the data center. Front-end application is used locally as well as in other outstations. For the local users performance is good and they are satisfied as we have almost unlimited bandwidth locally. But for the outstation users application performance is erratic sometimes its ok; sometimes its very poor. There are many factors contributing in the slow response like UI, network, database etc.

Dataportal server is setup in resilience environment. HTTP channel is used for remoting and the Dataportal server is hosted in IIS application. Public internet is used for the connectivity between outstation PCs and the dataportal server. Average bandwidth is around 512 Kbps between outstation PCs and the dataportal server.

Can anyone help us in suggesting the ways to reduce the slow response.

Regards
Faraz

sergeyb replied on Sunday, August 02, 2009

The quickest way I could think of is to convert portal to be WCF portal and use HTPP channel that implements compression.  You will just need to find a post here that has WCF HTTP compression library.

 

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

cid:_2_0648EA840648E85C001BBCB886257279
Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

 

From: mafaraz [mailto:cslanet@lhotka.net]
Sent: Sunday, August 02, 2009 4:47 AM
To: Sergey Barskiy
Subject: [CSLA .NET] Slow Response Issue

 

Hi All,

We have developed an in-house product using the CSLA framework. It???s an enterprise level application with 500 users and around 300 plus screens. Its an N-tier application with winforms is used as frontend; dataportal is at the middle tier and Oracle 9i is used as the database.

The Dataportal & Database servers are hosted in the data center. Front-end application is used locally as well as in other outstations. For the local users performance is good and they are satisfied as we have almost unlimited bandwidth locally. But for the outstation users application performance is erratic sometimes its ok; sometimes its very poor. There are many factors contributing in the slow response like UI, network, database etc.

Dataportal server is setup in resilience environment. HTTP channel is used for remoting and the Dataportal server is hosted in IIS application. Public internet is used for the connectivity between outstation PCs and the dataportal server. Average bandwidth is around 512 Kbps between outstation PCs and the dataportal server.

Can anyone help us in suggesting the ways to reduce the slow response.

Regards
Faraz

andy replied on Sunday, August 02, 2009

I have deployed my app in very similar environment. 
I had performance issue during initial deployement stage.
The performance was connection pool for odp.net.  I simply enabled it via configuration and resolved the issue.  Database connection is very resource intensive so one needs to treat with care.
I am still using .net remoting and do not see a need to switch over to WCF yet.
Just for your info, I have west coast users access my centralized server in the east coast with no performance issue at all.  I would suggest you to fine tune your back-end database.  It could be your app's major bottle neck.

 

Andy

mbblum replied on Sunday, August 02, 2009

Also make sure to remove un-needed saves and fetches to reduce network load.

In an app I inherited, the client app continually updated Date Last Maintained and Last User fields, causing every object to save even though nothing else changed. Revising the objects so these two fields did not cause IsDirty made a major performance improvement for us.

Smart loading or cache of lists, if not already being done, will help perforamance.

mafaraz replied on Monday, August 03, 2009


Dear All,

Thank you all for your valuable inputs.

@ sergeyb: Unfortunately we cannot change the application architecture as it requires lot of effort and time.

@ andy: Connection pooling is enabled at the database level and at the odp.net level.

@ mbblum: We have reviewed the entire application and reduce the no. of database calls. Also all the master data is cached at the application loading time asynchrounsly.

Regards,
Faraz


Paul Czywczynski replied on Monday, August 03, 2009

We started using Noemax about six months ago with good success. We cut our payload almost in half using Fast Infoset with compression. We're using WPF with our dataportal installed on an IIS7 web farm.

http://www.noemax.com/products/wcfx/index.html

-Paul

andy replied on Monday, August 03, 2009

Without know much detail about your implemtation / architeural design.   It's very difficult to pin point the problem.
Here are something you might want to explore:

1) Implement lazy loading(database intensive query for child list) 

2) Loading your object graph using "deep data" technique from Rocky.

My application have quite complex struture(parent->child-list->grand-child-list).
These techniques do really boost my application performance tremendously.

Andy

FraggleRocks replied on Monday, August 03, 2009

We have also had to overcome poor performance with enterprise windows-form applications. Here are our top tips, but I am sure that you have thought of these already.

You will probably find that the problem falls into 4 parts:
A: Form Painting - If you use a lot of custom controls you will need to optimise their painting. To get started profile your performance and understand where your bottlenecks are. Try using Jet-Brains performance tool if you are doing .NET forms.

B: Message Latency (i.e. ping time). Every client/server message exchange will be impacted by the time it takes the message to get there and back. Two things to tackle here are B1 - good-hosting to minimise the ping time for most users. B2 - alter your architecture to cut the NUMBER of synchronous messages.

C: Message Size. Larger messages take longer to process. If using WCF use custom binding to enable you to send data in binary rather than text format. Also look at the impact of message encryption, headers and the frequency of security information being exchanged. Also adjust business objects so that you only retrieve the data you need and post back data that has actually changed. Use a network trace tool to log all of you application in and out messages - this can be quite revealing.

D: Asynchronous / Synchronous behaviour. Ideally parts of your windows forms that can paint before data has arrived should do so. i.e. try and get some processing done whilst data is being read/written. Showing an animated "waiting" symbol can also make users more likely to be happy with poor performance.

ajj3085 replied on Monday, August 03, 2009

I think B & D are good ideas.

Remember... you don't actually need to increase performance, only make it SEEM as if its quicker.

RockfordLhotka replied on Monday, August 03, 2009

One thing to consider to achieve B, is to use unit of work objects.

If a form needs the business object, plus a few NVL or ROL objects, you really don't want to round-trip to the app server numerous times to get all those objects.

So create a unit of work object (usually a ReadOnlyBase or CommandBase) that goes to the server, gets all the needed objects and returns them in one call.

The most common scenario for a UOW is loading a form, and creating a ReadOnlyBase object to do this is pretty trivial.

http://forums.lhotka.net/forums/permalink/35162/35162/ShowThread.aspx#35162

RockfordLhotka replied on Monday, August 03, 2009

Also, although Remoting is very old now, you may be able to still find vendors with alternative Remoting channel implementations - possibly including a compressed channel?

Or, if you are using HTTP maybe you can turn on HTTP compression in IIS and get compression that way - I don't remember if Remoting was compatible with that option or not.

Copyright (c) Marimer LLC