I agree; normally you don't flush or pre-load unless you migrate a change, or apply a service pack, and then you should always do it during scheduled maintenance.
Instead of flushing the cache after installing 7.6.04 SP3 I chose to set pre-load on, and restart the tomcat instances after the application of SP3 to ARS. Two of the three mid-tiers had already been updated to SP3. I did this on all three mid-tiers, and two on over-speced hardware (the ARS/ITSM server with admin mid-tier, and web server with primary mid-tier and Kinetic) pre-loaded in about 15 minutes. The backup mid-tier on the same hardware I used for 7.1 took three times longer. In each case, the first user (me) saw slightly slower form dislays (3 - 8 seconds) whereas in my experience they are much slower initially after a flush cache operation. After the initial pre-load, I turned that setting back OFF on each mid-tier, and saw normal form performance (1-5 seconds). The \cache folders contain between 850 mb and 1.08 gb of files. Our experience with flush cache on SP1 was that the mid-tiers became unstable as they threw cached usernames at the AR Server (without passwords), which were then thrown at the AREA plugin, which frequently crashed and wiped out external authentication until the plugin server was restarted several times. This process always killed threads on the AR Server, which disrupted communications between the mid-tier and AR Server, blowing out user sessions and delaying the start of new ones while it was going on. Definitely NOT something you want to see during production hours. The SP3 mid-tier appears to still throw the same crap at the AR Server on a pre-fetch, flush/pre-fetch, or pre-load, but they must have hardened the Sp3 AR Server and AREA to better handle it. When the mid-tiers were SP3 but the AR Server was Sp1, these problems were still very evident. Time will tell if they have been solved; the SP3 installation has not been completely restarted yet, and won't be until Mickey's monthly updates roll around. On the question of what can be safely updated during production, my experience is that you can get away with updating something that runs exclusively on the server (filters; escalations are more dangerous), but anything that operates in the client is saved for the maintenance window or at least after normal work hours. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Goodall, Andrew C Sent: Monday, March 26, 2012 3:24 PM To: [email protected] Subject: Re: Effects of flushing midtier cache If you have the full ITSM suite, then in my experience it takes about 1 hour to completely recache (just over 1 GB of cache) and for CPU consumption to fall back within normal range. That is not a "brief" disruption :) Regards, Andrew Goodall Software Engineer 2 | Development Services | jcpenney . www.jcp.com -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Joe Martin D'Souza Sent: Monday, March 26, 2012 3:19 PM To: [email protected] Subject: Re: Effects of flushing midtier cache When would you need to flush cache? The obvious answer is when there is a workflow change on production.. Changes to workflow are done whenever there is need for code change for enhancement or bug fixes.. The general industry practice is to manage these changes in a change window, where there is a scheduled outage, which is typically scheduled on weekends or the least productive hours of an organization. So cache should be flushed during these changes. That being said, there may be emergency changes that were a result of a part or whole system being rendered unusable pending that change. On such an event it would be ok to flush your cache after fixing whatever the problem/bug/enhancement was. Yes flushing cache during production hours may cause a brief negative impact on users using the system at the time of the change. Joe -----Original Message----- From: David Durling Sent: Monday, March 26, 2012 3:48 PM Newsgroups: public.remedy.arsystem.general To: [email protected] Subject: Effects of flushing midtier cache Hi, I'm one of those that has found it necessary to use the "flush cache" button in the mid tier config when sometimes certain changes aren't picked up at the regular cache check interval. Do you all consider a flush of the mid tier cache to be unintrusive - something that can be done during production hours? Or is it something that should be done off-hours? On our server I don't notice performance issues in using it, and in what little testing I've done, user sessions seem to be uninterrupted. (I'm not sure about floating users on the web, though - if there's anything to consider there.) I'm on ARS 7.5 patch 007 with mid tier 7.5 patch 007 with apache/tomcat. Thanks, David --- David Durling [email protected] Enterprise IT Services University of Georgia ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient, you are hereby notified that your access is unauthorized, and any review, dissemination, distribution or copying of this message including any attachments is strictly prohibited. If you are not the intended recipient, please contact the sender and delete the material from any computer. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
