Hi peggers.
OE 11.6.3 64bits running on Linux (Red Hat).
Linux Machine : 256GB RAM , 64 cores (8 x 8), storage with ssd disks.
I would like to know what the cost in term of memory and processor if enable the cacheinfo for all the users .
Application have 12 databases (sum mor os less 1,2TB).
Have 600 users
50 appserver connections (running some machine databases)
50 connections webspeed
30 connections SQL
20 4GL local connections
450 client/servers users
Progress pre-allocates for statement cache 256 bytes of shared memory per session. If the size of information for a client exceeds this limit than the information will be stored in the temp .cst files.
Overheads of enabling statement caching is negligible if you set _Connect-CachingType to 3 (One Time Capture). Wait a sampling interval, check what session did in the previous moment and set _Connect-CachingType to 3 again. Other values (1 and 2) are meaningless because they are non-efficient: a session may update the information a thousand times per second but your program will read it only once per a few seconds or minutes.
Also note that _Connect-CachingType = 0 turns off caching but you will not return to an initial state before the statement caching was enabled. Additional USR latch activity will be persistent until db restart.
In general I avoid turning it on for all clients and leaving it on for long periods. Historically some releases of Progress have had some regrettable bugs with this feature. So you should be very careful with it.
I find that it is a very good idea to set the temp-directory *before* collecting any data. It really ought to follow -T but it does not.
If your clients are making remote connections rather than self-service connections there can be unexpected overhead.
Unlike George I find _connect-cachingType = 1 to be useful. Yes, it may be updated far more often than it can be checked but if you don't know in advance when you want to check I think that it is impractical to use option 3.
Option 2, the "stack" option is usually of most use for a session that is being targeted for a specific reason -- not so useful for "all users" types of things. This option also has the largest performance impact.
IMHO, SQL connections should have type = 1 set by default. That way you would always be able to see SQL queries that are executing.
Keep in mind that this data is only updated when your code communicates with the db engine -- it will not tell you what is going on with non-db 4gl statements. For a 4gl stack trace at an arbitrary point in time you should use "progetStack".