bad performance on Mac clients

Questions, answers, tips and ideas on Servoy Client

bad performance on Mac clients

Postby tgs » Fri Jun 06, 2008 9:14 am

Hello!

We have a performance problem with the Mac clients (PPC + Intel) in the network. On lauching the smart clients, the performance is good for 2 or 3 hours. Then the speed for changing forms, starting transactions and so on is going down to freeze the Client. On waiting 5 to 10 minutes it's working again for the next 30 minutes....
The MS SQL-Sever is on a Win XP machine, the Firewalls on the Client PC's are off. A Servoy Server logfile is attached for a better help.

Regards, Thomas
Attachments
Servoy Server Administration.pdf
(88.47 KiB) Downloaded 337 times
Thomas Schnaus
SAN Developer
yomotec GmbH
User avatar
tgs
 
Posts: 886
Joined: Wed Oct 04, 2006 12:05 pm
Location: Germany

Postby swingman » Fri Jun 06, 2008 10:02 am

Hi Thomas,

I'm also not getting the performance I would expect on the Mac (10.4.x, Java 1.5), but we don't have that many freezes.

I can see from your log that you end up with deadlocks maybe caused by the transactions.

Not sure this applies in your case: A long time ago I was coding with transactions in Servoy, possible in version 2.0, and found that starting a transaction in Servoy would lock up an entire table. This meant that I could only wrap transactions around code which would execute in one go. So, you can't use transactions when a user edits a form, since it may take a while -- but you can have one around a few lines of code when you save.
Christian Batchelor
Certified Servoy Developer
Batchelor Associates Ltd, London, UK
http://www.batchelorassociates.co.uk

http://www.postgresql.org - The world's most advanced open source database.
User avatar
swingman
 
Posts: 1472
Joined: Wed Oct 01, 2003 10:20 am
Location: London

Postby tgs » Fri Jun 06, 2008 10:27 am

Hi Christian,

thank you for your fast replay! Your answer is very interessting for me, because I liked to use transactions (start, rollback, commit) for creating new records and editing. It is an easy way to have always an option to cancel the last changes. It will be a lot of work to change my methodes, but if that will be a better solution and performance I do.
Thomas Schnaus
SAN Developer
yomotec GmbH
User avatar
tgs
 
Posts: 886
Joined: Wed Oct 04, 2006 12:05 pm
Location: Germany

Postby swingman » Fri Jun 06, 2008 2:17 pm

Hi Thomas,

if the scenario I outlined is the cause of your problems, you can try the following; not tested it ;-)

- Add an integer field to the table as a 'flag'.
- Add a foundset filter on your main form so only records with the flag set will show.
- Set the flag on all existing records.
- When you Edit a new record, the 'flag' is not set, so it does not show, even if saved.
- When you click 'Save' the flag gets set, so it will show on your main forms.
- When you click 'Cancel' you delete the record rather than roll back.
- You can add a script to reuse or delete unflagged records older than some time (you don't want to delete records being edited)

Let me know if it works...
Christian Batchelor
Certified Servoy Developer
Batchelor Associates Ltd, London, UK
http://www.batchelorassociates.co.uk

http://www.postgresql.org - The world's most advanced open source database.
User avatar
swingman
 
Posts: 1472
Joined: Wed Oct 01, 2003 10:20 am
Location: London

Postby tgs » Fri Jun 06, 2008 2:51 pm

Ok, I will try that out. An other thing is to handle saved existing records. Edited records should set back (rollback) to the previous values with 'cancel' when perhaps inserted wrong values. Editing records in my opinion have to be saved by confirming the action and not on entering data, or?
Thomas Schnaus
SAN Developer
yomotec GmbH
User avatar
tgs
 
Posts: 886
Joined: Wed Oct 04, 2006 12:05 pm
Location: Germany

Postby tgs » Fri Jun 06, 2008 2:57 pm

Yet another point maybe is, that in practice customers hold transactions started for a longer time (more than 5 or 10 minutes) before they commit with the 'save' button. Could this cause the performance problem?
Thomas Schnaus
SAN Developer
yomotec GmbH
User avatar
tgs
 
Posts: 886
Joined: Wed Oct 04, 2006 12:05 pm
Location: Germany

Postby swingman » Fri Jun 06, 2008 3:06 pm

tgs wrote:Yet another point maybe is, that in practice customers hold transactions started for a longer time (more than 5 or 10 minutes) before they commit with the 'save' button. Could this cause the performance problem?


That is what I suspect.
Christian Batchelor
Certified Servoy Developer
Batchelor Associates Ltd, London, UK
http://www.batchelorassociates.co.uk

http://www.postgresql.org - The world's most advanced open source database.
User avatar
swingman
 
Posts: 1472
Joined: Wed Oct 01, 2003 10:20 am
Location: London

Postby swingman » Fri Jun 06, 2008 3:17 pm

tgs wrote:Ok, I will try that out. An other thing is to handle saved existing records. Edited records should set back (rollback) to the previous values with 'cancel' when perhaps inserted wrong values. Editing records in my opinion have to be saved by confirming the action and not on entering data, or?


This behaviour is what you often see with web forms, as a side-effect of the limitations of HTTP. You can get around it with Ajax.

In Servoy, I use field validation and the on_save table event to reject bad data, so I don't have any distinct 'edit' mode with a possibility to cancel. Keep it simple.

Now, you you want to go down a more complex route, you could deal with edit the following way:
- Assume each user only logged on once and editing one record in the table at any time.
- Each user has an id.
- Table filter only shows records with positive id.
- Create a record for each user with id = -userid.
These records will normally not show.
When user wants to edit, you copy the record you want to edit to the 'user specific record' and show using your 'edit' form. On save you copy back, on 'cancel' you don't. You just need to find a way not to lose the original pk of the record...
Christian Batchelor
Certified Servoy Developer
Batchelor Associates Ltd, London, UK
http://www.batchelorassociates.co.uk

http://www.postgresql.org - The world's most advanced open source database.
User avatar
swingman
 
Posts: 1472
Joined: Wed Oct 01, 2003 10:20 am
Location: London

Postby ROCLASI » Fri Jun 06, 2008 3:25 pm

Why not using the servoy 'transactions' (i.e. disable autosave and save manually) ?
That will work exactly like a webform does.

Hope this helps.
Robert Ivens
SAN Developer / Servoy Valued Professional / Servoy Certified Developer

ROCLASI Software Solutions / JBS Group, Partner
Mastodon: @roclasi
--
ServoyForge - Building Open Source Software.
PostgreSQL - The world's most advanced open source database.
User avatar
ROCLASI
Servoy Expert
 
Posts: 5438
Joined: Thu Oct 02, 2003 9:49 am
Location: Netherlands/Belgium

Postby swingman » Fri Jun 06, 2008 4:17 pm

ROCLASI wrote:Why not using the servoy 'transactions' (i.e. disable autosave and save manually) ?
That will work exactly like a webform does.

Hope this helps.


You are right, that should work well ;-)
Christian Batchelor
Certified Servoy Developer
Batchelor Associates Ltd, London, UK
http://www.batchelorassociates.co.uk

http://www.postgresql.org - The world's most advanced open source database.
User avatar
swingman
 
Posts: 1472
Joined: Wed Oct 01, 2003 10:20 am
Location: London

Postby tgs » Sun Jun 08, 2008 3:50 pm

In a new workaround I replaced the transaction functions:
databaseManager.startTransaction()
databaseManager.rollbackTransaction()
databaseManager.commitTransaction()
databaseManager.hasTransaction()

to

databaseManager.setAutoSave()
databaseManager.getAutoSave()
databaseManager.rollbackEditedRecords()
databaseManager.saveData()

and that is working well. I have only to do a few changes in my code. But deleting a record can't be canceled with a rollback.
Thank you for your suggestions.
Thomas Schnaus
SAN Developer
yomotec GmbH
User avatar
tgs
 
Posts: 886
Joined: Wed Oct 04, 2006 12:05 pm
Location: Germany

Postby Robert Huber » Sun Jun 08, 2008 10:50 pm

Why not use Servoy transaction?

Because it is in praxi quite to extremely lavishly! Sounds easy but for real applications to handle all possible cases and allow for a rollback is extremely lavishly - my opinion only.

Best regards, Robert

ROCLASI wrote:Why not using the servoy 'transactions' (i.e. disable autosave and save manually) ?
That will work exactly like a webform does.

Hope this helps.
Robert Huber
7r gmbh, Switzerland
SAN Developer
www.seven-r.ch
User avatar
Robert Huber
 
Posts: 1239
Joined: Tue Aug 23, 2005 6:52 pm
Location: Schaffhausen, Switzerland

Postby ROCLASI » Mon Jun 09, 2008 12:01 am

Hi Robert,

Not everything is perfect. In this case Thomas can't use database transactions with his choice of back-end database (MS-SQL) due to deadlocks (whole tables are locked when using transactions) so an all in-memory approach is a better solution.
So depending on your use Servoy transactions might be the best and even painless solution.
For all other situations where using Servoy transactions don't suffice I am sure you all know your way to the support system for bug reports and feature requests.
Robert Ivens
SAN Developer / Servoy Valued Professional / Servoy Certified Developer

ROCLASI Software Solutions / JBS Group, Partner
Mastodon: @roclasi
--
ServoyForge - Building Open Source Software.
PostgreSQL - The world's most advanced open source database.
User avatar
ROCLASI
Servoy Expert
 
Posts: 5438
Joined: Thu Oct 02, 2003 9:49 am
Location: Netherlands/Belgium

Postby Robert Huber » Mon Jun 09, 2008 8:20 am

Hi Robert

ROCLASI wrote:Hi Robert,

Not everything is perfect.


Agree!

ROCLASI wrote:In this case Thomas can't use database transactions with his choice of back-end database (MS-SQL) due to deadlocks (whole tables are locked when using transactions) so an all in-memory approach is a better solution.


Is this a general problem with MS-SQL? Or "only" in combination with Servoy?

ROCLASI wrote:So depending on your use Servoy transactions might be the best and even painless solution.
For all other situations where using Servoy transactions don't suffice I am sure you all know your way to the support system for bug reports and feature requests.


That's true :-)

Regards, Robert
Robert Huber
7r gmbh, Switzerland
SAN Developer
www.seven-r.ch
User avatar
Robert Huber
 
Posts: 1239
Joined: Tue Aug 23, 2005 6:52 pm
Location: Schaffhausen, Switzerland

Postby ROCLASI » Mon Jun 09, 2008 9:54 am

Robert Huber wrote:Hi Robert
ROCLASI wrote:In this case Thomas can't use database transactions with his choice of back-end database (MS-SQL) due to deadlocks (whole tables are locked when using transactions) so an all in-memory approach is a better solution.


Is this a general problem with MS-SQL? Or "only" in combination with Servoy?

Assuming that database transactions are managed, as the name implies, on the database I would say yes. I also did some quick googling and found other instances of table locks in MS-SQL using other (MS) technologies as well.
You would think a modern (O)RDBMS would support row-level locking instead of table locking when using transactions (I know PostgreSQL and Oracle do).
Then again using database transactions and keeping them open for 5+ minutes could also be seen as misuse of transactions. I don't think they were ever designed for that.
I think a combination of in-memory 'transactions' and the final write to the database using database transactions might be the best approach.
Robert Ivens
SAN Developer / Servoy Valued Professional / Servoy Certified Developer

ROCLASI Software Solutions / JBS Group, Partner
Mastodon: @roclasi
--
ServoyForge - Building Open Source Software.
PostgreSQL - The world's most advanced open source database.
User avatar
ROCLASI
Servoy Expert
 
Posts: 5438
Joined: Thu Oct 02, 2003 9:49 am
Location: Netherlands/Belgium

Next

Return to Servoy Client

Who is online

Users browsing this forum: No registered users and 9 guests