Load-testing a new origin stack by sending duplicating HTTP traffic to it

Follow
rtyley

I’d like to load-test a new origin stack, by duplicating all HTTP GET traffic sent to the old-origin stack.

At this point, ideally, the request to the new stack would be fire-and-forget - generate the traffic, forwarding auth cookies, but don’t wait for the response. The old origin stack would still be the one returning the response to the user.

Is it possible to do this with Fastly VCL?!

0

Comments

3 comments

Sort by Date Votes
  • Jonathan Dade

    One thing that might make this a little better for the end user, would be to set an ultra low time to first byte timeout on the origin you want to smoke test. That way Fastly can fail quickly, restart and go to the old origin and send the data on more quickly. This is an even better idea if the response and its data is not wanted from the smoke test.

    The details of how to set the timeout are at https://docs.fastly.com/guides/debugging/changing-connection-timeouts-to-your-origin

    0
    Permalink
  • rtyley

    Thanks for your help with this - with your assistance I was able to come up with VCL that looked like this:

    https://fiddle.fastlydemo.net/fiddle/6d80110f

    ...the one thing I didn't understand was why return (pass); seems to be necessary - ideally, I would like both my backends to be getting the same quantity of requests, but returning pass on the TEST branch means that my TEST backend will receive requests for cached static assets that my PROD backend probably won't...? I tried removing the return (pass); ... but then no traffic was directed to my TEST backend :frowning:

    In any case, this is probably good enough for me to be getting on with! Thanks again!

    0
    Permalink
  • Andrew Betts

    If you remove the return(pass) then you are not terminating the recv function, and you will fall through to code that will set the backend to the default one. You can fix this by returning explictly but using return(lookup) instead of return(pass).

    If you do this, then your test backend's content will be in cache. Since the backend is not part of the cache key, we'll match both test and prod content on the lookup. That's why I thought it was easier not to cache test. But you're right, and if you want the behaviour to be similar, you'll need to add a request header to record which backend you are targeting:

    set req.http.Backend-Mode = "test";

    And then add a Vary header on the response, either from the backend, or in fetch:

    set besp.http.Vary = "Backend-Mode";

    0
    Permalink

Please sign in to leave a comment.

New post