[
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
