Re: Performance Tuning
I would be interested in that as well! Sue From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pruitt, Christopher (Bank of America Account) Sent: Wednesday, March 14, 2012 9:54 AM To: arslist@ARSLIST.ORG Subject: Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. Christopher Pruitt Business Consulting III HP Enterprises Services christopher.pru...@hp.commailto:christopher.pru...@hp.com www.hp.comhttp://www.hp.com/ [cid:image001.jpg@01CD01CA.0DD1D790] Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. _attend WWRUG12 www.wwrug.comhttp://www.wwrug.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 inline: image001.jpg
Re: Performance Tuning
I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! ** ** Sue ** ** *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of America Account) *Sent:* Wednesday, March 14, 2012 9:54 AM *To:* arslist@ARSLIST.ORG *Subject:* Performance Tuning ** ** ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. *Christopher Pruitt* Business Consulting III *HP Enterprises Services **christopher.pru...@hp.com *www.hp.com *Confidentiality Notice:* This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake.* *** _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ -- Patrick Zandi ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Performance Tuning
MPSO!!! You bring back old memories! Joe From: patrick zandi Sent: Wednesday, March 14, 2012 10:13 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pruitt, Christopher (Bank of America Account) Sent: Wednesday, March 14, 2012 9:54 AM To: arslist@ARSLIST.ORG Subject: Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. Christopher Pruitt Business Consulting III HP Enterprises Services christopher.pru...@hp.com www.hp.com Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Performance Tuning
** Me too! From: "Barber, Sue" sbar...@mitre.orgTo: arslist@ARSLIST.ORG Sent: Wednesday, March 14, 2012 9:05 AMSubject: Re: Performance Tuning ** I would be interested in that as well! Sue From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pruitt, Christopher (Bank of America Account)Sent: Wednesday, March 14, 2012 9:54 AMTo: arslist@ARSLIST.ORGSubject: Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. Christopher Pruitt Business Consulting III HP Enterprises Serviceschristopher.pru...@hp.comwww.hp.com Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_
Re: Performance Tuning
Hi, You may find some information here: http://rrr.se/doc/WWRUG09_RRR_LogFilePerformanceTuning.pdf Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. Christopher Pruitt Business Consulting III HP Enterprises Services christopher.pru...@hp.com www.hp.comhttp://www.hp.com/ Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. ___ 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
Re: Performance Tuning
You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe From: patrick zandi Sent: Wednesday, March 14, 2012 10:13 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pruitt, Christopher (Bank of America Account) Sent: Wednesday, March 14, 2012 9:54 AM To: arslist@ARSLIST.ORG Subject: Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. Christopher Pruitt Business Consulting III HP Enterprises Services christopher.pru...@hp.com www.hp.com Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Performance Tuning
These are for 7.6 - I don't know about 7.1 BMC Remedy AR System Server 7.6 Performance Tuning for Business Service Management http://documents.bmc.com/supportu/documents/90/37/199037/199037.pdf The mid-tier deployment guide is from: https://communities.bmc.com/communities/docs/DOC-18162 Regards, Andrew Goodall Software Engineer 2 | Development Services | jcpenney . www.jcp.com http://www.jcp.com/ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pruitt, Christopher (Bank of America Account) Sent: Wednesday, March 14, 2012 8:54 AM To: arslist@ARSLIST.ORG Subject: Performance Tuning Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. Christopher Pruitt Business Consulting III HP Enterprises Services christopher.pru...@hp.com www.hp.com http://www.hp.com/ Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ font face=monospacesize=-3brThe information transmitted is intended only for the person or entity to which it is addressed and brmay contain confidential and/or privileged material. If the reader of this message is not the intendedbrrecipient, you are hereby notified that your access is unauthorized, and any review, dissemination,brdistribution or copying of this message including any attachments is strictly prohibited. If you are notbrthe intended recipient, please contact the sender and delete the material from any computer.br ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are image001.jpg
Re: Performance Tuning
I agree:: Joe.. autorefresh, reconciliation engine, AIE On Wed, Mar 14, 2012 at 10:52 AM, Joe Martin D'Souza jdso...@shyle.netwrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe *From:* patrick zandi remedy...@gmail.com *Sent:* Wednesday, March 14, 2012 10:13 AM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of America Account) *Sent:* Wednesday, March 14, 2012 9:54 AM *To:* arslist@ARSLIST.ORG *Subject:* Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. *Christopher Pruitt* Business Consulting III *HP Enterprises Services **christopher.pru...@hp.com *www.hp.com *Confidentiality Notice:* This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ -- Patrick Zandi ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Performance Tuning
I want to thank all of you who contacted me directly or replied back to the list. I now have all that I need and all of it is very good. Thanks everyone. Christopher Pruitt Business Consulting III HP Enterprises Services christopher.pru...@hp.com www.hp.comhttp://www.hp.com/ [cid:image001.png@01CD01CF.53C9E210] Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of patrick zandi Sent: Wednesday, March 14, 2012 10:32 AM To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** I agree:: Joe.. autorefresh, reconciliation engine, AIE On Wed, Mar 14, 2012 at 10:52 AM, Joe Martin D'Souza jdso...@shyle.netmailto:jdso...@shyle.net wrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I'm guessing this does impact performance too?? I'm sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe From: patrick zandimailto:remedy...@gmail.com Sent: Wednesday, March 14, 2012 10:13 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.orgmailto:sbar...@mitre.org wrote: ** I would be interested in that as well! Sue From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Pruitt, Christopher (Bank of America Account) Sent: Wednesday, March 14, 2012 9:54 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. Christopher Pruitt Business Consulting III HP Enterprises Services christopher.pru...@hp.commailto:christopher.pru...@hp.com www.hp.comhttp://www.hp.com/ Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. _attend WWRUG12 www.wwrug.comhttp://www.wwrug.com ARSlist: Where the Answers Are_ -- Patrick Zandi _attend WWRUG12 www.wwrug.comhttp://www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives
Re: Performance Tuning
Another one.. Disk fragmentation on the database server can often lead to latency I was told way back in the days.. I’m sure that is still applicable.. Solution is to defrag the disk on regular maintenance cycles.. Joe From: patrick zandi Sent: Wednesday, March 14, 2012 11:32 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** I agree:: Joe.. autorefresh, reconciliation engine, AIE On Wed, Mar 14, 2012 at 10:52 AM, Joe Martin D'Souza jdso...@shyle.net wrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe From: patrick zandi Sent: Wednesday, March 14, 2012 10:13 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pruitt, Christopher (Bank of America Account) Sent: Wednesday, March 14, 2012 9:54 AM To: arslist@ARSLIST.ORG Subject: Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. Christopher Pruitt Business Consulting III HP Enterprises Services christopher.pru...@hp.com www.hp.com Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Performance Tuning
limit AIE, put it on its own queue and limit the number of Threads to account for CPU usage.. I put all 32 cpu's at 85% once.. lol On Wed, Mar 14, 2012 at 12:29 PM, Joe Martin D'Souza jdso...@shyle.netwrote: ** Another one.. Disk fragmentation on the database server can often lead to latency I was told way back in the days.. I’m sure that is still applicable.. Solution is to defrag the disk on regular maintenance cycles.. Joe *From:* patrick zandi remedy...@gmail.com *Sent:* Wednesday, March 14, 2012 11:32 AM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** I agree:: Joe.. autorefresh, reconciliation engine, AIE On Wed, Mar 14, 2012 at 10:52 AM, Joe Martin D'Souza jdso...@shyle.netwrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe *From:* patrick zandi remedy...@gmail.com *Sent:* Wednesday, March 14, 2012 10:13 AM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of America Account) *Sent:* Wednesday, March 14, 2012 9:54 AM *To:* arslist@ARSLIST.ORG *Subject:* Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. *Christopher Pruitt* Business Consulting III *HP Enterprises Services **christopher.pru...@hp.com *www.hp.com *Confidentiality Notice:* This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ -- Patrick Zandi ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Performance Tuning
Nice! I’ve done better.. I’ve crashed servers :-) We shouldn’t forget about tweaking the DB. Often many leave the DB at default settings. This in my opinion could never be optimal settings. For e.g. the MS-SQL server had its default packet sizes during the version 6.5 days at 4096 K. I recall even a recent version of MS-SQL (I think 2005) had the same packet size as default. I wouldn’t be surprised if the latest and greatest version has the same size too.. Network speeds have grown 10 times more with better physical network resources. Application sizes have grown significantly too.. Processing powers on CPU’s and server memories have quadrupled over the past 10 years.. I’m not a DBA but I’m certain parameters like packet size, server memory etc. ought to be looked at and tweaked to take advantage of greater available resources. Joe From: patrick zandi Sent: Wednesday, March 14, 2012 12:32 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** limit AIE, put it on its own queue and limit the number of Threads to account for CPU usage.. I put all 32 cpu's at 85% once.. lol On Wed, Mar 14, 2012 at 12:29 PM, Joe Martin D'Souza jdso...@shyle.net wrote: ** Another one.. Disk fragmentation on the database server can often lead to latency I was told way back in the days.. I’m sure that is still applicable.. Solution is to defrag the disk on regular maintenance cycles.. Joe From: patrick zandi Sent: Wednesday, March 14, 2012 11:32 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** I agree:: Joe.. autorefresh, reconciliation engine, AIE On Wed, Mar 14, 2012 at 10:52 AM, Joe Martin D'Souza jdso...@shyle.net wrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe From: patrick zandi Sent: Wednesday, March 14, 2012 10:13 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pruitt, Christopher (Bank of America Account) Sent: Wednesday, March 14, 2012 9:54 AM To: arslist@ARSLIST.ORG Subject: Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. Christopher Pruitt Business Consulting III HP Enterprises Services christopher.pru...@hp.com www.hp.com Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution
Re: Performance Tuning
Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.netwrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe *From:* patrick zandi remedy...@gmail.com *Sent:* Wednesday, March 14, 2012 10:13 AM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of America Account) *Sent:* Wednesday, March 14, 2012 9:54 AM *To:* arslist@ARSLIST.ORG *Subject:* Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. *Christopher Pruitt* Business Consulting III *HP Enterprises Services **christopher.pru...@hp.com *www.hp.com *Confidentiality Notice:* This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. _attend WWRUG12 www.wwrug.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
Re: Performance Tuning
Its not a hard hitter but it accounts for smaller cache sizes by reusing code instead of recreating it everytime its required.. Useful when every run counts.. Wont make a big difference if your application footprint is small. Joe From: Jason Miller Sent: Wednesday, March 14, 2012 4:45 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.net wrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe From: patrick zandi Sent: Wednesday, March 14, 2012 10:13 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pruitt, Christopher (Bank of America Account) Sent: Wednesday, March 14, 2012 9:54 AM To: arslist@ARSLIST.ORG Subject: Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. Christopher Pruitt Business Consulting III HP Enterprises Services christopher.pru...@hp.com www.hp.com Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Performance Tuning
About the recommendation of using AL instead of Filters to increase performance, I know that BMC recommends it, but I think that is a big mistake. In fact it can increase performance, but at the price of degrading the business logic layer. I can explain it with an example: Tell a Java developer to move the business logic code from the server to javascript to free server resources. Just this morning I published a post that contains this point of view, what a coincidence! http://theremedyforit.com/2012/03/bmc-and-dirty-programming/ Jose M. Huerta Project Manager** Movil: 661 665 088 Telf.: 971 75 03 24 Fax: 971 75 07 94 http://www.sm2baleares.es/ SM2 Baleares S.A. C/Rita Levi Edificio SM2 Parc Bit 07121 Palma de Mallorca http://es-es.facebook.com/pages/SM2-Baleares/158608627954 http://twitter.com/#!/SM2Baleares http://www.linkedin.com/company/sm2-baleares La información contenida en este mensaje de correo electrónico es confidencial. La misma, es enviada con la intención de que únicamente sea leída por la persona(s) a la(s) que va dirigida. El acceso a este mensaje por otras personas no está autorizado, por lo que en tal caso, le rogamos que nos lo comunique por la misma vía, se abstenga de realizar copias del mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo de inmediato. P Por favor, no imprima este mensaje ni sus documentos adjuntos si no es necesario. On Wed, Mar 14, 2012 at 21:48, Joe Martin D'Souza jdso...@shyle.net wrote: ** Its not a hard hitter but it accounts for smaller cache sizes by reusing code instead of recreating it everytime its required.. Useful when every run counts.. Wont make a big difference if your application footprint is small. Joe *From:* Jason Miller jason.mil...@gmail.com *Sent:* Wednesday, March 14, 2012 4:45 PM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.netwrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe *From:* patrick zandi remedy...@gmail.com *Sent:* Wednesday, March 14, 2012 10:13 AM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of America Account) *Sent:* Wednesday, March 14, 2012 9:54 AM *To:* arslist@ARSLIST.ORG *Subject:* Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. *Christopher Pruitt* Business Consulting III *HP Enterprises Services **christopher.pru...@hp.com *www.hp.com *Confidentiality Notice:* This message and any files transmitted with it are intended
Re: Performance Tuning
The things that slow down applications the most are the work the database has to do and the chatter on the network. Both of these things can be address 90% through application design. What do I mean by application design? In it's simplest form, I mean the way you store and reference data. There are things that a person can do to make the presentation nice, but you pay a price for those conveniences. In relation to the database, applications that push lots of data around are going to be inherently slower than applications that do not push lots of data around. The easiest way to address this is to store information only once, and read/reference it from that single location. In relation to the network, applications that talk back and forth a lot are going to be inherently slower than applications that perform all their work in a single request/response pair (the ideal scenario). Active links that set fields, table field refreshes, reading menu values, images embedded in your forms, etc. all require a trip to the server and back. Each active link or form objects that performs one of these operations requires a round trip. The more round trips you have the slower things will be. There are limitations to what Remedy can and can not do natively to address these 2 items. Workflow, join forms, etc. can only take you so far, and to remove the hurdles that Remedy can not address natively requires that you work outside Remedy. Some things that commonly come up in this category include: - database tuning (how you store data, how you configure the database, the disk configuration or storage subsystem characteristics) - data access [one trip to do it all] (join forms only give a limited set of capabilities, to extend beyond that you need to look into other things: plugins, database views, etc.) At the end of the day, the decision that has to be made is the trade-off between visual characteristics (capabilities) and performance. Everyone will fall in a different location with respect to these two competing interests. One has to keep in mind that the balance chosen, once implemented, can not be easily changed. This is why it is critically important to define the goals before the design. Those are the things that can have the most drastic impact to the performance of your system, though it is not something that can be addressed with applications that already exist. Axton Grams On Wed, Mar 14, 2012 at 3:48 PM, Joe Martin D'Souza jdso...@shyle.netwrote: ** Its not a hard hitter but it accounts for smaller cache sizes by reusing code instead of recreating it everytime its required.. Useful when every run counts.. Wont make a big difference if your application footprint is small. Joe *From:* Jason Miller jason.mil...@gmail.com *Sent:* Wednesday, March 14, 2012 4:45 PM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.netwrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe *From:* patrick zandi remedy...@gmail.com *Sent:* Wednesday, March 14, 2012 10:13 AM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Pruitt
Re: Performance Tuning
My arserver is never close to 100% utilization; in fact it is rarely above 10% utilization. I don't see that the arserver needs the work to be offloaded. What I do see is that those 60 round trips to the server to load a form increases the page load time by 20 seconds. On Wed, Mar 14, 2012 at 4:37 PM, Jose Huerta jose.hue...@sm2baleares.eswrote: ** About the recommendation of using AL instead of Filters to increase performance, I know that BMC recommends it, but I think that is a big mistake. In fact it can increase performance, but at the price of degrading the business logic layer. I can explain it with an example: Tell a Java developer to move the business logic code from the server to javascript to free server resources. Just this morning I published a post that contains this point of view, what a coincidence! http://theremedyforit.com/2012/03/bmc-and-dirty-programming/ Jose M. Huerta Project Manager** Movil: 661 665 088 Telf.: 971 75 03 24 Fax: 971 75 07 94 http://www.sm2baleares.es/ SM2 Baleares S.A. C/Rita Levi Edificio SM2 Parc Bit 07121 Palma de Mallorca http://es-es.facebook.com/pages/SM2-Baleares/158608627954 http://twitter.com/#!/SM2Baleares http://www.linkedin.com/company/sm2-baleares La información contenida en este mensaje de correo electrónico es confidencial. La misma, es enviada con la intención de que únicamente sea leída por la persona(s) a la(s) que va dirigida. El acceso a este mensaje por otras personas no está autorizado, por lo que en tal caso, le rogamos que nos lo comunique por la misma vía, se abstenga de realizar copias del mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo de inmediato. P Por favor, no imprima este mensaje ni sus documentos adjuntos si no es necesario. On Wed, Mar 14, 2012 at 21:48, Joe Martin D'Souza jdso...@shyle.netwrote: ** Its not a hard hitter but it accounts for smaller cache sizes by reusing code instead of recreating it everytime its required.. Useful when every run counts.. Wont make a big difference if your application footprint is small. Joe *From:* Jason Miller jason.mil...@gmail.com *Sent:* Wednesday, March 14, 2012 4:45 PM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.netwrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe *From:* patrick zandi remedy...@gmail.com *Sent:* Wednesday, March 14, 2012 10:13 AM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of America Account) *Sent:* Wednesday, March 14, 2012 9:54 AM *To:* arslist@ARSLIST.ORG *Subject:* Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities
Re: Performance Tuning
Ah, I am following you now. Instead of having multiple sets of redundant Active Links (say to refresh a set of tables) for different actions, put one set in a guide and then you just need individual ALs to call the guide instead of duplicating the action ALs for different conditions. Basically make subroutines. Jason On Wed, Mar 14, 2012 at 1:48 PM, Joe Martin D'Souza jdso...@shyle.netwrote: ** Its not a hard hitter but it accounts for smaller cache sizes by reusing code instead of recreating it everytime its required.. Useful when every run counts.. Wont make a big difference if your application footprint is small. Joe *From:* Jason Miller jason.mil...@gmail.com *Sent:* Wednesday, March 14, 2012 4:45 PM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.netwrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe *From:* patrick zandi remedy...@gmail.com *Sent:* Wednesday, March 14, 2012 10:13 AM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of America Account) *Sent:* Wednesday, March 14, 2012 9:54 AM *To:* arslist@ARSLIST.ORG *Subject:* Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. *Christopher Pruitt* Business Consulting III *HP Enterprises Services **christopher.pru...@hp.com *www.hp.com *Confidentiality Notice:* This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. _attend WWRUG12 www.wwrug.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
Re: Performance Tuning
I am thinking that the lack of a Run If qualification typical on at least some of the AL/Filters in a Guide might also speed the processing up - one less thing to check. Rick On Wed, Mar 14, 2012 at 7:55 PM, Jason Miller jason.mil...@gmail.comwrote: ** Ah, I am following you now. Instead of having multiple sets of redundant Active Links (say to refresh a set of tables) for different actions, put one set in a guide and then you just need individual ALs to call the guide instead of duplicating the action ALs for different conditions. Basically make subroutines. Jason On Wed, Mar 14, 2012 at 1:48 PM, Joe Martin D'Souza jdso...@shyle.netwrote: ** Its not a hard hitter but it accounts for smaller cache sizes by reusing code instead of recreating it everytime its required.. Useful when every run counts.. Wont make a big difference if your application footprint is small. Joe *From:* Jason Miller jason.mil...@gmail.com *Sent:* Wednesday, March 14, 2012 4:45 PM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.netwrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe *From:* patrick zandi remedy...@gmail.com *Sent:* Wednesday, March 14, 2012 10:13 AM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of America Account) *Sent:* Wednesday, March 14, 2012 9:54 AM *To:* arslist@ARSLIST.ORG *Subject:* Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. *Christopher Pruitt* Business Consulting III *HP Enterprises Services **christopher.pru...@hp.com *www.hp.com *Confidentiality Notice:* This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where
Re: Performance Tuning
As far as the work is concerned, the net cost of the operations is the same, when using an active link guide versus an active link, to perform some set of actions. The difference should be negligible. Now, if you could somehow send one request to the arserver and retrieve the data for all the table fields at once, that would be a different story. It would also be a different story if the javascript used asynchronous calls to refresh the table fields. The active link processing is serial though; this is why the output to the logs is serial and why the request/response pairs are serial. I think it would be a grand change if they could extend the active link processing (and subsequently, the javascript used to emulate the active link processing) to break down the workflow and make a determination on when synchronous/asynchronous calls could be used. I would even take the ability to manually specify which calls are asynchronous and which are synchronous (where the branching in the execution can occur) and define the synchronization points in the workflow. This change would go a long way on the performance of the applications and it would let you have the best of both worlds (visual characteristics and performance). Axton Grams On Wed, Mar 14, 2012 at 6:55 PM, Jason Miller jason.mil...@gmail.comwrote: ** Ah, I am following you now. Instead of having multiple sets of redundant Active Links (say to refresh a set of tables) for different actions, put one set in a guide and then you just need individual ALs to call the guide instead of duplicating the action ALs for different conditions. Basically make subroutines. Jason On Wed, Mar 14, 2012 at 1:48 PM, Joe Martin D'Souza jdso...@shyle.netwrote: ** Its not a hard hitter but it accounts for smaller cache sizes by reusing code instead of recreating it everytime its required.. Useful when every run counts.. Wont make a big difference if your application footprint is small. Joe *From:* Jason Miller jason.mil...@gmail.com *Sent:* Wednesday, March 14, 2012 4:45 PM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.netwrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe *From:* patrick zandi remedy...@gmail.com *Sent:* Wednesday, March 14, 2012 10:13 AM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of America Account) *Sent:* Wednesday, March 14, 2012 9:54 AM *To:* arslist@ARSLIST.ORG *Subject:* Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. *Christopher Pruitt
Re: Performance Tuning
Yes in regular programing sense it’s a sub-routine. Makes the application light weight. Its not the hardest hitter of them all when performance tuning an app, but it does help in the end. It probably accounts to trimming down the size of the app by at least 5% if not more.. Joe From: Jason Miller Sent: Wednesday, March 14, 2012 7:55 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** Ah, I am following you now. Instead of having multiple sets of redundant Active Links (say to refresh a set of tables) for different actions, put one set in a guide and then you just need individual ALs to call the guide instead of duplicating the action ALs for different conditions. Basically make subroutines. Jason On Wed, Mar 14, 2012 at 1:48 PM, Joe Martin D'Souza jdso...@shyle.net wrote: ** Its not a hard hitter but it accounts for smaller cache sizes by reusing code instead of recreating it everytime its required.. Useful when every run counts.. Wont make a big difference if your application footprint is small. Joe From: Jason Miller Sent: Wednesday, March 14, 2012 4:45 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.net wrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe From: patrick zandi Sent: Wednesday, March 14, 2012 10:13 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pruitt, Christopher (Bank of America Account) Sent: Wednesday, March 14, 2012 9:54 AM To: arslist@ARSLIST.ORG Subject: Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. Christopher Pruitt Business Consulting III HP Enterprises Services christopher.pru...@hp.com www.hp.com Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake
Re: Performance Tuning
That’s a very interesting thought.. I bet it does have a positive impact.. I never really gave that a thought but I bet you are right – theoretically at least.. Joe From: Rick Cook Sent: Wednesday, March 14, 2012 8:08 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** I am thinking that the lack of a Run If qualification typical on at least some of the AL/Filters in a Guide might also speed the processing up - one less thing to check. Rick On Wed, Mar 14, 2012 at 7:55 PM, Jason Miller jason.mil...@gmail.com wrote: ** Ah, I am following you now. Instead of having multiple sets of redundant Active Links (say to refresh a set of tables) for different actions, put one set in a guide and then you just need individual ALs to call the guide instead of duplicating the action ALs for different conditions. Basically make subroutines. Jason On Wed, Mar 14, 2012 at 1:48 PM, Joe Martin D'Souza jdso...@shyle.net wrote: ** Its not a hard hitter but it accounts for smaller cache sizes by reusing code instead of recreating it everytime its required.. Useful when every run counts.. Wont make a big difference if your application footprint is small. Joe From: Jason Miller Sent: Wednesday, March 14, 2012 4:45 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.net wrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe From: patrick zandi Sent: Wednesday, March 14, 2012 10:13 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pruitt, Christopher (Bank of America Account) Sent: Wednesday, March 14, 2012 9:54 AM To: arslist@ARSLIST.ORG Subject: Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. Christopher Pruitt Business Consulting III HP Enterprises Services christopher.pru...@hp.com www.hp.com Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have
Re: Performance Tuning
Oh sure it is. Remove the dead wood Sent from my iPhone On Mar 14, 2012, at 20:08, Rick Cook remedyr...@gmail.com wrote: ** I am thinking that the lack of a Run If qualification typical on at least some of the AL/Filters in a Guide might also speed the processing up - one less thing to check. Rick On Wed, Mar 14, 2012 at 7:55 PM, Jason Miller jason.mil...@gmail.com wrote: ** Ah, I am following you now. Instead of having multiple sets of redundant Active Links (say to refresh a set of tables) for different actions, put one set in a guide and then you just need individual ALs to call the guide instead of duplicating the action ALs for different conditions. Basically make subroutines. Jason On Wed, Mar 14, 2012 at 1:48 PM, Joe Martin D'Souza jdso...@shyle.net wrote: ** Its not a hard hitter but it accounts for smaller cache sizes by reusing code instead of recreating it everytime its required.. Useful when every run counts.. Wont make a big difference if your application footprint is small. Joe From: Jason Miller Sent: Wednesday, March 14, 2012 4:45 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.net wrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe From: patrick zandi Sent: Wednesday, March 14, 2012 10:13 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pruitt, Christopher (Bank of America Account) Sent: Wednesday, March 14, 2012 9:54 AM To: arslist@ARSLIST.ORG Subject: Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found them anywhere. Anyone have a like to these guides, I would really appreciate it if you would provide it. Thanks. Christopher Pruitt Business Consulting III HP Enterprises Services christopher.pru...@hp.com www.hp.com Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_
Re: Performance Tuning
If you refresh multiple tables via one active link, it now treats them as one roundtrip between client and server, verified with fiddler. I believe this is 7.6.4 forward, there are good opportunities for some optimization if you see multiple refreshes on unrelated tables (order of refreshes cannot be controlled when this is done) Sent from my BlackBerry device on the Rogers Wireless Network -Original Message- From: Axton axton.gr...@gmail.com Sender: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG Date: Wed, 14 Mar 2012 19:54:23 To: arslist@ARSLIST.ORG Reply-To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning As far as the work is concerned, the net cost of the operations is the same, when using an active link guide versus an active link, to perform some set of actions. The difference should be negligible. Now, if you could somehow send one request to the arserver and retrieve the data for all the table fields at once, that would be a different story. It would also be a different story if the javascript used asynchronous calls to refresh the table fields. The active link processing is serial though; this is why the output to the logs is serial and why the request/response pairs are serial. I think it would be a grand change if they could extend the active link processing (and subsequently, the javascript used to emulate the active link processing) to break down the workflow and make a determination on when synchronous/asynchronous calls could be used. I would even take the ability to manually specify which calls are asynchronous and which are synchronous (where the branching in the execution can occur) and define the synchronization points in the workflow. This change would go a long way on the performance of the applications and it would let you have the best of both worlds (visual characteristics and performance). Axton Grams On Wed, Mar 14, 2012 at 6:55 PM, Jason Miller jason.mil...@gmail.comwrote: ** Ah, I am following you now. Instead of having multiple sets of redundant Active Links (say to refresh a set of tables) for different actions, put one set in a guide and then you just need individual ALs to call the guide instead of duplicating the action ALs for different conditions. Basically make subroutines. Jason On Wed, Mar 14, 2012 at 1:48 PM, Joe Martin D'Souza jdso...@shyle.netwrote: ** Its not a hard hitter but it accounts for smaller cache sizes by reusing code instead of recreating it everytime its required.. Useful when every run counts.. Wont make a big difference if your application footprint is small. Joe *From:* Jason Miller jason.mil...@gmail.com *Sent:* Wednesday, March 14, 2012 4:45 PM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.netwrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe *From:* patrick zandi remedy...@gmail.com *Sent:* Wednesday, March 14, 2012 10:13 AM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of America Account) *Sent:* Wednesday, March 14, 2012 9:54 AM
Re: Performance Tuning
Hopefully these types of things are being considered for a future version that may or may not be a major overhaul to the core ARS code. On Mar 14, 2012 5:54 PM, Axton axton.gr...@gmail.com wrote: ** As far as the work is concerned, the net cost of the operations is the same, when using an active link guide versus an active link, to perform some set of actions. The difference should be negligible. Now, if you could somehow send one request to the arserver and retrieve the data for all the table fields at once, that would be a different story. It would also be a different story if the javascript used asynchronous calls to refresh the table fields. The active link processing is serial though; this is why the output to the logs is serial and why the request/response pairs are serial. I think it would be a grand change if they could extend the active link processing (and subsequently, the javascript used to emulate the active link processing) to break down the workflow and make a determination on when synchronous/asynchronous calls could be used. I would even take the ability to manually specify which calls are asynchronous and which are synchronous (where the branching in the execution can occur) and define the synchronization points in the workflow. This change would go a long way on the performance of the applications and it would let you have the best of both worlds (visual characteristics and performance). Axton Grams On Wed, Mar 14, 2012 at 6:55 PM, Jason Miller jason.mil...@gmail.comwrote: ** Ah, I am following you now. Instead of having multiple sets of redundant Active Links (say to refresh a set of tables) for different actions, put one set in a guide and then you just need individual ALs to call the guide instead of duplicating the action ALs for different conditions. Basically make subroutines. Jason On Wed, Mar 14, 2012 at 1:48 PM, Joe Martin D'Souza jdso...@shyle.netwrote: ** Its not a hard hitter but it accounts for smaller cache sizes by reusing code instead of recreating it everytime its required.. Useful when every run counts.. Wont make a big difference if your application footprint is small. Joe *From:* Jason Miller jason.mil...@gmail.com *Sent:* Wednesday, March 14, 2012 4:45 PM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.netwrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe *From:* patrick zandi remedy...@gmail.com *Sent:* Wednesday, March 14, 2012 10:13 AM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.orgwrote: ** I would be interested in that as well! Sue *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of America Account) *Sent:* Wednesday, March 14, 2012 9:54 AM *To:* arslist@ARSLIST.ORG *Subject:* Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both
Re: Performance Tuning
Doug Mueller gave an excellent response almost two years ago regarding this topic (subject: Logic in active links vs. filters). What he outlines is right in-line with your thoughts. http://old.nabble.com/forum/ViewPost.jtp?post=28271031framed=y Jason On Wed, Mar 14, 2012 at 2:37 PM, Jose Huerta jose.hue...@sm2baleares.eswrote: ** About the recommendation of using AL instead of Filters to increase performance, I know that BMC recommends it, but I think that is a big mistake. In fact it can increase performance, but at the price of degrading the business logic layer. I can explain it with an example: Tell a Java developer to move the business logic code from the server to javascript to free server resources. Just this morning I published a post that contains this point of view, what a coincidence! http://theremedyforit.com/2012/03/bmc-and-dirty-programming/ Jose M. Huerta Project Manager** Movil: 661 665 088 Telf.: 971 75 03 24 Fax: 971 75 07 94 http://www.sm2baleares.es/ SM2 Baleares S.A. C/Rita Levi Edificio SM2 Parc Bit 07121 Palma de Mallorca http://es-es.facebook.com/pages/SM2-Baleares/158608627954 http://twitter.com/#!/SM2Baleares http://www.linkedin.com/company/sm2-baleares La información contenida en este mensaje de correo electrónico es confidencial. La misma, es enviada con la intención de que únicamente sea leída por la persona(s) a la(s) que va dirigida. El acceso a este mensaje por otras personas no está autorizado, por lo que en tal caso, le rogamos que nos lo comunique por la misma vía, se abstenga de realizar copias del mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo de inmediato. P Por favor, no imprima este mensaje ni sus documentos adjuntos si no es necesario. On Wed, Mar 14, 2012 at 21:48, Joe Martin D'Souza jdso...@shyle.netwrote: ** Its not a hard hitter but it accounts for smaller cache sizes by reusing code instead of recreating it everytime its required.. Useful when every run counts.. Wont make a big difference if your application footprint is small. Joe *From:* Jason Miller jason.mil...@gmail.com *Sent:* Wednesday, March 14, 2012 4:45 PM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** Hi Joe, Can you expand on why using an guides (particularly AL) increases performance? Thanks, Jason On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza jdso...@shyle.netwrote: ** You could add a few more to that jar that I can think at the top of my head... #15 Select appropriate Refresh Option for menus depending on their use (On Connect, On Open, 15 Minute Intervals). #16 Use Active Link or Filter Guides where possible. #17 Refresh your table fields only when necessary use appropriate chunks sizes #18 Design Flashboard variables carefully. #19 Use Computed or Dynamic groups where possible... I’m guessing this does impact performance too?? I’m sure there are other performance related AR System related parameters Might be a good idea to compile a good list more relevant to our current versions.. Joe *From:* patrick zandi remedy...@gmail.com *Sent:* Wednesday, March 14, 2012 10:13 AM *Newsgroups:* public.remedy.arsystem.general *To:* arslist@ARSLIST.ORG *Subject:* Re: Performance Tuning ** I am looking at a jar in front of me.. it says the following:: #1 use indexes appropriately #2 use efficient queries #3 consider using set field action in filters instead of AL #4 avoid using filters which perform run process to run a macros (old) ##5 stagger escalations times #6 use direct sql, $PROCESS$ sparingly #7 avoid sending notifications to too many addresses (hah!) #8 minimize the number of diary, and long charcter fields #9 avoid admin tool / migrator during peak hours. #10 keep your application design simple #11 implement MPSO (hah!) #12 Define carefully the number of fast and list servers. #13 allocate enough shared memory for the db. #14 provide adequate computer network resources. Most still apply ! On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue sbar...@mitre.org wrote: ** I would be interested in that as well! Sue *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of America Account) *Sent:* Wednesday, March 14, 2012 9:54 AM *To:* arslist@ARSLIST.ORG *Subject:* Performance Tuning ** Does anyone know where I can find a Performance Tuning guide or white paper for the following AR System Server versions? 7.1 and 7.6.04. I have gone through the Optimizing and Troubleshooting Guide for both versions but I thought there was a more detailed Performance Tuning guide out there somewhere. I have gone through BMCs documentation for both versions and have search the BMC Communities and have not found
Re: Performance Tuning
BMC White Paper 85503 Performance Tuning for Business Service Management is a good starting point. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Performance Tuning ARS 7.1
Tempdb is a ala temporary tablespace in sql server. AR installer does not create this. When SQL Server is installed the setup program creates tempdb database. Tempdb is a system database used by SQL Server to store temporary tables and temporary stored procedures, for sorting, subqueries, and aggregates with GROUP BY, ORDER BY, for cursors and so on. Tempdb database contains only temporary objects, so if you want to create a permanent object, do not create it in the tempdb database. Regards, Abhijeet From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Robert Molenda Sent: Saturday, May 23, 2009 6:47 PM To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ARS 7.1 ** We have been experiancing random ARERR 92 / 8939's at several custom locations - generally a restart of ARS clears the issue - this is occuring on multiple 7.1 patch versoins. Since this is the 'tempdb' and not ARSystem - I am curious as to what ARS would be doing in the tempdb - guess I need to enable profiler and check the activity... One question - is what is the transaction logsize of tempdb? is it attempting to grow (and grow)?? I will pass this 'tip' on to my team(s) for them to try at a few customer locations just to double check... Robert Molenda On Thu, May 21, 2009 at 11:43 AM, Leonard Nelson leo.nel...@gmail.commailto:leo.nel...@gmail.com wrote: Hello All We just launched ARS 7.1 two weeks ago. Things have been running fairly well until last week when we started to see the error ARERR 92 Timeout during database update -- the operation has been accepted by the server and will usually complete successfully : server.comhttp://server.com/ With BMC guidance we increased the tempdb size from an initial 8MB to 1GB. The ARERR 92 error appeared to be resolved until earlier this week when we started seeing error ARERR 382 The value(s) for this entry violate a unique index that has been defined for this form : HPD:Help Desk entry:INC8832 fields: and error ARERR 8939 The AR System Plug-In server is not responding. Cannot connect to the system at this time. Contact your AR System Administrator for assistance. : RPC: Timed out I suspect that ARERR 92 and ARERR 382 are related, so earlier this morning I increased the tempdb size from 1GB to 5GB. This appears to have resolved these errors. However, I'm not sure if ARERR 8939 is related to this issue but restarting the arplugin.exe process appears to have resolved this issue. Our AR server is running on a Windows 2003 server R2 with 8GB RAM and the database backed is SQL 2005 running on a similar server. I'm curious if anyone else has encountered similar issues and what recommendations people have for improving performance of a system. Clearly, we are learning some new ways of tuning our system, so any tips would be greatly appreciated. Leo ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.orghttp://www.arslist.org/ Platinum Sponsor:rmisoluti...@verizon.netmailto:sponsor%3armisoluti...@verizon.net ARSlist: Where the Answers Are -- If it were not for the gutter, my mind would be homeless! _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance Tuning ARS 7.1
You know...I had all of these same problems - but on Solaris with a remote Oracle database. While I doubt you are having the same problem (CLOB's needed to be changed to in-row storage) the real clue was seeing large gaps in the log files where absolutely nothing happened. On the other hand, we also had a bunch of problems with the Java plug-in server running and generally messing stuff up. The Java plug-in server is not needed in 7.1 (unless you are using the SLM Data Collector or some custom stuff) - you may want to comment it out of the armonitor.cfg file. Beyond that - we still get occasional 91/92 errors, and they are usually network related. William Rentfrow Principal Consultant, StrataCom Inc. wrentf...@stratacominc.com O 715-592-5185 C 715-410-8056 From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Gadgil, Abhijeet Sent: Monday, May 25, 2009 1:01 PM To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ARS 7.1 ** Tempdb is a ala temporary tablespace in sql server. AR installer does not create this. When SQL Server is installed the setup program creates tempdb database. Tempdb is a system database used by SQL Server to store temporary tables and temporary stored procedures, for sorting, subqueries, and aggregates with GROUP BY, ORDER BY, for cursors and so on. Tempdb database contains only temporary objects, so if you want to create a permanent object, do not create it in the tempdb database. Regards, Abhijeet From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Robert Molenda Sent: Saturday, May 23, 2009 6:47 PM To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning ARS 7.1 ** We have been experiancing random ARERR 92 / 8939's at several custom locations - generally a restart of ARS clears the issue - this is occuring on multiple 7.1 patch versoins. Since this is the 'tempdb' and not ARSystem - I am curious as to what ARS would be doing in the tempdb - guess I need to enable profiler and check the activity... One question - is what is the transaction logsize of tempdb? is it attempting to grow (and grow)?? I will pass this 'tip' on to my team(s) for them to try at a few customer locations just to double check... Robert Molenda On Thu, May 21, 2009 at 11:43 AM, Leonard Nelson leo.nel...@gmail.com wrote: Hello All We just launched ARS 7.1 two weeks ago. Things have been running fairly well until last week when we started to see the error ARERR 92 Timeout during database update -- the operation has been accepted by the server and will usually complete successfully : server.com http://server.com/ With BMC guidance we increased the tempdb size from an initial 8MB to 1GB. The ARERR 92 error appeared to be resolved until earlier this week when we started seeing error ARERR 382 The value(s) for this entry violate a unique index that has been defined for this form : HPD:Help Desk entry:INC8832 fields: and error ARERR 8939 The AR System Plug-In server is not responding. Cannot connect to the system at this time. Contact your AR System Administrator for assistance. : RPC: Timed out I suspect that ARERR 92 and ARERR 382 are related, so earlier this morning I increased the tempdb size from 1GB to 5GB. This appears to have resolved these errors. However, I'm not sure if ARERR 8939 is related to this issue but restarting the arplugin.exe process appears to have resolved this issue. Our AR server is running on a Windows 2003 server R2 with 8GB RAM and the database backed is SQL 2005 running on a similar server. I'm curious if anyone else has encountered similar issues and what recommendations people have for improving performance of a system. Clearly, we are learning some new ways of tuning our system, so any tips would be greatly appreciated. Leo ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org http://www.arslist.org/ Platinum Sponsor:rmisoluti...@verizon.net mailto:sponsor%3armisoluti...@verizon.net ARSlist: Where the Answers Are -- If it were not for the gutter, my mind would be homeless! _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Performance Tuning ARS 7.1
We have been experiancing random ARERR 92 / 8939's at several custom locations - generally a restart of ARS clears the issue - this is occuring on multiple 7.1 patch versoins. Since this is the 'tempdb' and not ARSystem - I am curious as to what ARS would be doing in the tempdb - guess I need to enable profiler and check the activity... One question - is what is the transaction logsize of tempdb? is it attempting to grow (and grow)?? I will pass this 'tip' on to my team(s) for them to try at a few customer locations just to double check... Robert Molenda On Thu, May 21, 2009 at 11:43 AM, Leonard Nelson leo.nel...@gmail.comwrote: Hello All We just launched ARS 7.1 two weeks ago. Things have been running fairly well until last week when we started to see the error ARERR 92 Timeout during database update -- the operation has been accepted by the server and will usually complete successfully : server.com With BMC guidance we increased the tempdb size from an initial 8MB to 1GB. The ARERR 92 error appeared to be resolved until earlier this week when we started seeing error ARERR 382 The value(s) for this entry violate a unique index that has been defined for this form : HPD:Help Desk entry:INC8832 fields: and error ARERR 8939 The AR System Plug-In server is not responding. Cannot connect to the system at this time. Contact your AR System Administrator for assistance. : RPC: Timed out I suspect that ARERR 92 and ARERR 382 are related, so earlier this morning I increased the tempdb size from 1GB to 5GB. This appears to have resolved these errors. However, I'm not sure if ARERR 8939 is related to this issue but restarting the arplugin.exe process appears to have resolved this issue. Our AR server is running on a Windows 2003 server R2 with 8GB RAM and the database backed is SQL 2005 running on a similar server. I'm curious if anyone else has encountered similar issues and what recommendations people have for improving performance of a system. Clearly, we are learning some new ways of tuning our system, so any tips would be greatly appreciated. Leo ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.netsponsor%3armisoluti...@verizon.netARSlist: Where the Answers Are -- If it were not for the gutter, my mind would be homeless! ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
