Very good point Axton. I've just never had the luxury of a server big enough to scale our system. It is too expensive. With that limitation, and a good gigabit network already in place, separate servers was the best choice for us.
Chad Hall (501) 342-2650 ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Tuesday, January 15, 2008 9:37 AM To: arslist@ARSLIST.ORG Subject: Re: Server Configuration Recommendations ** On Jan 15, 2008 10:22 AM, Kaiser Norm E CIV USAF 96 CS/SCCE <[EMAIL PROTECTED]> wrote: I personally tend to disagree with the notion of putting the DB on its own server. I prefer to put ARS and the DB on the same server and Midtier on its own to cut down on the database accesses and updates from having to be accomplished over the network. Local sockets will always be faster than IP sockets. We have over 2,000 concurrent users, and our performance is outstanding. Considering your performance is slowing with a modest increase in the number of users, I would suspect a memory leak of some sort. Have you looked at RAM consumption in task manager? -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Craig Carter Sent: Tuesday, January 15, 2008 9:13 AM To: arslist@ARSLIST.ORG Subject: Re: Server Configuration Recommendations ** Thanks Chad-that is my impression as well. There should be no reason we should be having these performance problems based on the server we just set up. We generate a lot of emails each day and have over 500K tickets but something else is obviously wrong. Craig Carter ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Hall Chad - chahal Sent: Tuesday, January 15, 2008 7:58 AM To: arslist@ARSLIST.ORG Subject: Re: Server Configuration Recommendations We've ran over 600 concurrent users on a 2x1.4 GHz with 1 GB of memory without any issues. And that's a system with millions of tickets and over 50,000 emails sent each day on only 20 fast, 20 list, plus some private threads. We have two of these so one doesn't normally carry that load, but it has at times. So I don't think it's the size of your server. Ordinarily I would suggest you split the database out onto its own server. But given how big your current hardware is, and how small your current user base is, I see no need for that just yet. You seem to have plenty of hardware for that size of a system. I would use something like BMC Log Analyzer to analyze your API and SQL logs from a slowdown. That will tell you if you've got long running SQL or API calls, if you have little or no idle time on some threads (queuing), etc. It's available on the BMCDN last time I checked. I believe Misi has a log analysis tool as well at www.rrr.se < http://www.rrr.se/ <http://www.rrr.se/> > , but I haven't used it myself. If you see that your API calls are big, and your SQL calls are big, you've got a problem with your database. In that case, look at database metrics or hardware metrics to see if you have disk contention problems. Once we tuned our AR Server almost all of our bottlenecks were in the database, and mainly with disk contention. Chad Hall (501) 342-2650 ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Craig Carter Sent: Tuesday, January 15, 2008 8:41 AM To: arslist@ARSLIST.ORG Subject: Q: Server Configuration Recommendations All, We're running into some performance problems recently. I upgraded the server a few days ago (operating system, database, CPUs, memory, queues, etc, and it hasn't helped much. Basically, it takes longer to search and create tickets as more and more people log in (as expected) but the server has plenty of available CPU, plenty of memory, and plenty of bandwidth so it appears there is a bottleneck somewhere. 8 CPUs 16GB Memory Windows Server 2003 Enterprise SQL Server 2005 Enterprise ARS v7.0.1 P5 (CSS and custom apps-no ITSM) 24 Fast, 40 List It flies with about 40 people, becomes sluggish with 80, and gets real slow with 100. I would expect this system to be able to handle a much larger load. Since the running CPU usage and disk usage is fairly low, I'm looking for advice. Everything is currently installed on the same server and on the same drive (although these are raid drives). Is it possible we're seeing contention over disk resources and I/O? Any advice on determining where the bottleneck is or from people administering a large number of users? How much advantage would be gained by running the AR Server on another drive or box separate from the database? Is it reasonable to expect to only get 100 concurrent users (using the WUT) on a server of this size? Looking in the docs and whitepapers but any advice would be helpful since this is impacting us now. Craig Carter __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __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" __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ************************************************************************* The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you. ************************************************************************* _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
