Omnis App Server settings and JS remote forms
Thank you Stene for sharing your findings. Very helpful.
From: omnisdev-en [mailto:email@example.com] On Behalf Of Sten-Erik Björling
Sent: Wednesday, February 14, 2018 2:59 AM
To: OmnisDev List – English
Subject: Omnis App Server settings and JS remote forms
After some digging, evaluation and some development and testing I have got my JS test environment stable (touch wood) using the DVD Rental database as a test platform for different approaches. Below are some of the things that I have learned when interacting with other Omnis developers and their experiences (Andrew Stolarz, Mayada Al-Kishtini, Jan Eskilsson) and some digging in the mail list (Doug Easterbrook etc.).
Below is a short description:
From Andrew Stolarz:
1. Make sure you are running with multithreading on.
2. Set the $serverstacks in the startup task of the library to something like do $root.$prefs.$serverstacks.$assign(20)
3. Set the $stacklimit in the startup task of the library to something like do $root.$modes.$stacklimit.$assign(40)
From experience I would not go higher in number here in #2 and #3 above.
1- added onbeforeunload=”jOmnis.onUnload()” to your html template:
So change this tag:
2- added a time out to my remote task to disconnect any idle connection after 30 mins..you can adjust that based on your need to avoid running out of licenses.
After running the Vivaldi validation tool for the remote form html page there turned up some notes in regard to the pragma tag and an eventual problematic call to scripts. These are corrected in the template files linked in this mail.
I am running macOS X Server and one problem that turned up was that App Nap got involved after a period of time – rending the Omnis App Server unusable. Link below to solve the problem where supplied by Doug Easterbrook:
Of course one should look into automatic turn-off, disk resting modes etc. if you are using standard hard drives etc.
On macOS X one can activate ”Performance Mode” which changes the overall setup of the system to be more response and more aggressive in processor cycles delegation to server processes. These and other tips are presented at the link below:
I strongly recommend the use of session pools, SQL workers and other worker approaches and to hunt down millisecond delays everywhere… The Omnis side of the execution in the DVD Rental example are mostly around half a millisecond – the longest operations are the ones executed at the Postgres DB – at most around 3-4 milliseconds in this small example. The limiting factor here is the DB server.
What is problematic with these performance optimisations is that the Omnis implementation of push in more complex contexts slows down things significantly – the optimisations on the web server and the OS are suboptimal. The third-party implementation chosen (Pollymer) introduces delays in the transmission between the server and the client that proportionally are drastic. The average example is that Omnis App Server finalises its routines (including the search effort of the Postgres DB) mostly within 2-4 milliseconds but the push mechanism in multiple sub-form approaches introduces wait-times of between 250-900 milliseconds per subform – this added to the delays introduced by the network access. This has to be improved!
Please feel free to massacre this and give alternatives…
Take care, all the best…
Kyrkogatan 5A 2 tr
SE-972 32 Luleå
Mobile: +46-70-655 11 72
Hotmail / Messenger: firstname.lastname@example.org
This email and any files transmitted with it are confidential, may be legally privileged and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, please note that any use, distribution, or reproduction of the contents of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by return email and destroy all copies of the original message including any attachments thereto. Thank you.
Please note that we take reasonable precautions to prevent the transmission of viruses; however, we cannot guarantee that this email or its attachments are free from viruses. We only send and receive emails on the basis that we are not be liable for any loss or damage resulting from the opening of this message and/or attachments.