Eclipse-fm® Deployment – a White Paper
Also available in printer friendly form as a PDF file here
Eclipse-fm® is a data intensive Windows application the deployment of which needs careful consideration as to the environment in which it is to operate.
What we recommend - ideally
- Your own server, set up to meet the needs of running Eclipse-fm® for your circumstances*.
- Located and managed so that you can defend it from ill considered extra workloads or tweaking.
- Running
- Your own MS SQL Server database.
- Application instances via Microsoft Terminal Services, Remote Application Services or Citrix.
- Powerful enough (enough processors, enough memory, enough disk space) to run your desired application user count, Web module and MS SQL Server database.
If you have too many users to fit database and application serving into one server (memory and CPU performance limits), then a second (preferably closely coupled) database server is inevitable, or consider using the main IT database provisions but only if adequate network capacity is available over a high speed network connections, and the main IT MS SQL Server has sufficient spare capacity.
A specification based on the above principles, especially those related to using Terminal Services, Remote Application Services or Citrix should accommodate any users, connected by even the slowest of network connections.
Where the database is separated from where the application runs, then you need to consider network traffic over the network segments involved. As one example, hospital networks come under considerable load when X-Ray image data is being transmitted between departments, and this can have a significant affect on the perceived performance of a database application.
*We will recommend detailed hardware specifications in the light of your circumstances.
Hosted for you
If you do not have the expertise to manage such, consider hosting. This kind of set up is insensitive to geographical distance, and we can provide the expertise to commission and maintain the server(s), database and applications.
What you should avoid
- The earlier generation shared file database
- Local end user PC deployment of the application.
- Long distance, and/or non dedicated connection between application instances and database in conjunction with either of these.
- Application Evolution
- Network Evolution
- Detailed considerations and tips as to network and deployment architecture
- How to make best use of today’s powerful application servers
- Using the main IT MS SQL Server installation
Application Evolution
Ten years ago, the typical Facilities Management System in use in the NHS was a character mode system, with limited user friendly characteristics such as look up lists, or grid style entry. It found a data record, or at most a small number of related records, then processed and saved that same limited number of records in response to user input. Bulk record processing was handled off-line (end of month routines), and was expected to take a while.
Today, applications are typically Windows based, record finding is augmented by helpful selection lists, and on-screen data entry is often based on a grid (table) based user interface populated with many records and dynamically refreshed as the user navigates the rows. Instead of finding a handful of records, hundreds of records may be fetched for display. On saving records, much more on-line processing takes place, providing up to date management information instead of waiting for a month-end updating batch process. If it is a web based application, or has a web module, similar levels of interactivity may be present, and with current trends in Web application development then such interactivity is going to become more commonplace.
This evolution has lead to a considerable increase in the data traffic needed to service data entry in a modern Windows application compared with its character mode equivalent.
This trend is partially countered by the move from shared file databases to true server databases, which removes some of the extra network load in fetching each record – but not necessarily making up for all the extra data records fetched out of the database.
Network Evolution
Ten years ago, the typical FM department usually had its own server, holding its own FM application data. If it was connected to the main hospital network, it would be via a router and this ensured that only necessary data traffic passed across the router in either direction. The file server was very often Novell, a very efficient file server, or the whole system was Unix based, removing the network traffic considerations.
Today, the network server will usually be a Windows server, and it may no longer be located within the FM department but in the hospital IT Centre. Without a dedicated link to the server the FM application data will be competing for bandwidth with the whole of the hopsital’s network traffic. The use of a server database will make up for the slower Windows server file serving performance but this may be negated by the temptation to run other applications on the server.
We also see more instances of remote sites. These may be real “remote” FM department sites, some miles distant, but in network terms we may even see the main FM department as “remote” from its server, defined as where the network link is across a slow, 1-2 megabit, leased line connection.
The Result
A big increase in network traffic requirements in orders to meet modern expectations of usability, a big decrease in the effective bandwidth available to the application, and if the shared file database is persisted with, a less efficient file server.
Back to Contents
Deploying for Performance
Localisation
Ideally, keep the application, its data, and the users all within a local sub-network within the FM department. Use a router to ensure that the department traffic is not exposed to the main Hospital network except for traffic that must be routed to and from the network. With a growing trend towards IT centralisation, this may not be possible, in which case:-
Avoid Low Speed Network Links at all costs
Even if a server database is in use, a data intensive application today assumes a 100 megabit Local Area network as standard, though you might get away with 10 megabits for an isolated, low user count departmental network. Anything slower – such as a 2 MB leased line between your users and the server - is going to give very poor performance, even where a server database is concerned. If still using the older shared file type of database (Access, DataFlex), a low speed, 2 MB connection will not work.
Interpret busy time slow downs appropriately
Even with a 100MB infrastructure, hospital local area networks are large, heavily used and commonly overloaded. If your application works at 7:00 am and slows down by mid morning, don’t assume it has a built in delay loop to slow itself down depending on the time of day! Assume that your central database server or network is getting busy. Or, other applications running on the same physical server are likewise getting busy.
Use a Server Database
The shared file database is now not appropriate for use, generating much too much network traffic to be a “good neighbour” on a hospital LAN. Except for the smallest and most isolated of departmental requirements, a server database must be used. All Eclipse-fm® sites are now (V 4 and above) based on MS SQL server with 2005 Express as the advised minimum.
Adoption of a server database will reduce the network traffic as compared with a shared file database, as the traffic needed for managing data requests and saves, as opposed to the data records themselves is eliminated. However there is still relatively heavy traffic in the moving of actual data records to and from the database to populate those look up lists and grid entries.
Minimise the distance between data and application
Except where the ideal of a local FM Department sub-network can be achieved, with its own server, this primarily applies to deployment via Terminal Services/Citrix, or a web module. These should be deployed either on the server handling the database, or (for highest performance) on a second server with a dedicated, high speed Gigabit (or better) network connection between the two.
Use Terminal Services, Windows Remote Applications, or Citrix
Using Terminal Services, the latest Windows “remote applications”, or Citrix achieves the ideal of deploying the application as close as possible to the database, within the same physical server. With all instances of the application running in the same physical server, record finding and transfer to the application is all “in memory”, and therefore very fast indeed. If not on the same server as the database, the considerations of close co-location and fast, dedicated connection must apply.
When using Terminal Services, remote applications or Citrix, no transaction data is put onto the network, only screen update information, keyboard and mouse data, which is trivial, and report content which is relatively trivial and infrequent compared to transaction data. Now, your application is a good “network neighbour”, and even slow, 2MB leased lines become viable. It is even usable via a laptop connected via a Mobile phone.
Back to Contents
ServerPower and the impact of running other applications
Ten years ago the perceived wisdom was “One server, one task”. Now we can get eight processor cores into one physical box. So how much work can we get out of one box?
Distinguish between current and older servers
While current multi processor, multi-core equipped servers can provide lots of power, do not assume that older ones will be as powerful. We have seen “unusable” performance cured by doing no more than replacing an old server with a (cheaper to buy!) modern equivalent.
Consider processing power and memory.
A twin quad core processor will provide plenty of processing power, but is still going to see a finite amount of memory. Your server database wants lots of memory, but will probably be well served by just one of those processors, dedicated to database serving, with (at least) 1 or 2Gigabyte of memory allocated to it. Running multiple Eclipse-fm® instances, other applications will occupy the other processors, but may run you up against the 4GB (but now only 2 or 3 GB after the database has been accommodated) memory limit (unless you are able to use the Enterprise edition of Windows server, or until 64Bit deployments become common).
So, do not assume that you (or “IT”) can load “everything” onto your server.
If running Terminal Services or Citrix, remember that each user instance of the application will need both processor power and memory. At some point, a big database and lots of users under MS Terminal Services will need two separate servers. You will only be able to judge the balance if you can get to see your server performance – memory, CPU usage – which you may not be able to do if it is locked away in the IT Centre.
Virtual Servers
The latest trend is to provide multiple virtual servers on a single physical server. But currently, it is likely that each virtual server has to share that single 4Gigabyte allowance of physical memory. Virtual servers are good for running lots of small, light server applications; server databases do not fall into that category, and neither does the load of running Terminal services or Citrix.
So if you were thinking of running three virtual servers, each with MS SQL, and each MS SQL is going to have even only 1 GB of memory, the maths won’t add up. Nor will the network access, the capacity of which will now be shared between all the applications running in that one physical server. If offered a virtual server space on an already running server for your application and database, check what else is running on that server, and how it is configured before accepting the offer!
The Future
Windows Remote Applications, available on Windows 2008 server allow users to execute an application on the server as if it were a local application. This considerably simplifies printing issues, and as remote applications appear as icons in the existing desktop it is easier for users to understand than the complete new desktop instance that MS Terminal Services implies. This is not yet a proven option, but looks very interesting.
We expect to see 64Bit server technology move into common use over the next year. This will considerably lift the current 4GB memory limitation, resulting in much larger workloads becoming supportable either as a dedicated server, or even more usefully, in supporting server virtualisation.
Using the Hospital’s MS SQL Server installation
Your hospital may have a data centre managed MS SQL database server to which you can add your Eclipse-fm® database. In theory this is a valid solution, particularly where you are going to run instances of the application through Terninal Services or Citrix on a data centre server. In practice, make sure that the central server has the capacity to handle Eclipse-fm® demands, and if performance is slow and particularly slower at certain times of day, suspect that this may not be the case.
Back to Contents
