So for a DDSO all your customers are down. till it is resolved, hours later? Geographically separated servers give you Continued functionality during a crisis.
On Thu, Mar 17, 2011 at 9:08 AM, Terje Moglestue <[email protected]>wrote: > Well, > > I am not using DSO. I have had great success with geographically separated > mid tier servers. Our users in Japan find the application on average 3 > seconds faster for every operation accessing a local web server then > accessing a web server in UK. The AR Server located in UK. > > I am now looking into the possibility to improve the overall network > performance between AR Server and every local mid-tier server. By giving the > network traffic between the serves higher priorities - I hope to improve the > overall performance. You can control server-to-server traffic - you have no > or limited control over end users accessing the mid-tier. > > With world-wide support centers - using the same AR installation, the plan > is to have local web serves/mid-tier servers to improve end-to-end > performance. > > Am I missing out of anything here? > > ARS 75p7, ITSM 75p1, mid-tier servers 7.6.4. Platform Windows Server 2008 > 64 bits. > > ~ > Terje > > > ________________________________ > > From: Action Request System discussion list(ARSList) on behalf of patrick > zandi > Sent: Wed 16/03/2011 04:52 PM > To: [email protected] > Subject: Re: ITSM 7.6.4 > > > ** Geographically separated mid-tiers is not recommended. > making servers geographically separated (using DSO) and mid-tiers with them > is. > The network traffic between a mid-tier and the ARS server should be > protected, at a high level of encryption, and to further put it > geographically separated over a wan is a performance killer. > > IMHO > > Put the mid-tier and the Server on the same Physical Switch (reducing time) > use a group of mid-tier's (they are just clients) load balanced to increase > speed. > Use the pre-load to increase speed, Tune the oracle tables associated with > the common IO calls people are having. > The top 10 > user indexes appropriately > use efficient queries > consider using set fields actions in filters instead of active links > avoid using filters which perform run process > stagger escalations times > use direct sql, $PROCESS$, sparingly > avoid sending notifications to many addressees > minimize the number of diary and long character Fields > avoid admin tool def changes during peak hours > keep you application design simple > implement DSO > allocate enough shared memory in the tomcat and server > provide adequate computer and network resource. > > > > On Wed, Mar 16, 2011 at 12:26 PM, Roger Justice <[email protected]> wrote: > > > ** The first way to imporve WEB client performance is to locate the > Mid_Tier servers closer to you users. > > > > > -----Original Message----- > From: Gard, Richard J <[email protected]> > To: arslist <[email protected]> > Sent: Wed, Mar 16, 2011 12:23 pm > Subject: Re: ITSM 7.6.4 > > > David, > > We are planning for our next global deployment of ITSM (7.6.03/4). > The new > solution will hopefully address considerable performance issues > experienced by > remote users of our current 7.1 deployment. The current deployment > is located > on the eastern seaboard where a large portion of my customer base is > located. > However, my clients in Asia Pacific (fastest growing) and Europe > have complained > about slow performance. What is the recommended implementation of > ITSM 7.6.03/4 > that will present the best response times for all users of the > system? We have > considered placing mid tier and app servers in the remote regions, > but I don't > have data to support this design. The reference architecture > document > ( > http://documents.bmc.com/supportu/documents/49/03/114903/114903.pdf) does > not > speak to this design challenge directly. Suggestions greatly > appreciated. > > Best regards, > Rich > ? > ? > ? > ? > GIS-ISS-SEM > Service Technology Development Manager > ITIL Practisioner Certified: Support and Restore > -----Original Message----- > From: Action Request System discussion list(ARSList) [ <mailto: > ars_attend%20WWRUG11%20www.wwrug.com%20ARSlist:> > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > -- Patrick Zandi _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
