Comments inline... > -----Original Message----- > From: thin-bounce@xxxxxxxxxxxxx > [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Shonk, Joe - Perot > Sent: 07 May 2004 19:09 > To: thin@xxxxxxxxxxxxx > Subject: [THIN] Re: Application Availability > > >> Healthcare apps are very flaky. If an application > >> takes down a server, only that application is down. > > >Do you / anybody actually run apps that can take down servers, these > >days? > > It still happens... Many of these systems are still 16 bit. I have to say it shouldn't happen - driver code is one thing, but applications shouldn't crash the OS. > >> There are many hospitals > >> Application loads. Single applications can have > >> 200-300 concurrent users a piece. > > >And it's extremely unlikely you'll get a single TS / Citrix > server to > >run that 200-300 concurrent users. > > No, they are not on a single server... That's the point, > there are 7-10 servers allocated for one application set. > There is no point in bogging them down further with > additional applications. Hang on a minute - then what are we arguing about? The only reason I was making these points was regarding running an application, or set of applications on merely one server, in response to this that you wrote???? :- "If the application set is isolated on it's own server then a scheduled logoff ica-tcp is all that is needed." See the phrase "own server" - note the singular. > >But the flipside of it being that if an app is just > published / present > >on one server, and that server goes down, no app. > > That is why an application is installed on several servers > and load-balanced. I stated that there is nothing wrong with > a server hosting a single application, but I never said > anything about only a single server. Um, yes you did - which is the only reason I made the points I did - see above! > >> Application maintenance. Different application sets > >> have different maintenance schedules. > > >Agreed - I'm not against partitioning farms with applications (or > >application sets) in mind - merely that just having one > server for an > >app certainly restricts your options, and resiliency. > > How so? Applications sets are across multiple servers. That's not what you said, though. You may have meant it, but it's not what you said - and that's the only reason. I think we are in aggreement, actually. It doesn't make sense to simply run an application on one server, but it can make sense to run a singular application across more than one server. The latter, doesn't say anything logically about the former. > >> Taking one application > >> offline and booting off the users should not affect access to > >> other applications. (Remember this is a 24/7 shop) > > >That's no reason to just publish it (or have it present) on > one server, > >though - in fact it gives you a compelling argument to *not* just > >publish (/ install) it on one server. > > Again, the applications sets are redundant across multiple > servers. Again single application, not single server. Good. Neil *********************************************** This e-mail and its attachments are confidential and are intended for the above named recipient only. If this has come to you in error, please notify the sender immediately and delete this e-mail from your system. You must take no action based on this, nor must you copy or disclose it or any part of its contents to any person or organisation. Statements and opinions contained in this email may not necessarily represent those of Littlewoods. Please note that e-mail communications may be monitored. The registered office of Littlewoods Limited and its subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB. Registered number of Littlewoods Limited is 262152. ************************************************ ******************************************************** This Week's Sponsor - RTO Software / TScale What's keeping you from getting more from your terminal servers? Did you know, in most cases, CPU Utilization IS NOT the single biggest constraint to scaling up?! Get this free white paper to understand the real constraints & how to overcome them. SAVE MONEY by scaling-up rather than buying more servers. http://www.rtosoft.com/Enter.asp?ID=147 ********************************************************** Useful Thin Client Computing Links are available at: http://thin.net/links.cfm *********************************************************** For Archives, to Unsubscribe, Subscribe or set Digest or Vacation mode use the below link: http://thin.net/citrixlist.cfm