Performance tip - $root.$prefs.$maxCacheClasses

[Doug Easterbrook]

hi Mike:

I was not speaking of data cache ---  I was talking about read only cache for the omnis code and window classes --- things that are *read only* from the studio library that loads and then you execute it.      Thats stuff you definitely want cached into ram.   The performance improvement is substantial.


database caching --   you definitely want that too for purposes of read only data.     and you want a database and operating system combination that attempts to guarantees write through to disk on commits (ie -- the very things that are done by a database server to make a database ACID compliant).

so, read cache is good everywhere.


Raid cards, in fact, can be *harmful*.     If they are configured to buffer writes and lead the database processes to think that the data has been committed to disk, then you are walking a fine line, battery backup or not.      In all cases, you want to configure the raid card and operating system to ensure that its has a write through cache configured so that writes to the cache are immediately written to non volatile media - like the hard disk.    Because if it isn't --  you are in trouble if the raid card dies or the battery dies

this is worth a read if you think you are protected.  simply having a battery backup in a raid card isn't the insurance people think they are getting.  Its far deeper than that.

http://www.postgresql.org/docs/9.4/static/wal-reliability.html


While that lists things a DBA should do and the article is related to postgres --   imagine what your database server is (or is not doing) to guarantee data integrity.   If you are using omnis datafiles as the storage mechanism, you have to do some of this setup yourself if you want enterprise level safety in your data storage.

for what its worth --

Doug Easterbrook
Arts Management Systems Ltd.
mailto:doug at artsman.com
http://www.artsman.com
Phone (403) 536-1205    Fax (403) 536-1210

> On Dec 22, 2014, at 1:45 AM, Mike Matthews <omnis at lineal.co.uk> wrote:
> 
> As always, use cacheing with care.  When Studio goes BOOM, and it does, I have lost changes to certain class types when this happens.  So the more that are cached, the more chance there is of loosing the data as it is cached and may not be properly saved back to disk.
> 
> I often loose changes to Queries, even if I have closed the class window, these change are only saved HARD, i.e. back to disk when I quit Studio and restart.
> 
> We always provide RAID cards for our servers with a battery backup in case the power fails AND the UPS runs out.  So don't get tricked into using caches too much.
> 
> Mike
> 
> 
> 
> 
> 
> 
> Mike Matthews,
> Managing Director, SQLWorks Software Ltd
> 
> 
> 
> SQLWorks replaces Sage, ACT!, Opera, Access, SAP
> 
> On 22 Dec 2014, at 04:06, Doug Easterbrook <doug at artsman.com> wrote:
> 
>> hi all:
>> 
>> I was playing around with our Omnis Studio library on the weekend - which has some 3000+ classes in it.   It performs really well, but I hit a small snag trying to make it perform well under the scenario where the library was not on the same drive as the application…   There is a reason that I want the library on a server (macintish - network user situation)
>> 
>> performance went down - dismally.
>> 
>> and then I discovered my saviour — a preference that can be set at run time.
>> 
>> 
>> $root.$prefs.$maxCacheClasses
>> 
>> 
>> initally it was set to 300 (as it has been for years)…. and so I set it up at 5000 - just for giggles.      After the initial load of my library by the omnis runtime, I got a bunch of performance back because more of the classes are being stored in ram.
>> 
>> so if you are not aware of this setting — its worth knowing.
>> 
>> you can also look at
>> sys(190) - to see the number of classes loaded by the runtime and
>> sys(191) - to see the number of classes discarded out of cache
>> 
>> 
>> its really a lot faster if your app is not discarding classes out of the cache because $root.$prefs.$maxCacheClasses is set too low.
>> 
>> 
>> thats my learning for the weekend.   hope it helps somebody.
>> 
>> 
>> 
>> 
>> 
>> Doug Easterbrook
>> Arts Management Systems Ltd.
>> mailto:doug at artsman.com
>> http://www.artsman.com
>> Phone (403) 536-1205    Fax (403) 536-1210
>> 
>> _____________________________________________________________
>> Manage your list subscriptions at http://lists.omnis-dev.com
> 
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com