Mailing List Archive: h2c benchmarks with same Ubuntu tune as before

h2c benchmarks with same Ubuntu tune as before

Aug 29, 2022, 7:02 PM

Post #1 of 3 (377 views)

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 [ In reply to ]

joe at sunstarsys

Aug 31, 2022, 9:41 AM

Post #2 of 3 (376 views)

Permalink

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 <joe@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.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

Re: h2c benchmarks with same Ubuntu tune as before [ In reply to ]

joe at sunstarsys

Aug 31, 2022, 9:45 AM

Post #3 of 3 (376 views)

Permalink

*100_000 simultaneous requests.

On Wed, Aug 31, 2022 at 12:41 PM Joe Schaefer <joe@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 <joe@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.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

Mailing List Archive

Mailing List Archive

Attached Files: