Develop high performance distributed applications with batching, asynchrony, and parallel computation

• Download source files - 1002 Kb

Introduction

I have been working at creating a raw socket-based framework according to batching, asynchrony and parallel computation, since 2001. In 2002, I published my article entitled as Use of free SocketPro package for creating super client and server applications, and posted my ideas here. Afterwards, I spent a lot of my time to improve the software package. At this time, the framework is matured and completed in Win32 platforms. The framework has many attractive features. This article is focused on the performance comparison. Everyone knows that software performance is extremely important within a real enterprise system. No software engineer is willing to create a sluggish software. This article, attached with all of the source codes, specifically shows you the performance improvement of the framework over the latest Microsoft technology, .NET remoting. Hopefully, it catches your attention.

Setup

The article provides you sample client server projects to help you play with both .NET remoting and SocketPro. First of all, you need to make sure that MS .NET framework version 1.1 is installed at both client and server machines and runs properly. Second, you need to set up either MSDE or MS SQL server having the sample database Northwind. Afterwards, do the following setups for both client and server.

Client setup -- registering two COM DLLs:

Find Command Prompt, navigate to the directory which contains the two COM DLLs usocket.dll and udb.dll, and register the two DLLs by executing the following commands:

• Regsvr32 usocket.dll
• Regsvr32 udb.dll

Server setup:

Find the executable file DotNetSvrOne.exe, and start it by double clicking it. You are ready to play with the sample projects.

To see the source code, see the directory ..\sourcecode, which contains the source code of udb.dll and SocketAroAdapter.dll. Also, you can find the client and server sample codes in the directories ..\source code\offsetclient and ..\source code\offsetserver, respectively. Note that udb.dll is written from Visual C++ and ATL/COM. If you want to see the code execution inside this DLL, you have to have some basic knowledge about the use of Visual C++.

The .NET remoting sample is created with TCP binary format channel with UTF-8 encoding.

Experimental hardware conditions

The performance data in the following section is obtained with the following hardware setups:

• Server: Single processor/P IV 1.9 GHz, 512 M RAM, MS XP Professional.
• Client: Single processor/P IV 1.9 GHz, 512 M RAM, MS XP Professional.

Results

The following data was obtained using different networks, slow dial-up modem, 10-Mbps LAN, and 100-Mbps LAN. In addition, I also list the test results of processing requests across different applications within the same machine (Localhost).

The test results include querying different size of rowsets and executing 10000 echo requests. See the first column in the following table. The required time in ms is the time required for processing a request using .NET remoting. The time required for processing a similar request with SocketPro can be found by dividing a required time by a factor. For example, the time, required for bringing the table Products from a .NET remoting server to a client, is 48.9 ms. In comparison, the time required for SocketPro is just 8.9 ms (48.9/5.5) only. Therefore, a factor in the following table actually represents the speed improvement of SocketPro over .NET remoting. The test was designed to investigate the influence of different rowset size on .NET remoting and SocketPro performances. See the data inside the table columns 2 and 3. For details about table schema, please see the MS sample database Northwind using either Access or SQL server.

Overall, the results in the above table clearly shows that SocketPro has a huge performance benefit over .NET remoting under all cases.

LAN (Local Area Networking):

1. Tiny rowset (130% - 250%)

   Regarding to a tiny rowset (for example Shippers), SocketPro is roughly about %90 (30% - 150%) faster than .NET remoting.

2. Small rowset (400% - 700%)

   With a small table (e.g., Products), the speed of SocketPro is typically five (300% - 600%) times faster than .NET remoting.

3. Regular rowset (1000% - 3000%)

   If you have to handle a normal size rowset like the tables Order Details and Orders, as shown in the above table, SocketPro could be easily over twenty times faster than .NET remoting.

4. Large rowset ( > 3000%)

   For a large rowset like "select * from orders, products" which generates a large (not really too large) rowset with (14+10) columns and 63910 rows (830*77), SocketPro is 3500% or more faster than .NET remoting. The memory foot print of .NET remoting is about 400 mega bytes RAM consumed with about 90 seconds overhead. The over head for SocketPro is just 0.01 second, and memory foot print is about 5 mega bytes in RAM only.

As implied with these test data, the larger a rowset, the larger a factor. It is implied that SocketPro is dramatically faster than .NET remoting when a large rowset is involved.

I also analyzed what factors cause the low performance of .NET remoting. It is found that .NET remoting is poor in both serializing a DataSet object into a stream at one side and de-serializing a stream back into a DataSet object at the other side. Each of the serializing and de-serializing costs about 42 seconds. Sending a DataSet stream from a server to a client over is relatively fast and efficient, and costs just a few seconds over 100 Mbps network. At this time, a DataSet object is marshaled across two application domains in one big text stream. Converting binary data into text and then into one big stream has too large overhead. On contrary, SocketPro marshals a rowset with binary format in batches instead of one big stream. Further, both serializing a rowset into streams at one side and de-serializing streams back into a rowset at the other side can happen simultaneously because of its asynchrony computation. The online compressing is very helpful to low bandwidth networks. The three SocketPro key features ensure its super performance.

Although MS may marshal a DataSet in binary format in the future and .NET remoting, it will be still slow because serializing and de-serializing a DataSet object as one big stream take too much memory. Consuming too much memory at the run time always decreases an application's performance, although it will be better in comparison with the current implementation of marshaling a DataSet object.

Simple Requests (about 1000%)

I also executed 10000 echo requests with both SocketPro and .NET remoting. As shown in the above table, the difference between the two is about a factor of 10. SocketPro can batch many requests and send them into a remote machine with a single stream. This key feature always improves your distributed application a lot. This is one of the attractive features with SocketPro.

WAN (Wide Area Networking):

I also compared SocketPro with .NET remoting on slow network having long latency, dial-up. The performance difference between SocketPro and .NET remoting is huge. See the data in the above table. SocketPro has been integrated with online compressing. Our experiment has verified that this feature is very helpful to all of the networks having a bandwidth less than 50 Mpbs. The feature typically increases performance three times for marshaling Unicode strings and one time at least for marshaling other primitive data types. If you have to send multiple requests to a remote server over expensive networks like dial-up, DSL, cable and wireless modems, the SocketPro batching feature will dramatically improve an application performance (up to 200 times or more). Considering long latency of slow networks, the improvement of SocketPro over .NET remoting is so huge that you can not simply ignore it!

In comparison to SocketPro, .NET remoting runs truly like snail, no matter what networks you use and no matter what objects or requests are processed. I am sorry to Microsoft and .NET remoting experts, but it is indeed a fact.

Conclusion

SocketPro is written from asynchrony, batching and parallel computation. Its design is dramatically different from frameworks like SOAP/XML web service, .NET remoting, DCOM, CORBA and Java RMI. It is more closer to non-blocking sockets but it certainly makes socket programming much more easier. This article is written specifically for demonstration of SocketPro performance, compared with MS .NET remoting. Although I didn't compare it with other common frameworks, it is guaranteed that all of other frameworks run like snail too in speed, in comparison to SocketPro. SocketPro delivers excellent performance because of its following key features:

1. SocketPro can batch any number of requests at client and return results at server so that network efficiency is 100% and no bandwidth is wasted. This is very different from the above common framework.
2. SocketPro online compressing further improves the performance 2 - 3 times typically. In some cases, the improvement can be more than ten times.
3. SocketPro fully takes advantage of binary transferring data over expensive networks. It doesn't use text format for moving data over network.
4. SocketPro uses 100% non-blocking socket communication so that all network devices on one transaction circle works concurrently, but the above common synchronous frameworks have no way to ensure that all network devices on one transaction circle works at the same time.

I don't expect that .NET remoting is able to match SocketPro in performance under any case no matter what machines and networks you have. Should you find a case that .NET remoting delivers similar performance, please let me know either here or privately.