I missed your question... sorry.
- No admin-changes were done
- And No changes to Groups of the type View/Change were done
This is from BMC KB KM-000000024487. It doesn't answer your ? directly,
but is full of good information.
What may cause poor performance in the Admin Tool?
When poor performance is seen in the Admin Tool when saving objects, it
may be a result of how AR Server handles information it has read into
memory.
At server startup, AR Server reads information from the database into
memory, for example all field properties are read into memory, all users
and groups and active links, etc.
When this information that has been read into memory changes, there are
two different ways for AR Server to handle the event.
It can update the existing memory footprint so that users all see the
change that was made.
It can create a separate memory footprint so existing users still utilize
the existing memory footprint, while new users logging in would utilize
the new memory footprint.
Either method will cause a performance hit, but the big difference between
the two ways of handling the event is where the performance impact is
seen.
Note: How noticeable the performance hit is depends on several factors,
but mostly the amount of data that needs to be read into memory. This is
usually a direct result of the number of objects (forms and workflow) that
exist. The more objects, the greater the performance impact.
Is there a way to improve performance or control which option AR Server
uses?
Yes. There is a server configuration, called Development Cache Mode, that
was introduced to help with performance when dealing with systems that
have large amounts of forms and workflow objects in a development
environment. The Cache-Mode setting is available in ARServer 6.0.1 patch
1339 and above, and in ARServer 5.1.2 patch 1338 and above as well as in
6.3 and above. Note: only the 6.3 and above Admin Tool shows the GUI
checkbox for Development Cache Mode in the Server Information dialog on
the Configuration tab. If you're using an Admin Tool that does not have
the checkbox for Development Cache Mode, then the Cache-Mode parameter
must be manually added to the ar.cfg file.
It can be found in the Admin Tool under File->Server Information on the
Configuration tab. It is a check box called "Development Cache Mode" and
by default, it is not selected.
When selected, it puts a parameter in the ar.cfg/ar.conf file called
Cache-Mode: 1.
There are two cache modes, production and development.
In production mode (Cache-Mode: 0), which is the default behavior if the
line is not set in ar.cfg/ar.conf file (i.e. the Development Cache Mode is
not checked in the Admin Tool), AR Server operates as it always has --
whenever an admin operation will change the memory cache, the admin thread
makes a new copy of the memory cache and makes its changes there. While
this slows performance for the admin making the change, it allows the
change to be made without affecting other users of the system so it's
appropriate for a production environment with many users.
In development mode (Cache-Mode: 1 in the ar.cfg/ar.conf file or where
the Development Cache Mode is selected in the Admin Tool), the admin
thread will instead lock other threads out of the current copy of the
cache while it makes its change in that copy. On each API call that will
cause a change to the cache, the admin thread locks the cache, waits for
all other threads to stop using the cache, makes its modifications, and
unlocks the cache. The thread locks the entire cache, which means other
threads cannot process API calls or escalations while the admin thread
processes its API call. In a development environment this should be an
acceptable cost.
This effectively gives priority to the administrator at the expense of
other users. It is therefore not really suitable for a production
environment (blocking all users for the entire time that that the change
is taking place is not good in production), but is great where development
is the primary aim of the system.
This mode (development mode) has a couple of notable effects --
The first is that the server will no longer copy the cache, though it will
wait for user operations to complete before it proceeds with making a
change. This will almost always be faster than copying the cache and the
difference in time will be greater with the number of objects on the
server. In other words, the larger the application and number of objects
(i.e. forms, active links, etc.) on the server, the greater the effect of
the cache mode will be.
The second is that the server's memory footprint will be smaller so that
it is less likely to cause paging; this will again improve the server
performance.
Changes to the cache mode only take effect after AR Server has been
restarted.
The expectation is that in a development environment, admin changes have
priority over other users. In a production environment the opposite is
true.
So, the key thing to understand when using this parameter is that we lock
the object when a change is applied (when we issue a Set, Delete, or
Create API call), not when it is opened. This means that any number of
admin tools may have an object open; if one of them changes the object and
a second one makes another change, the first is overwritten. That
behavior is no different than without the change, since there is only one
admin thread and all admin operations are serialized.
This should improve performance immensely when saving a form because you
are only dealing with the current form and not all objects on the server
being cached.
Is there any risk to having Development Cache Mode enabled in production?
Yes. An issue was discovered when development cache mode is enabled that
can cause AR Server to appear hung. This is thoroughly described in
KM-000000025743. This is NOT a common issue. Normally, there would be no
risk other than the described behavior of AR Server when Admin changes
occur.
------ Here's 25743
There is an important side-effect that can cause AR Server to appear hung
and users receive timeout errors, like ARERR 93.
This occurs under specific circumstances, but specifically when the
Development Cache Mode is selected in the Admin Tool under File->Server
Information on the Configuration tab (see KB 24487 for information on
Development Cache Mode).
Here is the specific course of events that leads to the problem:
An escalation starts running and puts a Read Lock on the Server Cache
tables (in memory).
An Admin Operation (like a form or workflow save) starts but cannot put an
Exclusive lock on the cache until the Escalation is done with its lock.
The escalation continues to run.
Users and utilities try to perform ARServer work (APIs). But they need a
read lock on the cache and are forced to wait.
The escalation keeps running.
Users start getting timeouts (ARERR 93, etc.) and the Admin Tool times
out.
The escalation keeps running.
Finally the escalation completes and the Admin Operation can start.
Admin Operation completes and users work can start. Since the users
already timed out, they've likely given up and moved into trouble shooting
mode, unaware of whats happening with AR Server.
Normally, escalations run pretty quick, but in some cases, this isn't
true. For instance, lets say an escalation fires on a form with 200,000
records in it, updating each one. Each record touched causes Filters to
fire which do Push Fields actions to several other forms for example,
resulting in each of the 200,000 records to take roughly 18 seconds to
complete. This escalation would take a very long time to complete and all
the while, AR Server would appear as though its hung because of the
Development Cache mode being enabled. When Development Cache mode is
enabled, it will attempt to put an exclusive lock on the server cache
tables in memory. When disabled, a separate memory footprint is created so
there is no locking conflict with the cache and therefore this problem
would not occur.
This behavior is not considered a bug, but rather a circumstantial issue
caused by the design of the product. Currently there is no workaround to
this issue, but being aware of it means that there are options. For
instance, normally Development Cache Mode is only enabled on a development
server. If this is the case, then usually you can disable escalations or
temporarily disable development cache mode in development (if the
escalation must run for testing, etc.). You could also alter the
escalation(s) so it doesn't touch so many records or doesn't cause filters
to fire, etc. In other words, speed up the escalation processing time so
any locks are very quick, or disable the escalation (or all escalations),
or disable development cache mode.
Tony Worthington | Sr. Technical Analyst | Kohl?s Department Stores
N56 W17000 Ridgewood Drive | Menomonee Falls, WI 53051 | office: (262)
703-7763 | e-mail: tony.worthing...@kohls.com
From:
Misi Mladoniczky <m...@rrr.se>
To:
arslist@ARSLIST.ORG
Date:
11/20/2009 08:49 AM
Subject:
Development Cache Mode revisited
Sent by:
"Action Request System discussion list(ARSList)" <arslist@ARSLIST.ORG>
Hi all,
If you have Development Cache Mode ON for a production environment.
What would be the impact, if:
- No admin-changes were done
- And No changes to Groups of the type View/Change were done
The client runs ARServer 7.1.0 patch 4, ITSM 7.0, Windows and Oracle. it
is a server group with 2 servers.
The reason I ask, is that if they have Cache-Mode turned OFF (0), the
production server seems to time out when they actually do an admin change.
For example enabling an escalation.
They want to do occasional admin-changes during off-hours when activity is
very low.
I tried to catch the actual "recaching" in my AR Server SQL-log, but could
not find any such activity. Maybe it is not logged for some reason???
Best Regards - Misi, RRR AB, http://rrr.se
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
**********************************************************************
CONFIDENTIALITY NOTICE:
This is a transmission from Kohl's Department Stores, Inc.
and may contain information which is confidential and proprietary.
If you are not the addressee, any disclosure, copying or distribution or use of
the contents of this message is expressly prohibited.
If you have received this transmission in error, please destroy it and notify
us immediately at 262-703-7000.
CAUTION:
Internet and e-mail communications are Kohl's property and Kohl's reserves the
right to retrieve and read any message created, sent and received. Kohl's
reserves the right to monitor messages by authorized Kohl's Associates at any
time
without any further consent.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
