Thanks everyone for the feedback. Really helped. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Abhijit Hendre Sent: Friday, July 01, 2016 8:29 PM To: [email protected] Subject: Re: Remedy Scalability
** One important thing to consider over here is separation of admin operations from user operations. We know admin operations cause load on server so it's advisable to separate user facing node(s) from admin node so that end users would get flawless experience. If user ops and admin ops hosted on same server then end user experience wrt system responsiveness would be different at different point of time depending on if admin ops running/not running on that server at particular point of time. This will also help to achieve HA. Thanks, Abhijit H On 02-Jul-2016 1:10 am, "Joe D'Souza" <[email protected]<mailto:[email protected]>> wrote: ** I recall once someone here once shared a utility created using HTML, where you could flush cache of as many mid-tier servers as needed, by editing the HTML file accordingly. Thus you would just need to open that file up using IE or any other browser, and click one button that flushes the cache instead of having to logi in. navigate to the cache management and then flush. You could revise the script to include all the servers you wanted to flush the cache on so that one single press could do them all. I have used it a long time ago when working with 20+ servers successfully. Joe ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Pierson, Shawn Sent: Thursday, June 30, 2016 12:03 PM To: [email protected]<mailto:[email protected]> Subject: Re: Remedy Scalability I don’t think there are hard and fast rules about it, because there are so many variations of CPUs, whether VMs or physical servers are involved, how you do reporting, etc. I’ve been in environments with huge server groups and mid tier servers…I have nightmares of going in and refreshing the mid tier cache on about 25 different servers every time we changed a form or active link (I forget why we had to do this actually, when at worst we could have written a script to restart the processes.) In my current production environment we have three app servers, two mid tier servers, one of each for DR (which aren’t in the server group but I’m thinking about adding them just to make DR easier once I get past SQL 2014 failover issues with Remedy) and then my Smart IT/My IT infrastructure. That being said, we designed it to be something that provides a lot of room to grow, we’ve only got a few hundred people in the system at the same time at the moment. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Sinclair, Keith Sent: Thursday, June 30, 2016 10:05 AM To: [email protected]<mailto:[email protected]> Subject: Remedy Scalability ** Hi, I need some technical expertise with Remedy’s infrastructure and scalability. We’re using Linux and ARS 8.1 with Oracle 11 running on AWS servers. How scalable can Remedy truly be? Is it only limited by memory and CPU? Or are there choke points where a second or third server needs to be added to a server group? Is there a maximum number of users that can be on a given system at any one time? Thanks! Keith Sinclair Remedy Development ShopperTrak Chicago, USA O 312.676.8289<tel:312.676.8289> [email protected]<mailto:[email protected]> | shoppertrak.com<http://shoppertrak.com> Retail Profitability, Improved. _ARSlist: "Where the Answers Are" and have been for 20 years_ Private and confidential as detailed here<http://www.energytransfer.com/mail_disclaimer.aspx>. If you cannot access hyperlink, please e-mail sender. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
