Re: [OPINIONS DESIRED] (was Re: [PATCH] BUG/MINOR: Fix typo in `TotalSplicedBytesOut` field name)
On Sun, Apr 23, 2023 at 02:25:06PM +0200, Lukas Tribus wrote: > On Sun, 23 Apr 2023 at 13:08, Willy Tarreau wrote: > > > > On Sun, Apr 23, 2023 at 12:39:25PM +0200, Tim Düsterhus, WoltLab GmbH wrote: > > > Willy, > > > > > > On 3/27/23 20:25, Willy Tarreau wrote: > > > > OK, let's see what other users and participants think about it. If I get > > > > at least one "please don't change it" I'll abide, otherwise it may make > > > > sense to fix it before it ossifies and annoys some future users. > > > > > > > > Anyone has any opinion here ? > > > > > > Wanted to bump this thread to make sure it is resolved one way or another > > > before the release. > > > > Ah thanks, I remembered there was something pending but didn't remember > > what. > > Yeah I think we should just fix it since nobody objected. I'll deal with > > that > > next week (I did too much of haproxy for this week-end). > > I agree that we should fix this, considering the possible breakage is > pretty unlikely and very much non fatal. Thank you Lukas, Willy
Re: [OPINIONS DESIRED] (was Re: [PATCH] BUG/MINOR: Fix typo in `TotalSplicedBytesOut` field name)
On Sun, 23 Apr 2023 at 13:08, Willy Tarreau wrote: > > On Sun, Apr 23, 2023 at 12:39:25PM +0200, Tim Düsterhus, WoltLab GmbH wrote: > > Willy, > > > > On 3/27/23 20:25, Willy Tarreau wrote: > > > OK, let's see what other users and participants think about it. If I get > > > at least one "please don't change it" I'll abide, otherwise it may make > > > sense to fix it before it ossifies and annoys some future users. > > > > > > Anyone has any opinion here ? > > > > Wanted to bump this thread to make sure it is resolved one way or another > > before the release. > > Ah thanks, I remembered there was something pending but didn't remember what. > Yeah I think we should just fix it since nobody objected. I'll deal with that > next week (I did too much of haproxy for this week-end). I agree that we should fix this, considering the possible breakage is pretty unlikely and very much non fatal. Lukas
Re: [OPINIONS DESIRED] (was Re: [PATCH] BUG/MINOR: Fix typo in `TotalSplicedBytesOut` field name)
On Sun, Apr 23, 2023 at 12:39:25PM +0200, Tim Düsterhus, WoltLab GmbH wrote: > Willy, > > On 3/27/23 20:25, Willy Tarreau wrote: > > OK, let's see what other users and participants think about it. If I get > > at least one "please don't change it" I'll abide, otherwise it may make > > sense to fix it before it ossifies and annoys some future users. > > > > Anyone has any opinion here ? > > Wanted to bump this thread to make sure it is resolved one way or another > before the release. Ah thanks, I remembered there was something pending but didn't remember what. Yeah I think we should just fix it since nobody objected. I'll deal with that next week (I did too much of haproxy for this week-end). Thanks, Willy
Re: [OPINIONS DESIRED] (was Re: [PATCH] BUG/MINOR: Fix typo in `TotalSplicedBytesOut` field name)
Willy, On 3/27/23 20:25, Willy Tarreau wrote: OK, let's see what other users and participants think about it. If I get at least one "please don't change it" I'll abide, otherwise it may make sense to fix it before it ossifies and annoys some future users. Anyone has any opinion here ? Wanted to bump this thread to make sure it is resolved one way or another before the release. Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 duester...@woltlab.com www.woltlab.com Managing director: Marcel Werk AG Potsdam HRB 26795 P
[ANNOUNCE] haproxy-2.8-dev8
Hi, HAProxy 2.8-dev8 was released on 2023/04/23. It added 199 new commits after version 2.8-dev7. We're reaching the end of the planned sensitive changes and that's great, so I'm addressing my thanks to all those who went through the effort of polishing and testing their code before the last minute. We'll now engage in a stabilization period with a bit more serenity. Once we put the 49 bug fixes aside, among the visible changes in this release are the following: - Lua: the execution timeout was addressed. It did not always work for sample fetches for example, so that infinite loops were still possible. The reason was that it was relying on the internal timer that doesn't make any progress in this case, so infinite loops in sample fetches were still able to trigger the watchgod. Now a monotonic time is periodically retrieved to make sure the task is still allowed to run, otherwise it ends on failure. The maximum delay for this is currently set to one second (which is already huge but matches previous usages) and is configurable via tune.lua.burst-timeout. In addition to all this, some minor improvements to the server events API to pass the proxy's ID and a few elements needed to make the API more durable and extensible were merged. It now sounds like it should be easy enough to write action scripts in Lua that react to server up/down/add/del conditions. - channels/stream connectors: the remaining harmless changes were merged so as to clarify the internal API. The SC_FL_SHUTR flag that was ambigous since it could both indicate a close from the bottom layers or an abort from the upper ones was now split in two that are both tested. For 2.9 we'll audit their usage to figure which ones to keep at each place, but at least having them in good shape now will make troubleshooting much easier and ease backporting fixes in the future. It's interesting to note that the purpose of this refactoring was to make the internal API more logical and clearer, and that the changes needed to get there allowed us to spot several long-standing bugs, and that it already happened recently that a few loops/timeout bugs that affected 2.7 and older did not affect 2.8 anymore. Keeping fingers crossed! - QUIC: there was still a limitation with the way the incoming connection load balancing was handled, with the lowest bits of the connection ID serving to identify the thread ID. It was good enough but did not allow to properly redistribute the load to available threads. In order to address this limitation, QUIC connections now learned to migrate between threads after their handshake, so that they effectively work exactly like TCP sockets and file descriptors. As such they are now assigned to a thread upon accept() using the same mechanism that was already available for TCP connections. This results in a smoother and more controllable load distribution. And the thread ID is no longer derived directly from the connection ID but is located on the connection element itself, so that there's no longer the risk that poorly written clients cause an imbalance of the threads. Aside this, traces and debugging were improved, as usual. There is still one rare bug that Tristan is facing, that I hope will be found and fixed next week. Reaching such difficult bugs is a really good indication that the stack is getting more mature now. - "bind" lines are now fully compatible with thread groups and now support more than 64 threads. A new "shards" setting, "by-group" allows to create a new listener for each thread-group instead of having a single one for the whole process or one per thread. For sockets families (or OSes) that do not support sharding, a transparent fallback is performed which will simply dup() the existing socket so that threads from multiple groups can listen to the same socket. This also allowed to remove the hard-coded restriction to group 1 for the stats sockets, and means that when using more than one shard on a unix socket, we won't be seeing the last thread take all the traffic after having removed and replaced the predecessor's socket on the file system. Finally it was found that using the "by-group" shard setting was the best compromise in general: when running with a single group, it doesn't change anything, and when running with several groups, it will as much as possible try to create several sockets with the exact same number of file descriptors. I.e. it never costs more FDs than the default setting while significantly reducing the kernel-side locking. A test on a 24-core AMD EPYC 74F3 showed that the performance simply doubled from 112k to 214k conn/s by reducing kernel locking overhead from 71% to 55%. So that convinced me to enable "by-group" as the new default *right now*. However, the change of default value is a single commit, so if it were found to cause any problem, it's trivial to revert.
Re: [PATCH] CI: bump cirrus-ci freebsd to 13-2
Hi Ilya, On Sat, Apr 22, 2023 at 08:29:38PM +0200, ??? wrote: > Hello > > minor freebsd cirrus-ci image update (...) all 4 patches applied, thank you! Willy
Direct flight with hot rates to LHR/CDG/AMS ...
Dear Haproxy,good day! Hi there! we have space on hand with special rates . First come first served! More details you need ,welcome to contact with me. AirlineDepartureDestinationRATIO100kgs300kgs500kgs1000kgsRouting CA/CZPVGAMS1:300/$2.25//Direct 1:500/$2.08// 2CPVGCDGGeneral$3.43$3.43$3.43$3.43Direct MU MU7551/05:55-10:17 MU551 /13:00-17:17PVGLHRGeneral$3.28$3.28$3.28$3.28Direct 1:300/$2.85// 1:500/$2.55// 1:800/$2.38// 1:120//$3.15$3.15 1:100//$2.98$2.98 Remark: -General cargo should accordingto 1cbm=167kgs. -Chemical goods and pallet goods check case by case. -Please kindly confirm the rates before you make bookings. If you do not desire to receive future emails from us then click unsubscribe we will remove you from our mailing list. Best Regards Alin Tang | Oversea manager Cell/WA: +86 17675410807 Skype: +86 13726806624 Email: alin_t...@ufxscm.com Web: www.unifelix.com NVOCC:MOC-NV11485 SHENZHEN UNIFELIX INT'L LOGISTICS CO.,LTD
