Re: Re: CI caching improvement

On Mon, Mar 21, 2022 at 04:19:38PM +0500, Илья Шипицин wrote: > > I think we can adjust build-ssl.sh script to download tagged quictls (and > cache it in the way we do cache openssl itself) > Tags · quictls/openssl (github.com) > > Unfortunately that

Re: CI caching improvement

configuration in the repository. And typescript is not a language we would want to depend on if we need to debug it for example. Okay, that's fair. Giving that github is offering the job restart feature, we could skip the VTest caching, since it's a little bit ugly. Only the quictls cache need

Re: CI caching improvement

пт, 18 мар. 2022 г. в 15:32, William Lallemand : > On Wed, Mar 16, 2022 at 09:31:56AM +0100, Tim Düsterhus wrote: > > Willy, > > > > On 3/8/22 20:43, Tim Düsterhus wrote: > > >> Yes my point was about VTest. However you made me think about a very > good >

Re: CI caching improvement

On Wed, Mar 16, 2022 at 09:31:56AM +0100, Tim Düsterhus wrote: > Willy, > > On 3/8/22 20:43, Tim Düsterhus wrote: > >> Yes my point was about VTest. However you made me think about a very good > >> reason for caching haproxy builds as well :-) Very commonly, som

Re: CI caching improvement

Willy, On 3/8/22 20:43, Tim Düsterhus wrote: Yes my point was about VTest. However you made me think about a very good reason for caching haproxy builds as well :-) Very commonly, some VTest randomly fails. Timing etc are involved. And at the moment, it's impossible to restart the tests

Re: CI caching improvement

Let me make a competing proposal that: > > 1. Keeps the complexity out of the GitHub workflow configuration in > haproxy/haproxy. > 2. Still allows VTest caching. > > For my https://github.com/TimWolla/haproxy-auth-request repository I > have created a reusable GitHub Action to perform t

Re: [EXTERNAL] Re: CI caching improvement

/5ce1299c643543c9b17b4124b299feb3caf63d9e/.github/workflows/musl.yml#L19-L20 Your patch proposal doesn't adjust that, but with the dedicated action it could automatically benefit from caching or any other improvements we make to the VTest installation without needing to touch all the .yml files

Re: [EXTERNAL] Re: CI caching improvement

William, On 3/8/22 20:54, William Lallemand wrote: Honestly I'm confused, it is overcomplicated in my opinion :( I don't really see the benefits in creating a whole new repository instead of the few lines in the yaml file. I believe that having a non-trivial amount of logic in a YAML file

Re: [EXTERNAL] Re: CI caching improvement

On Tue, Mar 08, 2022 at 08:05:31PM +0100, Tim Düsterhus wrote: > > Let me make a competing proposal that: > > 1. Keeps the complexity out of the GitHub workflow configuration in > haproxy/haproxy. > 2. Still allows VTest caching. > > For my https://github.com/TimWo

Re: CI caching improvement

Willy, On 3/8/22 20:11, Willy Tarreau wrote: Yes my point was about VTest. However you made me think about a very good reason for caching haproxy builds as well :-) Very commonly, some VTest randomly fails. Timing etc are involved. And at the moment, it's impossible to restart the tests

Re: CI caching improvement

> > This was a reply to "cache the build of HAProxy", so unrelated to VTest. As > the HAProxy build is what we want to test, it's important to always perform > a clean build. Yes my point was about VTest. However you made me think about a very good reason for caching h

Re: CI caching improvement

William, On 3/8/22 16:06, William Lallemand wrote: Let me know if we can improve the attached patch, otherwise I'll merge it. Let me make a competing proposal that: 1. Keeps the complexity out of the GitHub workflow configuration in haproxy/haproxy. 2. Still allows VTest caching. For my

Re: CI caching improvement

On Tue, Mar 08, 2022 at 04:17:00PM +0100, Tim Düsterhus wrote: > William > > On 3/8/22 16:06, William Lallemand wrote: > > Also, I'm wondering if we could also cache the build of HAProxy, you > > could think that weird, but in fact it will help relaunch the tests when > > one is failing, without

Re: CI caching improvement

вт, 8 мар. 2022 г. в 21:13, William Lallemand : > On Tue, Mar 08, 2022 at 08:38:00PM +0500, Илья Шипицин wrote: > > > > I'm fine with swapping "vtest" <--> "haproxy" order. > > > > Ok, I can do that. > > > also, I do not think current patch is ugly, it is acceptable for me (if > we > > agree to

Re: CI caching improvement

On Tue, Mar 08, 2022 at 08:38:00PM +0500, Илья Шипицин wrote: > > I'm fine with swapping "vtest" <--> "haproxy" order. > Ok, I can do that. > also, I do not think current patch is ugly, it is acceptable for me (if we > agree to save 8 sec). Honestly I don't see the value in building the same

Re: CI caching improvement

this case the cost is larger than the benefit. Caching is one of the hard things in computer science :-) Best regards Tim Düsterhus

Re: CI caching improvement

I thought to build "vtest" just once and deliver using artifacts to all jobs. It will save some electricity, also GitHub sometimes throw 429 when we download "vtest" in too many parallel ways. however, it will not speed up, so I postoned that idea (something like that

Re: CI caching improvement

Hi Tim, On Tue, Mar 08, 2022 at 04:17:00PM +0100, Tim Düsterhus wrote: > William > > On 3/8/22 16:06, William Lallemand wrote: > > Also, I'm wondering if we could also cache the build of HAProxy, you > > could think that weird, but in fact it will help relaunch the tests when > > one is failing,

Re: CI caching improvement

Willy, William, On 3/8/22 16:14, Willy Tarreau wrote: Due to this I think we should move the build of vtest after the build of haproxy (and generally, anything that's not needed for the build ought to be moved after). This will at least save whatever can be saved on failed builds. That on the

Re: CI caching improvement

William On 3/8/22 16:06, William Lallemand wrote: Also, I'm wondering if we could also cache the build of HAProxy, you could think that weird, but in fact it will help relaunch the tests when one is failing, without rebuilding the whole thing. Please don't. You always want to run a clean

Re: CI caching improvement

Hi William, On Tue, Mar 08, 2022 at 04:06:45PM +0100, William Lallemand wrote: > Hello, > > The attached patch implements a somehow ugly way to cache the VTest > binary, basically it gets the commit ID by doing a curl of the > master.patch on the github URL. > > It allows to save ~8s per matrix

CI caching improvement

Hello, The attached patch implements a somehow ugly way to cache the VTest binary, basically it gets the commit ID by doing a curl of the master.patch on the github URL. It allows to save ~8s per matrix row, which is around 160s in total. I know there is a small window where the curl and the git

Re: [PATCH] CI: introduce caching for ssl libs (except BoringSSL, QUICTLS)

On Sat, Jan 22, 2022 at 12:07:37AM +0500, ??? wrote: > Hello, > > this patch introduces github actions cache for SSL libs. > hope it will save couple of minutes. Merged, thanks Ilya! Willy

[PATCH] CI: introduce caching for ssl libs (except BoringSSL, QUICTLS)

for SSL libs we have two kinds of SSL libs built - git based and version based. this commit introduces caching for version based SSL libs. --- .github/workflows/vtest.yml | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/.github/workflows/vtest.yml b/.github

Re: [cache] allow caching of OPTIONS request

s *really* happen to a point of being a concern with OPTIONS > requests ? I mean, if OPTIONS represent a small percentage of the traffic > I'd rather not start to hack around the standards and regret in 2 versions > later... > > > It seems it owns its own header for caching: > >

Re: [cache] allow caching of OPTIONS request

epresent a small percentage of the traffic I'd rather not start to hack around the standards and regret in 2 versions later... > It seems it owns its own header for caching: > https://www.w3.org/TR/cors/#access-control-max-age-response-header. > Some description here: https://www.w3.org/

Re: [cache] allow caching of OPTIONS request

t; issues. > > Thanks, > Willy > Hi Willy, The use case is to avoid too many requests hitting an application server for "preflight requests". It seems it owns its own header for caching: https://www.w3.org/TR/cors/#access-control-max-age-response-header. Some description here:

Re: [cache] allow caching of OPTIONS request

Guys, On Wed, Aug 07, 2019 at 02:07:09PM +0200, Baptiste wrote: > Hi Vincent, > > HAProxy does not follow the max-age in the Cache-Control anyway. I know it's a bit late but I'm having an objection against this change. The reason is simple, OPTIONS is explicitly documented as being

Re: [cache] allow caching of OPTIONS request

On Wed, Aug 07, 2019 at 03:20:34PM +0200, Baptiste wrote: > On Wed, Aug 7, 2019 at 3:18 PM William Lallemand > wrote: > > > On Wed, Aug 07, 2019 at 12:38:05PM +0200, Baptiste wrote: > > > Hi there, > > > > > > Please find in attachement a co

Re: [cache] allow caching of OPTIONS request

On Wed, Aug 7, 2019 at 3:18 PM William Lallemand wrote: > On Wed, Aug 07, 2019 at 12:38:05PM +0200, Baptiste wrote: > > Hi there, > > > > Please find in attachement a couple of patches to allow caching responses > > to OPTIONS requests, used in CORS pattern. &

Re: [cache] allow caching of OPTIONS request

On Wed, Aug 07, 2019 at 12:38:05PM +0200, Baptiste wrote: > Hi there, > > Please find in attachement a couple of patches to allow caching responses > to OPTIONS requests, used in CORS pattern. > In modern API where CORS is applied, there may be a bunch of OPTIONS > requests co

Re: [cache] allow caching of OPTIONS request

You see, the time the object will be cached by HAProxy is defined in your cache storage bucket. Baptiste On Wed, Aug 7, 2019 at 1:47 PM GALLISSOT VINCENT wrote: > Hi there, > > > May I add that, in the CORS implementation, there is a specific header > used for the caching du

RE: [cache] allow caching of OPTIONS request

Hi there, May I add that, in the CORS implementation, there is a specific header used for the caching duration: Access-Control-Max-Age This header is supported by most of browsers and its specification is available : https://fetch.spec.whatwg.org/#http-access-control-max-age One would think

[cache] allow caching of OPTIONS request

Hi there, Please find in attachement a couple of patches to allow caching responses to OPTIONS requests, used in CORS pattern. In modern API where CORS is applied, there may be a bunch of OPTIONS requests coming in to the API servers, so caching these responses will improve API response time

Re: issue with small object caching

Le 04/07/2019 à 16:54, Senthil Naidu a écrit : Hi, I there any fix that can be applied for small object caching to work with Firefox and chrome too, With Internet Explorer I am able to hit the cache properly. As mentioned in my earlier , I can see that firefox is sending header Cache

RE: issue with small object caching

Hi, I there any fix that can be applied for small object caching to work with Firefox and chrome too, With Internet Explorer I am able to hit the cache properly. As mentioned in my earlier , I can see that firefox is sending header Cache-Control: no-cache and Pragma: no-cache , While IE

RE: issue with small object caching

with small object caching Senthil, Am 03.07.19 um 13:20 schrieb Senthil Naidu: > From Firefox > *snip* > Cache-Control: no-cache This is the issue. Firefox requests that an intermediate proxy does not cache (or rather: that it re-validates its cached copy). Best regards Tim Düsterhus

Re: issue with small object caching

Senthil, Am 03.07.19 um 13:20 schrieb Senthil Naidu: > From Firefox > *snip* > Cache-Control: no-cache This is the issue. Firefox requests that an intermediate proxy does not cache (or rather: that it re-validates its cached copy). Best regards Tim Düsterhus

RE: issue with small object caching

:56:46 GMT If-None-Match "119-58ba89226aecd" Connection Keep-Alive Regards Senthil -Original Message- From: Christopher Faulet [mailto:cfau...@haproxy.com] Sent: 21 June 2019 23:10 To: Senthil Naidu; haproxy@formilux.org Subject: Re: issue with small object caching Le 21/06/2

Re: issue with small object caching

Le 21/06/2019 à 17:00, Senthil Naidu a écrit : Hi, I am using haproxy 2.0.0 , when I am using IE I can see in the logs the first request is reaching the real server and when I do the refresh all subsequent request is hitting the cache of haproxy, when I use firefox/crome all the request are

RE: issue with small object caching

e [TRACE] trace Regards Senthil -Original Message- From: Christopher Faulet [mailto:cfau...@haproxy.com] Sent: 21 June 2019 20:23 To: Senthil Naidu; haproxy@formilux.org Subject: Re: issue with small object caching Le 21/06/2019 à 16:39, Senthil Naidu a écrit : > I am testing the smal

Re: issue with small object caching

Le 21/06/2019 à 16:39, Senthil Naidu a écrit : I am testing the small object caching feature , when I am trying to browse the site behind haproxy using IE the cache is working but when I try the same from firefox or crome the caching functionality is not working. Has anybody faced this issue

issue with small object caching

Hi, I am testing the small object caching feature , when I am trying to browse the site behind haproxy using IE the cache is working but when I try the same from firefox or crome the caching functionality is not working. Has anybody faced this issue. Regards Senthil Senthil Naidu General

Re: Question on Caching.

Hi Willy, I think what we are looking for is some kind of small cache to accelerate the load times of a single page; this is particularly for things such as WordPress where page load times can be slow. I imagine it being set to cache the homepage only, fairly small(just a few K) and I guess it

Re: Question on Caching.

Hi Andrew, On Mon, Apr 30, 2018 at 10:08:11AM +0100, Andrew Smalley wrote: > Hi Willy > > Thank you for you for your detailed reply explaining why you think only the > favicon cache is sensible and that a full-blown cache within Haproxy > is not the best of ideas although interesting. > > I

Re: Question on Caching.

gt;> Hello Haproxy mailing list >> >> I have been looking at caching technology and have found this >> >> https://github.com/jiangwenyuan/nuster/ >> >> It claims to be a v1.7 / v1.8 branch fully compatible with haproxy >> and indeed based on haproxy with the

Re: Question on Caching.

Hi Andrew, On Thu, Apr 26, 2018 at 10:06:00PM +0100, Andrew Smalley wrote: > Hello Haproxy mailing list > > I have been looking at caching technology and have found this > > https://github.com/jiangwenyuan/nuster/ > > It claims to be a v1.7 / v1.8 branch fully co

Question on Caching.

Hello Haproxy mailing list I have been looking at caching technology and have found this https://github.com/jiangwenyuan/nuster/ It claims to be a v1.7 / v1.8 branch fully compatible with haproxy and indeed based on haproxy with the added capibility of having a really fast cache as described

Re: HAProxy 1.8.3 SSL caching regression

On Thu, Jan 04, 2018 at 02:14:41PM -0500, Jeffrey J. Persch wrote: > Hi William, > > Verified. > > Thanks for the quick fix, Great, patch now merged. Thanks! Willy

Re: HAProxy 1.8.3 SSL caching regression

Hi William, Verified. Thanks for the quick fix, Jeffrey J. Persch On Wed, Jan 3, 2018 at 2:02 PM, Jeffrey J. Persch wrote: > Hi William, > > The test case now works. I will do load testing with the patch today. > > Thanks, > Jeffrey J. Persch > > On Wed, Jan 3, 2018 at

Re: HAProxy 1.8.3 SSL caching regression

Hi William, The test case now works. I will do load testing with the patch today. Thanks, Jeffrey J. Persch On Wed, Jan 3, 2018 at 1:25 PM, William Lallemand wrote: > On Wed, Jan 03, 2018 at 06:41:01PM +0100, William Lallemand wrote: > > I'm able to reproduce the

Re: HAProxy 1.8.3 SSL caching regression

On Wed, Jan 03, 2018 at 06:41:01PM +0100, William Lallemand wrote: > I'm able to reproduce the problem thanks to your detailed example, it looks > like a regression in the code. > > I will check the code to see what's going on. I found the issue, would you mind trying the attached patch?

Re: HAProxy 1.8.3 SSL caching regression

On Wed, Jan 03, 2018 at 12:04:50PM -0500, Jeffrey J. Persch wrote: > Greetings, > Hi Jeffrey, > We have been load testing 1.8.3 and noticed SSL caching was broken in 1.8 > during the shctx refactoring. > > New SSL connections will cache up until tune.ssl.cachesize, the

HAProxy 1.8.3 SSL caching regression

Greetings, We have been load testing 1.8.3 and noticed SSL caching was broken in 1.8 during the shctx refactoring. New SSL connections will cache up until tune.ssl.cachesize, then no connections will ever be cached again. In haproxy 1.7 and before, the SSL cache works correctly as a LRU cache

Re: dns resoluton and caching

On Wed, Jul 2, 2014 at 5:03 AM, Yumerefendi, Aydan aydan.yumerefe...@inin.com wrote: We are using haproxy to route traffic to several AWS services that are behind an ELB and noticed the following behavior: - haproxy resolves the ELB address at startup and routes traffic just fine (not sure

Re: dns resoluton and caching

Thank you Baptiste. I think it will be very useful feature to add for any service that uses dynamic dns of some sort. Thanks for your reply, Best, ‹aydan On 7/3/14, 4:41 PM, Baptiste bed...@gmail.com wrote: On Wed, Jul 2, 2014 at 5:03 AM, Yumerefendi, Aydan aydan.yumerefe...@inin.com wrote:

dns resoluton and caching

We are using haproxy to route traffic to several AWS services that are behind an ELB and noticed the following behavior: - haproxy resolves the ELB address at startup and routes traffic just fine (not sure if haproxy uses the first IP or all resolved IPs and round-robins between them, though)

Re: problem with sort of caching of use_backend with socket.io and apache

was this: http://serverfault.com/questions/451690/haproxy-is-caching-the-forwarding and i got it working, but for some reason, after the authentication is made and the some commands are sent, the connection is dropped and a new connection is made as you can see here: info - handshake authorized

Re: problem with sort of caching of use_backend with socket.io and apache

Thanks willy, i solved it as soon you answer me but i'm still dealing to the configuration to make it work as i need: my last question was this: http://serverfault.com/questions/451690/haproxy-is-caching-the-forwarding and i got it working, but for some reason, after the authentication is made

Re: problem with sort of caching of use_backend with socket.io and apache

shadow.of.sou...@gmail.com wrote: Thanks willy, i solved it as soon you answer me but i'm still dealing to the configuration to make it work as i need: my last question was this: http://serverfault.com/questions/451690/haproxy-is-caching-the-forwarding and i got it working, but for some reason

Re: problem with sort of caching of use_backend with socket.io and apache

/index.html) most of the times, is still redirect to socket.io. after refreshing a few time, it finally loads index.html, but then, doesn't load the socket.io.js file inserted in the file (why it redirect to the apache server, and not the node.js app). so as i said, it sort of caching the request. i

Re: Caching

- maybe just when running -c. On 9/19/11 5:46 AM, Christophe Rahier wrote: I don't use Apache but IIS. I tried to disable caching on IIS but the problem is still there. There's no proxy, all requests are sent from pfSense. Christophe Le 19/09/11 13:45, « Baptiste »bed...@gmail.com a écrit

Caching

Hi, Is there a caching system at HAProxy? In fact, we find that when we put online new files (CSS, for example) that they are not addressed directly, it usually takes about ten minutes. Thank you in advance for your help. Christophe

Re: Caching

a écrit : hi Christophe, HAProxy is *only* a reverse proxy. No caching functions in it. Have you tried to browse your backend servers directly? Can it be related to your browser's cache? cheers On Mon, Sep 19, 2011 at 1:39 PM, Christophe Rahier christo...@qualifio.com wrote: Hi

Re: Caching

the same problem. To be sure, I tried with an other browser and the problem is the same. When I call my page locally from the server, the result is OK. Christophe Le 19/09/11 13:45, « Baptiste » bed...@gmail.com a écrit : hi Christophe, HAProxy is *only* a reverse proxy. No caching functions

Re: Caching

Rahier wrote: I don't use Apache but IIS. I tried to disable caching on IIS but the problem is still there. There's no proxy, all requests are sent from pfSense. Christophe Le 19/09/11 13:45, « Baptiste »bed...@gmail.com a écrit : hi Christophe, HAProxy is *only* a reverse proxy