Remoting Comparisons Part 2
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.
| 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.