well all this information is really great but I do not think it really helps me. We have a lot of users and employees as well but we also have very powerful servers.
Kevin Begosh, RSP External Initiatives System Design & Integration 301-791-3540 Phone 410-422-3623 Cell [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McClure, Don Sent: Thursday, August 28, 2008 11:07 AM To: [email protected] Subject: Re: Issue with some Users ** Hi Kevin....we are on ARS 7.1 patch 2, ITSM patch 7, Windows 2003 server and MSSQL 2005. We have 310 support staff in 222 support groups; 111 groups are company-bounded, and the other are 'reflections' of those groups with visibility to all support staff. Further: our User table is ca 150K users, and these are updated hourly during business hours via backend process. Updates of up to 300 records at a time takes a few seconds for the server, and a minor blip for the database (different hardware platform from ARServer, another Win2003 multi-core, 64-bit). We see few issues from user updates-and fewer yet from people updates. I have provoked several issues when updating foundation data (creating new support groups), and have moved those activities to off-hours since a re-caching generally ensues such changes. May I propose three items for investigation: - Thread allocation. Dr. Chris Strauss is the database admin-and he provisioned many more threads than default out-of-box; performance tuning info of this order has been covered in session during last several UserWorld events; - Database tuning. the MSSQL installations here have been rock-solid, and maintenance free; but Oracle installations often take more 'tuning' for best performance. - Memory in your platforms themselves: both our AR Server and SQL server are over 10Gig RAM each, separate physical platforms. We knew data situations would be intensive.... I strongly suspect that substantial foundation data is cached into RAM for faster access-again, I have never seen a formal list, but I would suspect the following data items: - loginIDs---probably as primary link for all the following - passwords - group memberships - application permissions - notification data Therefore, a change to any of these entities will probably set a 'dirty' flag, and force a re-caching. The only change which has forced slowdowns for us is creation of a new support group; association or de-association of users vs groups has not been a performance block. HTH-this is not necessarily intended as definitive or final.... Don W. McClure, P.E. Data Administrator & System Engineer Computing & IT Center, Call Tracking Administration University of North Texas, Denton dwmac_at_unt.edu "That which counts cannot necessarily be counted: that which can be counted will not always count." -- Albert Einstein From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Begosh, Kevin Sent: Thursday, August 28, 2008 8:44 AM To: [email protected] Subject: Issue with some Users ** We are on AR Server 7.1 patch4 and ITSM 7.03 patch 6, with UNIX Server and Oracle DB. We have about 100 employees who are in about 100 different support groups, and whenever we try to modify their record on the User form it locks up the user tool or takes a really long time to do what they where trying to do. Has anyone experienced this or does anyone have any systems that have employees in a lot of different support groups? Kevin Begosh, RSP 301-791-3540 Phone 410-422-3623 Cell __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
