Omnis App Server settings and JS remote forms
thanks for this post, it was very very helpful for me.
for those doing web-ish development and testing in the macos environment,
watch out for the pre-fetching that Safari and Chrome do – you might have
pages loaded by your browser before you ask for them.
drove me nuts during debugging more than once until i checked the server
logs and realized the pages were prefetched before my code requested them.
and I must take my hat off to Das – it is fascinating following his
re-emergence into the Omnis realm.
I left IT project management in 2012 to return to software development
(with new emphasis on responsive web development, after long time of
developing omnis desktop apps) so I recognize his pain points very well.
hang in there buddy, it does get easier. the best thing about being an
independent developer for small workgroups (the original traditional Omnis
market) is that you usually get to call the shots regarding
IT infrastructure, design, tools, etc.
there certainly has never been a better time to be a developer; so many
niches to fill, so many opportunities (especially when you are able to work
for yourself), and so many competitors who do not have your long term
coding experience designing integrated systems
From: Sten-Erik Bj?rling
> Subject: Omnis App Server settings and JS remote forms
> Dear all,
> 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.
> From Mayada:
> 1- added onbeforeunload=”jOmnis.onUnload()” to your html template:
> So change this tag:
> To read :
> *onbeforeunload=”jOmnis.onUnload()” *style=”margin:0;overflow:auto”>
> 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.
> Stene comments:
> 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
> 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?
> Sten-Erik Bj?rling
> Enviro Data
> Kyrkogatan 5A 2 tr
> SE-972 32 Lule?
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:email@example.com