Remoting Comparisons Part 2

Wednesday, March 30, 2005

Here is another unofficial remoting comparison.

Three classes involved:

RemotingClassA - Returned from the TCP remoting service with the sole purpose of returning a useful instance of MBVClass1.
RemotingClassB - Remote object hosted by IIS that retrieves a RemotingClassA instance to finally return an MBVClass1.
MBVClass1 - ISerializable Class with data that must be marshaled for local use without proxy to a server behind a firewall. The client has a concrete class to use this object.

The main goal is to retrieve an MBVClass1 from a Singleton or SingleCall TCP remoting service. I need these basic numbers to choose the fastest VPN and Internet accessibility, excluding factors such as DB interactions, multiple processors, slow networks, etc. The primary goal is to write the TCP remoting service once and have a web interface retrieve objects from that service (scalability issues aside).

The " Client <-> WS <-> TCP " contacts a stateless web service which creates and returns an MBVClass1 with the SOAP formatter. This means that the client application would not use remoting, only a web service interface. This is simple for the client and allows version changes to be limited between the web service and the internal TCP service. Using the web service also has advantages of plugin technologies such as compression, encryption, and authentication as Web services evolve.

The “Client <-> IIS <-> TCP” is a remoting object hosted in IIS, RemotingClassB, used to connect to the internal TCP remoting service to create a RemotingClassA to return MBVClass1. This must be in a second class, RemotingClassB, because the proxy that is created for RemotingClassA must be available on the client that is hosting the object in IIS. The actual object for RemotingClassA lives in the TCP remoting service. The client can instead use the proxy for RemotingClassB to get the MBVClass1 that resides in the IIS hosted object.

The following are call counts in a 5 second period. The IIS remoting solution uses the binary formatter after retrieving the object from the TCP remoting service. The web solutions, IIS host and the Web Service retrieval would perform the JIT compile delay and also perform fewer calls when the Web server was under a load. Compression was also tested using the latest ICSharpCode.SharpZipLib assembly.

Localhost

Method	Return Object	Return Object w/10K String	Return Object w/100K String	Return Object w/1MB String	Return Object w/1MB String Max Compression Speed (5844 Chars returned)	Return Object w/1MB String Max Compression Size (1324 Chars returned)
Local	7,300,000	325,000	7,400	1,100	124	2
Client - TCP	5,550	3,130	670	75	170	1
Client - IIS - TCP	685	520	205	32	137	3
Client - WS - TCP	710	560	205	32	138	3

Network Retrieval

Method	Return Object	Return Object w/10K String	Return Object w/100K String	Return Object w/1MB String	Return Object w/1MB String Max Compression Speed (5844 Chars returned)	Return Object w/1MB String Max Compression Size (1324 Chars returned)
Client - TCP	2,750	1,465	250	30	54	2
Client - IIS - TCP	310	275	40	10	48	2
Client - WS - TCP	390	300	20	7	48	2

Understanding how things work in the CLR such as the JIT compiler and the GC is imperative when evaluating choices like these.

Pay for play as we say.

No Comments