Now before you read these numbers I'd like to be clear about the scenarios I tested. To make it easy on me I set up the internet test to work with one of our current product's test beds already set up with some real test data. There are two servers in this test bed, one is the application server hosting remote components in IIS (HttpChannel) and accessed by the client using the BinaryFormatter. The second server is the database server. So what I was measuring was also including the time it took to select the records from the database through the components (no business logic, just filling an untyped dataset from a stored proc simple select -- about 19 columns with various data types). The servers are in Florida and I work from home in California where I was running the client. I was accessing them over a cable modem. In the local test I had the exact same code and databse running in all tiers on my local development machine to simulate no network latency.
That said, we don't want look at the numbers per se, look at the trend -- that is what is important here. There are also a lot of factors that affect serialization over the internet on a cable modem and you'll notice that there are a few anomalies in the local numbers with small sets of data, probably because my dev machine hiccupped at that moment.
So to recap, this is what we're measuring;
1) The time it takes to make the remote call to activate the component,
2) The time it takes to select the records from the database and create the dataset,
3) In the case of the surrogate class, the time it takes to convert the dataset to a series of byte arrays,
4) The time it takes to transmit the data,
5) In the case of the surrogate class, the time it takes to convert the byte arrays back into a dataset.
My conclusion is that native Binary serialization of datasets is only better over a long wire when the number of rows are in the thousands. Our application is 99% data entry forms so we would never be returning that much data. The surrogate class does have a slight overhead if your network is not congested/not the internet, however nothing that the user would notice. Therefore, for now, I'm sticking with the surrogate class for our application. I'll let you know if I change my mind later based on more formal load testing.
Okay here are the performance numbers:
LOCAL TEST (Low Network Latency) | ||||||
# Records | Size (bytes) | Transmission Time (ms) | ||||
Surrogate | Binary | XML | Surrogate | Binary | XML | |
2 | 13,761 | 56,198 | 11,673 | 15.63 | 31.25 | 15.63 |
10 | 15,261 | 57,419 | 15,754 | 15.63 | 31.25 | 15.63 |
20 | 17,133 | 58,972 | 21,018 | 31.25 | 31.25 | 15.63 |
100 | 32,233 | 71,626 | 63,434 | 31.25 | 31.25 | 31.25 |
500 | 107,336 | 134,641 | 276,350 | 62.50 | 46.88 | 62.50 |
1000 | 203,943 | 216,285 | 550,832 | 93.75 | 78.13 | 109.38 |
2000 | 392,296 | 374,665 | 1,087,187 | 171.88 | 125.00 | 250.00 |
4000 | 772,451 | 694,776 | 2,174,403 | 343.75 | 265.63 | 515.63 |
8000 | 1,521,110 | 1,323,693 | 4,383,707 | 734.38 | 531.25 | 968.75 |
INTERNET TEST (High Network Latency) | ||||||
# Records | Size (bytes) | Transmission Time (ms) | ||||
Surrogate | Binary | XML | Surrogate | Binary | XML | |
2 | 13,761 | 56,198 | 11,673 | 312.50 | 578.13 | 312.50 |
10 | 15,261 | 57,419 | 15,754 | 328.13 | 640.63 | 390.63 |
20 | 17,133 | 58,972 | 21,018 | 343.75 | 655.43 | 343.75 |
100 | 32,233 | 71,626 | 63,434 | 421.88 | 671.88 | 593.75 |
500 | 107,336 | 134,641 | 276,350 | 906.25 | 1078.13 | 1875.00 |
1000 | 203,943 | 216,285 | 550,832 | 1484.38 | 1562.50 | 3531.25 |
2000 | 392,296 | 374,665 | 1,087,187 | 2640.63 | 2515.63 | 6750.00 |
4000 | 772,451 | 694,776 | 2,174,403 | 5312.50 | 4500.00 | 13312.50 |
8000 | 1,521,110 | 1,323,693 | 4,383,707 | 9687.50 | 8406.25 | 26609.38 |