ConnectR Performance

Server Requirements

The ConnectR Server software requires that a dedicated server be used to run the software. For best performance, it is recommended that the server have quick disk access, adequate processing power to convert hundreds of thousands of healthcare messages daily, and abundant RAM to minimize swap-file usage. The machine must also have a relational database management system (RDBMS), as well as the ConnectR interfaces.

Hard Disk and RAM Requirements

The minimum disk space requirement is 20MB. However, this will vary depending on the ConnectR functions that the user accesses. (Additional disk space will be required if the user is performing Import/Export functions. In this case, an additional 100 MB of Hard Disk space is recommended).
The minimum RAM requirement is 32MB, but this will depend on the functions that the user will be accessing. (Additional memory will be required if the user is performing Import/Export functions. In this case, an additional 96 MB of RAM is recommended).

Processing Transactions and Hard Drive Considerations

ConnectR Server utilizes a store and forward mechanism for each transaction it processes. Each transaction (that moves from one application to another through ConnectR) is temporarily stored on the hard drive of the ConnectR Server. The benefit to this is that each transaction can be accessed at anytime— and this means that errors in and with messages can be fixed and resubmitted at will. The disadvantage is the potential for requiring a vast amount of disk space.

Additional disk space is necessary if the customer site uses the auditing features of ConnectR to keep a record of transactions and user activities via the front-end.

From our experience at customer sites, we have developed an algorithm to determine the minimum disksize requirements for ConnectR Server:
(#TPD) x (6kB) x (#DTH) + 1GB = Minimum Hard Disk Requirement

For example, a customer predicts to have 100,000 interface transactions per day, and would like to hold the audit trail for 14 days. The disk space required on the ConnectR Server will be: 100,000 x 6,000 x 14 + 1 = 9.4 GB

TPD is the number of transactions per day expected by a customer. Each registration, scheduling, result, dictionary update will result in a transaction.
DTH is the number of days the customer wishes to hold the audit trails on their ConnectR Server.

Memory Considerations

In addition to the ConnectR processing code, the operating system (Windows NT or Windows 2000) and MS SQL Server 2000 is loaded in RAM.

From our past experience with customers, we have developed an algorithm to determine the minimum RAM requirement for ConnectR Server software:
(#INT) x (20M)) + (#TTE) x (100)) + .5 GB = Minimum Memory Requirement

For example, a customer predicts that they will have five ConnectR interfaces, and that they will have 1,000 rows in the Translation Tables. The minimum memory requirement will be:
(5 x 20,000,000) + ((1,000) x (100)) + 500,000,000 = 600.01 MB of RAM.

INT is the number of interfaces that customer projects to service using ConnectR
TTE is the number of translation table entries that a particular customer projects to need. There could be one entry per dictionary entry is the application uses translation table entries heavily.

Capacity

There isn’t a hard cap on the # of interfaces that can be installed, but at some point you will start to run out of resources on the server and will need to split all new interfaces on to another ConnectR instance.

#Interfaces	Notes
0 - 60	No issues as long as RAM and CPU’s aren’t being pegged (i.e. under spec’d server)
> 60	Need to run IDXConnectR service as a user account that is NOT running anything else on that server
> 75	Probably should apply the reg fix outlined below
100 - 120	Have clients running this # successfully with the changes above
> 120	Uncharted waters, haven’t seen much success running this many

ConnectR Out Of Memory Errors

Problem

Out of memory errors in connectr

Overview

The desktop heap utilized by ALL services running as local system that do not interface with the desktop is called the ¿Service-0x0-3e7$\Default¿ heap (seen below). By default you only have 512kb for the services heap. ConnectR was sharing that space with other services. The other services were taking up about 81kb of the 512kb. ConnectR was using about 5.9kb per connect~2.exe process (distinct interface source or target). This would allow for about 73 ConnectR processes in your old configuration before running into heap allocation issues. Right now scott say he has 90% of them up and there are 90 ConnectR processes.

To correct this we put the ConnectR service running as the smg\allscripts user. This created a new desktop heap called ¿Service-0x0-2b441$\Default¿ to isolate the ConnectR processes. I also increased the size of the service desktop heaps to 1024 from 512. Now ConnectR should be able to run approx 173 interfaces and if it goes over will only corrupt it's own memory heap and not the other services.

Once you would go over your heap allocation you would corrupt the heap where not only connectr was, but, all system services were running resulting in eventide 243 ¿desktop heap allocation failed¿ that we talked about previously. Once the desktop heap allocations failed the services affected would become unstable. This might affect an interface that is trying to start, it might affect a windows service that is running or trying to start, etc. This could lock connectr or the entire system.

I can tell you this was absolutely a problem. I cannot guarantee it is the ONLY problem. You should be able to start up all your interfaces w/o having heap allocation failures now though.

Technical details

Here is the output of dheapmon after the change

 Session ID:    0 Total Desktop: ( 10432 KB -   10 desktops)

 WinStation\Desktop            Heap Size(KB)    Used Rate(%)

 WinSta0\Default                    3072              1.4
 WinSta0\Disconnect                   64              4.0
 WinSta0\Winlogon                    128              6.4
 Service-0x0-3e7$\Default           1024<-was 512     7.9 <=old heap under local system was 512
 Service-0x0-3e4$\Default           1024              1.7
 Service-0x0-3e5$\Default           1024              0.2
 SAWinSta\SADesktop                 1024              0.2
 __X78B95_89_IW\__A8D9S1_42_ID      1024              0.7
 Service-0x0-2b441$\Default         1024             51.8 <= new heap under allscripts account
 Service-0x0-6763a$\Default         1024              0.9

end dheapmon output ----------------------------

Note this value:

 Service-0x0-2b441$\Default         1024             51.8

current usage 530.432 kb (1024*.518) with 90 connectr processes.. approx 5.9 kb each = 173 connecr processes (1024*.518/90)

as local system we were running under with only 512kb (previously configured):

 Service-0x0-3e7$\Default           1024              7.9

Would have been:

 Service-0x0-3e7$\Default           512               15.8

with means 15.8% of 512kb = 81kb taken up by other services leaving 431KB for connectr at 5.9 kb each = 73 interfaces that could be run.

The increase from 512 to 1024 was configured in the registry under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems Changing the Windows key from: %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

To: %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,1024 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

Notice the LAST param in the Shared section was changed instead of the first: Windows SharedSection=1024,3072,512 To: Windows SharedSection=1024,3072,1024

Please note dheapmon will only show the heap in the session you are in. To monitor most of the heap you would run in session id 0 (console). There are more heaps created upon rdp login which are isolated from the session 0 heap, but, should be kept in mind if you ever decide to increase.