cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daan Hoogland (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CLOUDSTACK-4328) Make "mode http" & "option httpclose" in HAproxy.conf configurable on port 80
Date Fri, 30 Aug 2013 10:21:51 GMT

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Daan Hoogland updated CLOUDSTACK-4328:
--------------------------------------

    Description: 
By default CS configures "mode http" & "option http" when it detects a rule on public
port 80.

In most situations this is perfectly OK, but we hit a specific situation where this has negative
impact on performance. In this case a Varnish implementation which needs to run on port 80
and cannot run on an alternative port. We could imagine this could be an issue for other CS
users too.
Besides this also the maxconnections needs to be raised but this has already been address
by CS-2997, which is also the inspiration to make the "http mode" configurable.

next several other related options need to be set
         maxpipes 20480 # sugestion is to set it to 1/4 of max connection and do this automatically
(if needed this can be altered later
         nokqueue
         nopoll

and the following set
        option forwardfor
        option forceclose
be changed into
        no option forceclose


Details on the performance difference below.

So we like to see this "http mode"on port 80 configurable. e.g. httpmode false-true on the
API

See also CS-2997 and the following commits:
dd33abffbe3b7c5b615e8f64b1824a720329dd0d [dd33abf]
954e1978130b3cfb0c73f2f1506d94440f478f01 [954e197]

Performance testing details:

with ‘mode http en option httpclose’ on de load-balancing rule:

9:34 root@w6 /home/erwin/src/wrk > ./wrk  -c 1000 -t 20 -d 20 http://xxxxx/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg

Running 20s test @ http://xxxxx/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg
  20 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     6.21s     6.30s   15.87s    82.30%
    Req/Sec    43.61     37.81   371.00     78.61%
  16452 requests in 20.01s, 146.60MB read
  Socket errors: connect 0, read 8, write 309, timeout 4753
Requests/sec:    822.03
Transfer/sec:      7.33MB

-	without:

9:33 root@w6 /home/erwin/src/wrk > ./wrk  -c 1000 -t 20 -d 20 http://xxxxx/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg

Running 20s test @ http://xxxxx/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg
  20 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   240.62ms    1.28s   12.19s    97.80%
    Req/Sec   545.98    181.96     1.46k    74.70%
  222229 requests in 20.00s, 1.92GB read
  Socket errors: connect 0, read 53, write 43, timeout 791
Requests/sec:  11109.45
Transfer/sec:     98.09MB


  was:
By default CS configures "mode http" & "option http" when it detects a rule on public
port 80.

In most situations this is perfectly OK, but we hit a specific situation where this has negative
impact on performance. In this case a Varnish implementation which needs to run on port 80
and cannot run on an alternative port. We could imagine this could be an issue for other CS
users too.
Besides this also the maxconnections needs to be raised but this has already been address
by CS-2997, which is also the inspiration to make the "http mode" configurable.

Details on the performance difference below.

So we like to see this "http mode"on port 80 configurable. e.g. httpmode false-true on the
API

See also CS-2997 and the following commits:
dd33abffbe3b7c5b615e8f64b1824a720329dd0d [dd33abf]
954e1978130b3cfb0c73f2f1506d94440f478f01 [954e197]

Performance testing details:

with ‘mode http en option httpclose’ on de load-balancing rule:

9:34 root@w6 /home/erwin/src/wrk > ./wrk  -c 1000 -t 20 -d 20 http://xxxxx/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg

Running 20s test @ http://xxxxx/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg
  20 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     6.21s     6.30s   15.87s    82.30%
    Req/Sec    43.61     37.81   371.00     78.61%
  16452 requests in 20.01s, 146.60MB read
  Socket errors: connect 0, read 8, write 309, timeout 4753
Requests/sec:    822.03
Transfer/sec:      7.33MB

-	without:

9:33 root@w6 /home/erwin/src/wrk > ./wrk  -c 1000 -t 20 -d 20 http://xxxxx/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg

Running 20s test @ http://xxxxx/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg
  20 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   240.62ms    1.28s   12.19s    97.80%
    Req/Sec   545.98    181.96     1.46k    74.70%
  222229 requests in 20.00s, 1.92GB read
  Socket errors: connect 0, read 53, write 43, timeout 791
Requests/sec:  11109.45
Transfer/sec:     98.09MB


    
> Make "mode http" & "option httpclose" in HAproxy.conf configurable on port 80
> -----------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-4328
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4328
>             Project: CloudStack
>          Issue Type: Improvement
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Virtual Router
>    Affects Versions: 4.2.0
>            Reporter: Roeland Kuipers
>            Assignee: Daan Hoogland
>
> By default CS configures "mode http" & "option http" when it detects a rule on public
port 80.
> In most situations this is perfectly OK, but we hit a specific situation where this has
negative impact on performance. In this case a Varnish implementation which needs to run on
port 80 and cannot run on an alternative port. We could imagine this could be an issue for
other CS users too.
> Besides this also the maxconnections needs to be raised but this has already been address
by CS-2997, which is also the inspiration to make the "http mode" configurable.
> next several other related options need to be set
>          maxpipes 20480 # sugestion is to set it to 1/4 of max connection and do this
automatically (if needed this can be altered later
>          nokqueue
>          nopoll
> and the following set
>         option forwardfor
>         option forceclose
> be changed into
>         no option forceclose
> Details on the performance difference below.
> So we like to see this "http mode"on port 80 configurable. e.g. httpmode false-true on
the API
> See also CS-2997 and the following commits:
> dd33abffbe3b7c5b615e8f64b1824a720329dd0d [dd33abf]
> 954e1978130b3cfb0c73f2f1506d94440f478f01 [954e197]
> Performance testing details:
> with ‘mode http en option httpclose’ on de load-balancing rule:
> 9:34 root@w6 /home/erwin/src/wrk > ./wrk  -c 1000 -t 20 -d 20 http://xxxxx/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg
> Running 20s test @ http://xxxxx/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg
>   20 threads and 1000 connections
>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>     Latency     6.21s     6.30s   15.87s    82.30%
>     Req/Sec    43.61     37.81   371.00     78.61%
>   16452 requests in 20.01s, 146.60MB read
>   Socket errors: connect 0, read 8, write 309, timeout 4753
> Requests/sec:    822.03
> Transfer/sec:      7.33MB
> -	without:
> 9:33 root@w6 /home/erwin/src/wrk > ./wrk  -c 1000 -t 20 -d 20 http://xxxxx/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg
> Running 20s test @ http://xxxxx/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg
>   20 threads and 1000 connections
>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>     Latency   240.62ms    1.28s   12.19s    97.80%
>     Req/Sec   545.98    181.96     1.46k    74.70%
>   222229 requests in 20.00s, 1.92GB read
>   Socket errors: connect 0, read 53, write 43, timeout 791
> Requests/sec:  11109.45
> Transfer/sec:     98.09MB

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message