Re: HAProxy-1.8 sometimes sends a shorter html when using multithread function
Hello Willy, Ryan I have ran the 3 times tests for each case The following lists are the results. TestA haproxy-1.8.30 + (patch 1+2+3) 1st 2nd 3rd Shorter HTML: 0 0 0 HTTP 408: 2 1 4 TestB haproxy-1.8.30 + (patch2 only) 1st 2nd 3rd Shorter HTML: 0 0 0 HTTP 408: 3 4 5 TestC haproxy-2.4.0 1st 2nd 3rd Shorter HTML: 0 0 0 HTTP 408: 0 0 0 Every case, the number of threads is 16. # I also ran the tests without multithread # funtuion and found no shoter HTML and # HTTP408 issue. >From this result, I thought as follows. * haproxy-1.8.30 Both of all patches and patch 2 only resolve the shoter html issue using multithread function, but the HTTP 408 issue remains. * haproxy-2.4.0 This version doesn't have both of the shoter html issue and the HTTP 408 issue using multithread function. So I checked even for other thread counts on haproxy-1.8.30 + patch2 as follows. N_THREADS N_SHORT N_HTTP408 1 0 0 2 0 0 8 0 2 12 0 1 (12 is CPUs inlucdes Hyper-Thread) 16 0 3 (1st test of previous list) 32 0 0 64 0 0 Now I think patch2 is enough for the shorter HTML isusue as Willy previously expected. The following text is about performance terms of mutithread function, I wrote this for your infomation. * The multithread function improves throuhput According the tests bellow, which download same HTML 10 million times in 20 parallel client processes, I found the multithread function clearly improves the throuhput. haproxy-1.8.30+(patch2 only) N_THREADS / RUN_TIME(sec) 1 / 1280 2 / 916 8 / 737 12 / 744 16 / 751 32 / 797 64 / 908 haproxy-2.4.0 N_THREADS / RUN_TIME(sec) 1 / 1400 2 / 947 8 / 726 12 / 730 16 / 743 32 / 782 64 / 905 # In the case only haproxy-2.4.0 + 64 threads, # the number of log messages was 24 less than # that of downloads, I think this is another issue. Before these tests, I also ran TPC-W tests and I couldn't find out performance improvement in HTTP mode. (In HTTPS mode, I found it improves performance) Yes, I know TPC-W is an obsolete test model. But the department I belong to have accumelated experience and tools about TPC-W. My department is verifying with these tools for performance and high availability upgrade verification. I first noticed the shorter HTML issue in these TPC-W tests. * Relation between the number of threads and CPUs In the number of threads is lower(1,2), the throughput of haproxy-2.4.0 is lesser than that of haproxy-1.8.30. But the throughput of haproxy-2.4.0 is superior when the number of threads is 8 or more. This may be due to the detailed difference in multithreaded exclusive control. Throughput is good when the number of threads(8,12,16) is about the same as the number of CPUs(12). Throughput drops if the number of threads is increased too much(32,64). Kazu On Tue, May 25, 2021 at 5:19 PM Kazuhiro Takenaka wrote: > Hellow Willy, > > # Sorry I post this message directly to you, > # so i resend to the mailing list. > > I tested the patches you suggested, and got > the following results. > > TestA haproxy-1.8.30 + patch(1 + 2 + 3) > Shorter HTML: 0 > HTTP 408: 2 > > TestB haproxy-1.8.30 + patch(2 only) > Shorter HTML: 0 > HTTP 408: 3 > > TestC haproxy-2.4.0 > Shorter HTML: 0 > HTTP 408: 0 > > haproxy-2.4.0 ran without no issue, > but I found the bytes_read column of > haproxy-2.4.0 was diffrent from that of > haproxy-1.8.30 and haproxy-2.0.22 in the > normal cases. > > Values of bytes_read: > haproxy-1.8.30: 4864 > haproxy-2.0.22: 4837 (Also 2.3.X) > haproxy-2.4.0 : 4832 > > I don't think the difference of bytes_read is > related to the shorter html issue and the > HTTP 408 issue, I just noticed so report it. > > For now, I've ran TestA,B,C once. > I am planning to do 2 more tests on each case. > > >> I also tried haproxy-2.0.22 and I didn't find > >> messages about shorter htmls but the number of > >> log messages is smaller than the number of HTTP > >> accesses. > > > >This should definitely not happen, but it obviously depends > >where they are counted. > > > >For example some aborted idempotent requests between haproxy > >and the server on a reused connection could lead to a silent > >close to let the client try again. > > > >In this case it is guaranteed by the compliance with the > >HTTP protocol that the server has not done anything that > >cannot be retried, and all haproxy can see there is a > >failure to process (while in fact it could just be caused > >by an abort in
Re: Maybe stupid question but, I don't see a fetch method for %rt => StreamID
On 01.06.21 14:23, Tim Düsterhus wrote: Aleks, On 6/1/21 10:30 AM, Aleksandar Lazic wrote: This phrasing is understandable to me, but now I'm wondering if this is the best solution. Maybe the already existing user-configurable unique request ID should instead be sent to the SPOE and then logged? https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#7.3.6-unique-id The request_counter (%rt) you mentioned could be embedded into this unique-id. Well this uniqe-id is not send as Stream ID to SPOA receiver, due to this fact can't you debug which stream is the troubled one. Yes, that's why I suggested that the SPOE is extended to also include this specific ID somewhere (just) for logging purposes. Yep. Any opinion from the other community Members? Best regards Tim Düsterhus
Re: Maybe stupid question but, I don't see a fetch method for %rt => StreamID
Aleks, On 6/1/21 10:30 AM, Aleksandar Lazic wrote: This phrasing is understandable to me, but now I'm wondering if this is the best solution. Maybe the already existing user-configurable unique request ID should instead be sent to the SPOE and then logged? https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#7.3.6-unique-id The request_counter (%rt) you mentioned could be embedded into this unique-id. Well this uniqe-id is not send as Stream ID to SPOA receiver, due to this fact can't you debug which stream is the troubled one. Yes, that's why I suggested that the SPOE is extended to also include this specific ID somewhere (just) for logging purposes. Best regards Tim Düsterhus
Re: Maybe stupid question but, I don't see a fetch method for %rt => StreamID
Tim, Jun 1, 2021 9:50:17 AM Tim Düsterhus : > Aleks, > > On 6/1/21 1:03 AM, Aleksandar Lazic wrote: srv_conn([/]) : integer Returns an integer value corresponding to the number of currently established connections on the designated server, possibly including the connection being @@ -17514,6 +17509,9 @@ stopping : boolean str() : string Returns a string. +stream_uniq_id : integer + Returns the uniq stream id. + >>> >>> This explanation is not useful to the reader (even I don't understand it). >> […] >> This is shown on the SPOE log line as sid and therefore I think it should be >> possible to get the same ID also within HAProxy as fetch method. >> ``` >> SPOE: [agent-on-http-req] sid=88 st=0 >> 0/0/0/0/0 1/1 0/0 10/33 >> ``` >> […] >> ``` >> This fetch method returns the internal Stream ID, if a stream is available. >> The >> internal Stream ID is used in several places in HAProxy to trace the Stream >> inside HAProxy. It is also uses in SPOE as "sid" value. >> ``` >> > > This phrasing is understandable to me, but now I'm wondering if this is the > best solution. Maybe the already existing user-configurable unique request ID > should instead be sent to the SPOE and then logged? > > https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#7.3.6-unique-id > > The request_counter (%rt) you mentioned could be embedded into this unique-id. Well this uniqe-id is not send as Stream ID to SPOA receiver, due to this fact can't you debug which stream is the troubled one. > Best regards > Tim Düsterhus Regards Alex
Re: Maybe stupid question but, I don't see a fetch method for %rt => StreamID
Aleks, On 6/1/21 1:03 AM, Aleksandar Lazic wrote: srv_conn([/]) : integer Returns an integer value corresponding to the number of currently established connections on the designated server, possibly including the connection being @@ -17514,6 +17509,9 @@ stopping : boolean str() : string Returns a string. +stream_uniq_id : integer + Returns the uniq stream id. + This explanation is not useful to the reader (even I don't understand it). […] This is shown on the SPOE log line as sid and therefore I think it should be possible to get the same ID also within HAProxy as fetch method. ``` SPOE: [agent-on-http-req] sid=88 st=0 0/0/0/0/0 1/1 0/0 10/33 ``` […] ``` This fetch method returns the internal Stream ID, if a stream is available. The internal Stream ID is used in several places in HAProxy to trace the Stream inside HAProxy. It is also uses in SPOE as "sid" value. ``` This phrasing is understandable to me, but now I'm wondering if this is the best solution. Maybe the already existing user-configurable unique request ID should instead be sent to the SPOE and then logged? https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#7.3.6-unique-id The request_counter (%rt) you mentioned could be embedded into this unique-id. Best regards Tim Düsterhus
