crossroads

Git mirror of https://crossroads.e-tunity.com/
git clone git://git.finwo.net/app/crossroads
Log | Files | Refs

benchmarking.yo (5506B)

      1 This section shows how crossroads affects the
      2 transmitting of HTML data when used as an intermediate 'station'
      3 through which all data travels.
      4 
      5 
      6 subsect(Benchmark 1: Accessing a proxy via crossroads or directly)
      7 
      8 The benchmark was run on a system where the following was varied:
      9 
     10 enumeration(
     11         eit() A website was recursively spidered through a local squid
     12         proxy. The spidering was repeated 10 times, the total was recorded.
     13 
     14         eit() Crossroads was placed in front of the squid proxy, and
     15         the website was again recursively spidered. Again, the
     16         spidering was repeated 10 times and the total was recorded.)
     17         
     18 The crossroads configuration of the second alternative is shown below:
     19 
     20 verb(\
     21 service HttpProxy {
     22     port 8080;
     23     verbosity on;
     24     backend LocalSquid {
     25         server 127.0.0.1;
     26         port 3128;
     27         verbosity on;
     28     }
     29 })
     30 
     31 
     32 subsubsect(Results)
     33 
     34 The results of this test are that crossroads causes a negligible
     35 delay, if it is statistically relevant at all. Without crossroads, the
     36 timing results are:
     37 
     38 verb(\
     39 real	0m8.146s
     40 user	0m0.130s
     41 sys	0m0.253s)
     42 
     43 When using crossroads as a middle station, the results are:
     44 
     45 verb(\
     46 real	0m9.481s
     47 user	0m0.141s
     48 sys	0m0.230s)
     49 
     50 
     51 subsubsect(Discussion)
     52 
     53 The above shown results are quite favorable to crossroads. However,
     54 one should know that situations will exist where crossroads leans
     55 towards the 'worst case' scenario, causing up to 50%
     56 delay.
     57 
     58 E.g., imagine a test where a tt(wget) command retrieves a
     59 HTML document from an Apache server on tt(localhost). Now we have
     60 (almost) no overhead due to network throttling, hostname lookups and
     61 so on. When this test would be run either with or without crossroads
     62 in between, then theoretically, crossroads would cause a much larger
     63 delay, because it has to read from the server, and then write the same
     64 information to tt(wget).  Each read/write occurs twice when crossroads
     65 sits in between.
     66 
     67 This worst case scenario will however (fortunately) occur only very
     68 seldom in the real world:
     69 
     70 itemization(
     71         it() Normally network issues, such as the above mentioned host
     72         name lookups or throughput restrictions, will add
     73         significantly to the duration of a request. The 'twice as
     74         many' read/writes caused by crossroads are then relatively
     75         irrelevant.
     76 
     77         it() Normally a significant amount of time will be spent in a
     78         back end, due to processing (e.g., when calling a servlet on a
     79         back end). Again, this processing time will weigh much heavier
     80         than the multiple read/writes.)
     81 
     82 
     83 subsect(Benchmark 2: Crossroads versus Linux Virtual Server (LVS))
     84 
     85 LVS is a kernel-based balancer that acts like a masquerading
     86 firewall: TCP packets that arrive at the balancer are sent to one of
     87 the configured back ends. LVS has the advantage over crossroads that
     88 there is no stop-and-go in the transmission; in contrast, crossroads
     89 needs to send data via an internal buffer. Crossroads has the
     90 advantage that it offers instantaneous failover because it tries to
     91 contact the back end for upon each new TCP connection; in contrast,
     92 LVS isn't aware of downtime of back ends (unless one implements an
     93 external heartbeat). Also, crossroads offers more complex balancing
     94 than LVS.
     95 
     96 subsubsect(Environment)
     97 
     98 On the balancer, LVS was run on port 80, its forwarding set up for two
     99 equally weighted back ends, using tt(ipvsadm):
    100 
    101 verb(\
    102 ipvsadm -a -t 192.168.1.250:http -r 10.1.1.100:http -m -w 1
    103 ipvsadm -a -t 192.168.1.250:http -r 10.1.1.101:http -m -w 1)
    104 
    105 Crossroads was run on port 81. The configuration file is shown below:
    106 
    107 verb(\
    108 service http {
    109     port 81;
    110     dispatchmode roundrobin;
    111     revivinginterval 5;
    112     backend one {
    113         server 10.1.1.100;
    114         port 80;
    115     }
    116     backend two {
    117         server 10.1.1.101;
    118         port 80;
    119     }
    120 })
    121 
    122 subsubsect(Tests and results)
    123 
    124 In the first test, ports 80 and 81 on the balancer were 'bombed' with
    125 50 concurrent clients, each requesting a small page 50 times. The
    126 following timings where measured:
    127 
    128 itemization(
    129         it() How long it takes to establish a connection;
    130         it() How long it takes to retrieve the page.)
    131 
    132 The results of this test were:
    133 
    134 itemization(
    135         it() On average, each client took 0.12 seconds to connect
    136         to LVS, and each page was retrieved in 0.14 seconds;
    137         it() On average, each client took 0.11 seconds to connect to
    138         crossroads, and each page was retrieved in 0.13 seconds.)
    139 
    140 In this setup there seems to be no difference between the performance
    141 of LVS and crossroads!
    142 
    143 In a second test, the size of the retrieved page was varied from 2.000
    144 to 2.000.000 bytes. This test was taken to see whether crossroads would
    145 show performance degradation when transferring larger amounts of data.
    146 
    147 For each page size, 30 concurrent clients were started, that retrieved
    148 the page 50 times. Again, the connect times and processing times where
    149 recorded.
    150 
    151 The results of the total time (connect time + retrieval time)
    152 are shown in the below table:
    153 
    154 table(3)(rrr)(
    155   rowline()
    156   row(
    157     cell(bf(Bytes)) cell(bf(LVS timing)) cell(bf(Crossroads timing)))
    158   row(
    159     cell(2000) 	    cell(0.130741688) 	cell(0.12739582))
    160   row(
    161     cell(20000)     cell(0.490916224) 	cell(0.50376901))
    162   row(
    163     cell(200000)    cell(3.799440328) 	cell(4.33125273))
    164   row(
    165     cell(2000000)   cell(45.25090855) 	cell(45.9600728))
    166   rowline())
    167 
    168 Again, the results show that crossroads performs just as effectively
    169 as LVS, even with large data chunks!
    170