WebClient is Disastrously S L O W???

Hi Folks

When running web client from developer my solution is pretty useless since it’s taking up to 10 seconds to navigate one record to another. If I jump 10 or 20 records it could take 30 seconds to navigate there.

Smart client (in developer) works fine and has the speed I’d expect.

Its running in IE7 on a fast machine on ‘http://localhost:8080/servoy-webclient/solutions/solution/solution_xyz’ as you would anticipate.

Edited: It seems this is only in the table views of the data. In a record view I have a nextb / prev button and that navigates records as quickly as I’d expect. Table view is really slow though!

Q. Where should I start to look for potential errors and bottlenecks?

Set a breakpoint and start debuggin I think…

Is there anything triggered on events. Maybe disable it all and see what happens. When you are ‘up to speed again’ enable the event actions/methods one by one again…

Also worth checking calculated fields that are on the Table view. If you have unstored calculations they will be recalculated on display so multiply that by number of rows and you might find a lot of activity.

Open Servoy-Admin goto Performance data - clear statistics then navigate from one record to another and review the data. This will show you which queries are firing and how fast/slow they are.

Thanks Guys (Marcel and Graham), I’ll try the stats first then debug if I need further.

I had’nt appreciated that thre might be such a large difference between the speed of the Web as opposed to the Smart clients doing the same thing.

grahamg:
Also worth checking calculated fields that are on the Table view. If you have unstored calculations they will be recalculated on display so multiply that by number of rows and you might find a lot of activity.

Open Servoy-Admin goto Performance data - clear statistics then navigate from one record to another and review the data. This will show you which queries are firing and how fast/slow they are.

Graham - there is an aggregate on one column in that table.

Will that slow it down like an unstored calc?

If that aggregate is not displayed in the tableview - though its on the table itself I assume it will have the same effect?

Yes the aggregate column will need to be updated so that you have latest info - not an issue when developing but once deployed you could have multiple people adding/changing the data that will be in the aggregate.

Couple more thoughts:
Do you need the aggregate visible in table?
Could it be displayed on the detail screen - or a side-panel next to the table
If it has to be on list explore if the aggregate total could be setup as a stored_calc field - this will display much faster.

Finally I’m surprised that you have a speed difference between Rich Client & web Client - in my experience they usually very similar. Have you got any anti-virus software that is checking IE7?

HTH

grahamg:
Yes the aggregate column will need to be updated so that you have latest info - not an issue when developing but once deployed you could have multiple people adding/changing the data that will be in the aggregate.

If stored calcs or aggregates are not shown in the table (just on the detail form) will the tableview be speeded up Graham? It seems to me that Servoy is still retrieving the entire rows even if they are not in the tableview?

grahamg:
Finally I’m surprised that you have a speed difference between Rich Client & web Client - in my experience they usually very similar. Have you got any anti-virus software that is checking IE7?

I’ve tried this on several PC’s Graham - different AV and also now different browsers. Same result.

Thanks for your thoughts Graham.

How many fields there are in the table view? Can you post a screenshot? Check also the weight of the generated webpage (try to save it and see how many KB).

ngervasi:
How many fields there are in the table view? Can you post a screenshot? Check also the weight of the generated webpage (try to save it and see how many KB).

Not sure if I did this correctly Nicola but saving that IE Page resulted in a file 2.16 MB !!!. Unreal!!!

There are 28 columns in the table, and 3 of them are calculations. I’ve tried running it with out the calculated columns but it seems to make little difference to speed and navigation.

Most of these columns are required to allow the user to sort / find on selected patterns. I use ‘find’ too for specified columns (not in the table - but in the record view) but the primary user data-review is in the table. There are no images or other exotic columns in there - just text, boolean and number / integers. I find it hard to believe there is that much data in 200 of these records?

Attached the table from Smart Client (dev) and Web Client (Dev).

[attachment=1]ListTable.jpg[/attachment]

[attachment=0]ListTableWeb.jpg[/attachment]

Appreciate the feedback.

I’ve noticed that this runs significantly faster in Chrome too, though still not at the speed I’d expect for a workable app.

It seems you indeed display a LOT of data in the tableview, try limit the data shown and implement sort/find in different ways (like with a form in dialog)

Jan Blok:
It seems you indeed display a LOT of data in the tableview, try limit the data shown and implement sort/find in different ways (like with a form in dialog)

Thanks for the feedback Jan, unfortunately there is a requirement for users to have access to this table for speed editing as well as sorting and finding etc. A lot of users use the table as a means of skimming the data and its a lot more intuitive for inexperienced users.

One approach that might give me both (lower download overhead and the table usability) is to have a limited number of rows returned at a time, much like the Servoy limitation of 200 rows in the foundset.

Is it possible to change that foundset limit on a form by form basis? If not what strategy would you suggest as a limiter for this table paging? What methods could I look at to simplify this and keep the functionality?

Appreciate your feedback.

Make your body part less tall and a page navigator will show earlier

Jan Blok:
Make your body part less tall and a page navigator will show earlier

Doh… :oops: :shock: :? :D