performance issue opening up dialogs from container

[wadhwani]

I have just implemented some VL web apps to replace WAMs and seeing some performance issues where opening up a dialog from a view is slow/sluggish. The number of I/O in the server modules have been streamlined and I don't think we are doing too many calls. However there is a noticeable delay in opening up dialog.

Any suggestions on what I can do to improve performance? The previous WAMs doing similar functions were fast and 'zippy'. Don't know if I need to make the server modules smaller by moving server routines into multiple smaller ones. Cannot figure out where the bottleneck is. Our iSeries is quite fast power9 with lots of memory and very low cpu usage. We are using a model B front end and the windows server seems adequate with 16 gb memory.

Please let me know if anybody has experienced this kind of issue and possible resolutions.

Thanks
Gary

[Pablo]

Hi Gary,

First thing I'd do is use either your browser's developer tools (F12) or Fiddler.

Either option will show you the network traffic and the time the different files take to load in numbers and graphically.

That'll show you were the bottleneck is which may prompt you to post some other question.

Hope this helps.
Pablo

[jyoung]

Hi Gary,

First thing to do would be to identify if it the slow down is on the server or client.

If you are using Chrome (other browsers have similar tools) open up the Dev Tools (Ctrl+Shift+J), click on the Network Tab and make sure XHR is selected. Run through your app and you should see the data requests from the client to the server modules. If those are returning quickly, you know its not on the server and has to be on the client.

Your looking for something like this

Capture.PNG (19.67 KiB) Viewed 16798 times

I can see that this request took 1.59 seconds and is 2.3 KB.

I've had performance issues when using MD Dropdown lists with numerous list items, which caused me to rework the design to use an AutoComplete instead. Interestingly enough, I don't experience this with the Desktop style drop down.

Joe

[wadhwani]

Thanks let me do some additional debugging. Is the size of the server module significant in load/execute time?

[davidbalansa]

Hi Gary,

How do you call your server routines. Do you use xxxx.Execute or xxxx.ExecuteAsync? If using xxxx.Execute, it pauses execution the client until the server routine returns. If you use xxxx.ExecuteAsync, processing on the client (UI setup etc..) will continue while your server routine is running on the server.

David

[wadhwani]

mainly doing execute instead of executeasync because in some cases I need results of previous calls to do next. I have not tried to consolidate multiple call results into one server routine because it makes things not as modular and I would rather have smaller server routines which I can use in multiple places.

I did do some debugging using chrome tools as suggested and I am seeing some instances where server routines are being called when I am not expecting them to be. I may call server routines only say after a drop down change but sometimes looks like things are getting fired off even though screen is still loading and no user has input anything.

Still trying to understand the sequence of events when a view is loaded up and displayed to understand how to improve performance.

[Pablo]

Hi Gary,

Regarding the reason for using Execute vs ExecuteAsynch you can easily solve it by firing an event OnComplete of the server call.

Define_evt SomeEvent

#ServerRoutine.ExecuteAsync

Evtroutine Handling(#ServerRoutine.Completed)

Signal SomeEvent

Endroutine

Then

Evtroutine Handling(#com_owner.someevent)

here you do whatever is next

endroutine

Regards,
Pablo

[Pablo]

Hi Gary,

Did you get to the bottom of this and if yes could you share your findings?

Thanks in advance.
Pablo