[ovirt-users] Tunable parameters in ovirt engine

Juan Hernández jhernand at redhat.com
Wed Mar 7 13:55:12 UTC 2018


With the default configuration of the web server it is impossible to 
handle more than 256 *connections* simultaneously. I guess that "ab" is 
opening a connection for each concurrent request, so when you reach 
request 257 the web server will just reject the connection, there is 
nothing that the JBoss can do about it; you have to increase the number 
of connections supported by the web server.

Or else you may want to re-consider why you want to use 1000 
simultaneous connections. It may be OK for a performance test, but there 
are better ways to squeeze performance. For example, you could consider 
using HTTP pipelining, which is much more friendly for the server than 
so many connections. This is what we use when we need to send a large 
number of requests from other systems. There are examples of how to do 
that with the Python and Ruby SDKs here:

   Python:
 
https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/asynchronous_inventory.py

   Ruby:
 
https://github.com/oVirt/ovirt-engine-sdk-ruby/blob/master/sdk/examples/asynchronous_inventory.rb

On 03/07/2018 02:43 PM, Hari Prasanth Loganathan wrote:
> Hi Juan,
> 
> Thanks for the response.
> 
> I agree web server can handle only limited number of concurrent requests.
> But Why it is failing with SSL handshake failure for few requests, Can't
> the JBOSS wait and serve the request? We can spare the delay but not with
> the request fails. So Is there a configuration in oVirt which can be tuned
> to achieve this?
> 
> Thanks,
> Hari
> 
> On Wed, Mar 7, 2018 at 7:05 PM, Juan Hernández <jhernand at redhat.com> wrote:
> 
>> The first thing you will need to change for such a test is the number of
>> simultaneous connections accepted by the Apache web server: by default the
>> max is 256. See the Apache documentation here:
>>
>>    https://httpd.apache.org/docs/2.4/mod/mpm_common.html#maxrequestworkers
>>
>> In addition I also suggest that you consider using the "worker"
>> multi-processing module instead of the "prefork", as it usually works
>> better when talking to a Java application server, because it re-uses
>> connections better.
>>
>> On 03/07/2018 02:20 PM, Hari Prasanth Loganathan wrote:
>>
>>> Hi Team,
>>>
>>> *Description of problem:*
>>>
>>> I am trying to achieve 1000 concurrent request to oVirt. What are the
>>> tunable parameters to achieve this?
>>>
>>> I tried to perform the benchmarking for ovirt engine using Apache
>>> benchmark
>>> using the same SSO token.
>>>
>>> ab -n 1000 -c 500 -k -H "accept: application/json" -H "Authorization:
>>> Bearer SSOTOKEN" https://172.30.56.70/ovirt-engine/
>>> <https://172.30.56.70/ovirt-engine/api/vms/5440271b-afb3-48b
>>> b-9ff1-076fc07ebf50/statistics>
>>>
>>> When the number of concurrent request is 500, we are getting more than 100
>>> failures with the following error,
>>>
>>> SSL read failed (1) - closing connection
>>> 139620982339352:error:
>>>
>>> NOTE: It is scaling for concurrent request below 500.
>>>
>>> I used the profiler to get the memory and CPU and it seems very less,
>>>
>>>     PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+
>>> COMMAND
>>> 30413 ovirt     20   0 4226664 882396   6776 S 126.0 23.0  27:48.53 java
>>>
>>> Configuration of the machine in which Ovirt is deployed :
>>>
>>> RAM - 4GB,
>>> Hard disk - 100GB,
>>> core processor - 2,
>>> OS - Cent7.x.
>>>
>>> In which 2GB is allocated to oVirt.
>>>
>>>
>>> Version-Release number of selected component (if applicable):
>>>
>>> 4.2.2
>>>
>>>
>>> How reproducible:
>>>
>>> If the number of concurrent requests are above 500, we are easily facing
>>> this issue.
>>>
>>>
>>> *Actual results:*
>>>
>>> SSL read failed (1) - closing connection
>>> 139620982339352:error:
>>>
>>> *Expected results:*
>>>
>>> Request success.
>>>
>>>
>>> Thanks,
>>> Hari
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>
> 



More information about the Users mailing list