For testing the performance I used the following setup:
The procedure was not meant to produce highly accurate numbers, it should just give an impression of the delays we can expect when using NAT. The conditions in networks are mostly that complex I did not see much sense in trying to be more accurate. The numbers obtained are good enough for getting a feeling for what it means to have a NAT router, and that is all they are for.
I measured five different setups:
The following tables show the numbers I obtained. There are two rows for each setup. The upper one shows the numbers when I transferred the 20 MB file from Host 2 to Host 1, the lower row is for the transfer from Host 1 to Host 2. I always completed one direction before I started taking numbers for the other one. Swap space was unused on both hosts, there where only the basic processes running.
Table 1: raw numbers from 'time '-command
# | t1 | t2 | t3 | t4 | t5 | t6 | average |
7|c|seconds | |||||||
1 | 43.43 | 43.27 | 39.05 | 36.94 | 37.88 | 37.90 | 39.75 |
40.39 | 41.31 | 39.66 | 37.29 | 34.95 | 34.80 | 38.07 | |
2 | 40.57 | 38.86 | 36.17 | 37.70 | 35.94 | 37.08 | 37.72 |
40.24 | 41.06 | 40.10 | 35.68 | 35.22 | 34.42 | 37.79 | |
3 | 45.70 | 44.64 | 42.25 | 38.84 | 39.86 | 38.79 | 41.68 |
40.54 | 43.03 | 39.43 | 37.42 | 35.85 | 35.44 | 38.62 | |
4 | 49.27 | 48.96 | 41.85 | 39.97 | 39.20 | 39.94 | 43.20 |
41.57 | 42.19 | 40.73 | 36.44 | 35.79 | 36.25 | 38.83 | |
5 | 52.90 | 44.45 | 43.21 | 44.88 | 45.11 | 48.35 | 46.48 |
45.82 | 45.80 | 42.39 | 40.75 | 41.02 | 41.93 | 42.95 |
Table 2: numbers calculated from Table 1
# | t1 | t2 | t3 | t4 | t5 | t6 | average |
7|c|Kbytes/sec (ca.) | |||||||
1 | 482 | 484 | 536 | 567 | 553 | 553 | 527 |
519 | 507 | 528 | 562 | 599 | 602 | 550 | |
2 | 516 | 539 | 579 | 556 | 583 | 565 | 555 |
520 | 510 | 522 | 587 | 595 | 608 | 554 | |
3 | 458 | 469 | 496 | 539 | 525 | 540 | 502 |
517 | 487 | 531 | 560 | 584 | 591 | 542 | |
4 | 425 | 428 | 500 | 524 | 534 | 524 | 485 |
504 | 496 | 514 | 575 | 585 | 578 | 539 | |
5 | 396 | 471 | 485 | 467 | 464 | 433 | 451 |
457 | 457 | 494 | 514 | 510 | 499 | 487 |
It is interesting to note that even on the tiny private and closed network used for the tests there is a wide variation in the numbers. However, the general direction is clear. All test transfers started slow and became gradually faster, here we see TCP's slow-start algorithm at work. I have intentionally chosen a setup where the hosts and not the network are the bottleneck, because otherwise obviously the numbers would be worthless. I did no tests with virtual servers, because first I did not expect any surprises, i.e. completely different numbers, and second, I have implemented the structure that stores the dynamic client data as a list, which should be replaced by a more sophisticated structure like hashes or a binary tree anyway, i.e. testing the performance at this early stage does not make much sense. The list, however, was the choice in order to not complicate my very first virtual server implementation unnecessarily in addition it made bug tracking easier. Third, testing only the algorithm used for selecting a real server to map a client to is not useful since this choice is done just once while the list of clients (however it gets stored and searched) needs to be searched for every single packet.