You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by jo...@sunstarsys.com on 2022/08/30 02:02:07 UTC
h2c benchmarks with same Ubuntu tune as before
h2load -n 100000 -c 1000 -m 100 http://localhost/perl-script/enquiry.pl
starting benchmark...
spawning thread #0: 1000 total client(s). 100000 total requests
Application protocol: h2c
progress: 10% done
progress: 20% done
progress: 30% done
progress: 40% done
progress: 50% done
progress: 60% done
progress: 70% done
progress: 80% done
progress: 90% done
progress: 100% done
finished in 11.60s, 8624.38 req/s, 11.13MB/s
requests: 100000 total, 100000 started, 100000 done, 100000 succeeded, 0 failed, 0 errored, 0 timeout
status codes: 100000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 129.04MB (135312547) total, 560.93KB (574391) headers (space savings 95.51%), 126.74MB (132900000) data min max mean sd +/- sd
time for request: 225.73ms 11.31s 5.76s 3.09s 58.62%
time for connect: 15.40ms 212.74ms 62.57ms 54.73ms 87.50%
time to 1st byte: 261.01ms 9.04s 3.00s 2.01s 68.00%
req/s : 8.70 68.06 15.64 9.73 85.70%
Re: h2c benchmarks with same Ubuntu tune as before
Posted by Joe Schaefer <jo...@sunstarsys.com>.
*100_000 simultaneous requests.
On Wed, Aug 31, 2022 at 12:41 PM Joe Schaefer <jo...@sunstarsys.com> wrote:
> To explain the new-new here, with HTTP/2 comes this whole new idea of
> multiplexed "HTTP channels" within a single TCP connection. In this
> benchmark, each of the 1000 concurrent tcp connections has 100 multiplexed
> requests to the same URL as on the command line.
> The reason mod_http2 need threads is to explode these multiplexed channels
> into independent requests within the same server process context.
> Otherwise it'd have to queue them (it could, but really not the point of
> multiplexing in the spec).
> In effect, you are seeing my laptop respond to 10000 simultaneous requests
> for that URL. Most of this is serialized by the thread limits baked into
> mpm_event.conf and perl.conf, but it's still standing at the end of the
> exercise.
>
> On Mon, Aug 29, 2022 at 10:02 PM <jo...@sunstarsys.com> wrote:
>
>> h2load -n 100000 -c 1000 -m 100 http://localhost/perl-script/enquiry.pl
>>
>> starting benchmark...
>>
>> spawning thread #0: 1000 total client(s). 100000 total requests
>>
>> Application protocol: h2c
>>
>> progress: 10% done
>>
>> progress: 20% done
>>
>> progress: 30% done
>>
>> progress: 40% done
>>
>> progress: 50% done
>>
>> progress: 60% done
>>
>> progress: 70% done
>>
>> progress: 80% done
>>
>> progress: 90% done
>>
>> progress: 100% done
>>
>>
>>
>> finished in 11.60s, 8624.38 req/s, 11.13MB/s
>>
>> requests: 100000 total, 100000 started, 100000 done, 100000 succeeded, 0
>> failed, 0 errored, 0 timeout
>>
>> status codes: 100000 2xx, 0 3xx, 0 4xx, 0 5xx
>>
>> traffic: 129.04MB (135312547) total, 560.93KB (574391) headers (space
>> savings 95.51%), 126.74MB (132900000) data min
>> max mean sd +/- sd
>>
>> time for request: 225.73ms 11.31s 5.76s 3.09s 58.62%
>>
>> time for connect: 15.40ms 212.74ms 62.57ms 54.73ms 87.50%
>>
>> time to 1st byte: 261.01ms 9.04s 3.00s 2.01s 68.00%
>>
>> req/s : 8.70 68.06 15.64 9.73 85.70%
>>
>>
>>
>>
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <jo...@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>
--
Joe Schaefer, Ph.D.
We only build what you need built.
<jo...@sunstarsys.com>
954.253.3732 <//954.253.3732>
Re: h2c benchmarks with same Ubuntu tune as before
Posted by Joe Schaefer <jo...@sunstarsys.com>.
To explain the new-new here, with HTTP/2 comes this whole new idea of
multiplexed "HTTP channels" within a single TCP connection. In this
benchmark, each of the 1000 concurrent tcp connections has 100 multiplexed
requests to the same URL as on the command line.
The reason mod_http2 need threads is to explode these multiplexed channels
into independent requests within the same server process context.
Otherwise it'd have to queue them (it could, but really not the point of
multiplexing in the spec).
In effect, you are seeing my laptop respond to 10000 simultaneous requests
for that URL. Most of this is serialized by the thread limits baked into
mpm_event.conf and perl.conf, but it's still standing at the end of the
exercise.
On Mon, Aug 29, 2022 at 10:02 PM <jo...@sunstarsys.com> wrote:
> h2load -n 100000 -c 1000 -m 100 http://localhost/perl-script/enquiry.pl
>
> starting benchmark...
>
> spawning thread #0: 1000 total client(s). 100000 total requests
>
> Application protocol: h2c
>
> progress: 10% done
>
> progress: 20% done
>
> progress: 30% done
>
> progress: 40% done
>
> progress: 50% done
>
> progress: 60% done
>
> progress: 70% done
>
> progress: 80% done
>
> progress: 90% done
>
> progress: 100% done
>
>
>
> finished in 11.60s, 8624.38 req/s, 11.13MB/s
>
> requests: 100000 total, 100000 started, 100000 done, 100000 succeeded, 0
> failed, 0 errored, 0 timeout
>
> status codes: 100000 2xx, 0 3xx, 0 4xx, 0 5xx
>
> traffic: 129.04MB (135312547) total, 560.93KB (574391) headers (space
> savings 95.51%), 126.74MB (132900000) data min
> max mean sd +/- sd
>
> time for request: 225.73ms 11.31s 5.76s 3.09s 58.62%
>
> time for connect: 15.40ms 212.74ms 62.57ms 54.73ms 87.50%
>
> time to 1st byte: 261.01ms 9.04s 3.00s 2.01s 68.00%
>
> req/s : 8.70 68.06 15.64 9.73 85.70%
>
>
>
>
>
--
Joe Schaefer, Ph.D.
We only build what you need built.
<jo...@sunstarsys.com>
954.253.3732 <//954.253.3732>