Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Varnish: Dev

Varnish 3.1 becoming 4.0 instead (?)

 

 

Varnish dev RSS feed   Index | Next | Previous | View Threaded


phk at phk

Dec 5, 2011, 4:35 AM

Post #1 of 8 (481 views)
Permalink
Varnish 3.1 becoming 4.0 instead (?)

I've been mildly disciplined for not keeping the -dev mailing list
in the loop, and that's perfectly true: I have not.

I have no other excuse than I felt like I was talking into an empty
room, but I am assured now that the room is no longer empty so I
try to make sure that IRC doesn't become CABAL and use -dev more.

So a bit of catch-up is probably in order:

The big ticket item right now is streaming. Martin is working
furiously on that, and I'm trying to slow him down enough to make
sure that streaming becomes an integral part and not some bolt-on
feature.

After streaming backend-If-Modified-Since (Geoffs patches) are next
in the line.

The thinking until now was that we would try to release Varnish 3.1
with both of these as default-off features, and make them default-on
feautures in 4.0

However, as we work the code a couple of details and one 500 pound
gorilla has materialized, and I am now leaning towards skipping the
3.1 step and going directly for 4.0.

The gorilla is vcl_error{} which I am increasingly convinced was a
bad idea to begin with.

The only reason why we added vcl_error{} was to avoid every vcl_fetch{}
having to have to start with:

if (beresp.status == 503) {
/* do something */
}

But with streaming, you can only detect failures to fetch the
headers, once you have started to receive the body, you have committed
to a reply to the client, and it cannot be uncommitted.

That makes vcl_error{} basically pointless with streaming on.

The way I think it will look in 4.0 is that failures to fetch
the reponse-headers from the backend, will be reported as
a 503 reponse in vcl_fetch{}, from where a restart will
be possible.

If you are streaming, and the body fails, you won't hear about it
at VCL level, there will be nothing we can do about it.

If you are not streaming, and the body fetch fails, you will
see a 503 in vcl_deliver{}.

That leaves the other part of what we use vcl_error for today:
synthetic responses.

I thought I had a good idea for "synthetic responses from
everywhere" last year, but it transpired to be a tar-pit
of special-casing, so I abandonned that idea.

My thinking now is that functionality can and should move to
vcl_deliver{} where it rightfully belongs, with all other responses
to the client, and doing it (only) there enables us to provide a
much more sane and usable access to the response body.

Some sort of VCL syntax for "go to vcl_reponse and deliver
response=X" will be needed, and I think it will simply be

return (response(812));

which leaves the responsibility for synthesizing headers
and body entirely to vcl_deliver{}.

So if we do streaming in 3.1 as planned, I'll have to find some way
to hack up vcl_error{} to still work as we are used to, and I'm
increasingly finding that more trouble than it is worth and leaning
more and more towards the 4.0 option where we can do away with
vcl_error{} and avoid all the complications.

This email represents your chance to come up with really good
arguments for why we should not simply skip 3.1

It is also your chance to remind us what other VCL syntax/semantics
affecting changes should do/have promised for 4.0.

In either case, we are probably looking at a alpha-release with
streaming in jan/early-feb, but you will be able to play with
-trunk before that.

At a more detailed level, Martin and I are trying to pave the road
to streaming by shuffling things around, and the cheat-sheat on
that looks like this:

Everything related to backend fetch goes into busyobj.
including htc & (new) workspace for bereq/beresp

The new workspace means that we will have three workspaces
in total:
sess->ws holds req.*
ws->ws holds resp.*
busyobj->ws holds bereq.* and beresp.*

Eventually sess->ws should only exist when sessions do not
wait, and then worker->ws can then be eliminated and sess->ws
contain both req.* and resp.* (Hopefully in 4.0)

Client->body is be dealt with (FetchHdr() before fetcher-thread
is spawned.

Busyobj must be refcounted, since client->deliver may be much
slower than worker->fetch.

Busyobj will be malloced, and two strategies for caching free
ones will be $param selectable:

Either we cache a single free busyobj (in a static variable,
under lock), which will work well for high hit-rates.

Or we cache one per worker thread in wrk->nbusyobj, without
locking, which will be good for low hit-rates.

Stats counters will allow us to monitor the situation and
improve this policy.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk [at] FreeBSD | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

_______________________________________________
varnish-dev mailing list
varnish-dev [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev


tfheen at varnish-software

Dec 8, 2011, 4:03 AM

Post #2 of 8 (476 views)
Permalink
Re: Varnish 3.1 becoming 4.0 instead (?) [In reply to]

]] Poul-Henning Kamp

Hi,

> The only reason why we added vcl_error{} was to avoid every vcl_fetch{}
> having to have to start with:
>
> if (beresp.status == 503) {
> /* do something */
> }
>
> But with streaming, you can only detect failures to fetch the
> headers, once you have started to receive the body, you have committed
> to a reply to the client, and it cannot be uncommitted.
>
> That makes vcl_error{} basically pointless with streaming on.

I'd call it «less useful», not useless, since quite often the problem is
that your backend is overloaded and not able to give us an answer in a
reasonable amount of time. Still something we should see if we can fix,
though.

> The way I think it will look in 4.0 is that failures to fetch
> the reponse-headers from the backend, will be reported as
> a 503 reponse in vcl_fetch{}, from where a restart will
> be possible.

As long as you can detect whether a 503 is internally generated or not,
that's fine.

> If you are streaming, and the body fails, you won't hear about it
> at VCL level, there will be nothing we can do about it.

Reasonable.


[...]

> So if we do streaming in 3.1 as planned, I'll have to find some way
> to hack up vcl_error{} to still work as we are used to, and I'm
> increasingly finding that more trouble than it is worth and leaning
> more and more towards the 4.0 option where we can do away with
> vcl_error{} and avoid all the complications.

I don't think the 3.1 vs 4.0 naming is particularly important, but I
know you feel much stronger about that than I do.

> The new workspace means that we will have three workspaces
> in total:
> sess->ws holds req.*
> ws->ws holds resp.*
> busyobj->ws holds bereq.* and beresp.*

Does this mean the lifetime of the workspaces are the same as the
lifetime of those objects too?

> Eventually sess->ws should only exist when sessions do not
> wait, and then worker->ws can then be eliminated and sess->ws
> contain both req.* and resp.* (Hopefully in 4.0)

Won't sess->ws always exist (and probably be where most vmods will store
their data) or do you actually mean what you wrote?

Cheers,
--
Tollef Fog Heen
Technical lead, Varnish Software
t: +47 21 98 92 64

_______________________________________________
varnish-dev mailing list
varnish-dev [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev


phk at phk

Dec 9, 2011, 12:48 AM

Post #3 of 8 (467 views)
Permalink
Re: Varnish 3.1 becoming 4.0 instead (?) [In reply to]

In message <87ty5bmfsv.fsf [at] qurzaw>, Tollef Fog Heen writes
:

>As long as you can detect whether a 503 is internally generated or not,
>that's fine.

That is an interesting idea, but why would that be important ?

>I don't think the 3.1 vs 4.0 naming is particularly important, but I
>know you feel much stronger about that than I do.

I think we owe the users to clearly mark when we muck about with
VCL syntax. If consensus is that 3.1 is sufficient warning, then
fine by me.

>> Eventually sess->ws should only exist when sessions do not
>> wait, and then worker->ws can then be eliminated and sess->ws
>> contain both req.* and resp.* (Hopefully in 4.0)
>
>Won't sess->ws always exist (and probably be where most vmods will store
>their data) or do you actually mean what you wrote?

I usually mean what I write, but I may not have thought it through before
I wrote it :-)

My reasoning for the above is that large sites have very high numbers
of sessions waiting to see if the client will send more requests and
we need to reduce the memory pressure of that.

This is not a trivial change by any means, amongst other things a trivial
implementations opens several DoS vulnerabilities, so unless I get hit
by a really fast inspiratron, this will be somewhere past 4.0

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk [at] FreeBSD | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

_______________________________________________
varnish-dev mailing list
varnish-dev [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev


tfheen at varnish-software

Dec 9, 2011, 5:26 AM

Post #4 of 8 (465 views)
Permalink
Re: Varnish 3.1 becoming 4.0 instead (?) [In reply to]

]] "Poul-Henning Kamp"

> In message <87ty5bmfsv.fsf [at] qurzaw>, Tollef Fog Heen writes
> :
>
> >As long as you can detect whether a 503 is internally generated or not,
> >that's fine.
>
> That is an interesting idea, but why would that be important ?

It's really part of a somewhat larger problem which currently is to
figure out why you ended up in vcl_error. Was it because of a backend
timeout? Backend giving ECONNREFUSED? Something else? We don't know,
and it might be important to know, either because we want to log it or
we want to handle different errors in different ways.

So, if you know where an error comes from, you have more information and
that's useful.

> >I don't think the 3.1 vs 4.0 naming is particularly important, but I
> >know you feel much stronger about that than I do.
>
> I think we owe the users to clearly mark when we muck about with
> VCL syntax. If consensus is that 3.1 is sufficient warning, then
> fine by me.

To the extent historical precedent matters, we did the obj → beresp
change for vcl_fetch in 2.0 → 2.1. In my head, we don't break stuff in
3.0.x (but we can add bits), we can break between 3.0 and 3.1. The
distinction isn't particularly important to me, we are in no risk of
running out of integers.

> >> Eventually sess->ws should only exist when sessions do not
> >> wait, and then worker->ws can then be eliminated and sess->ws
> >> contain both req.* and resp.* (Hopefully in 4.0)
> >
> >Won't sess->ws always exist (and probably be where most vmods will store
> >their data) or do you actually mean what you wrote?
>
> I usually mean what I write, but I may not have thought it through before
> I wrote it :-)
>
> My reasoning for the above is that large sites have very high numbers
> of sessions waiting to see if the client will send more requests and
> we need to reduce the memory pressure of that.

Oh, I think I might have misunderstood what you meant, then. I
understood what you wrote to be that sess->ws would go away when a
client would wait for a backend fetch for instance, and that did not
make any sense at all. (If you go to vcl_hit, you can't use req.* in
vcl_deliver would be one of the fallouts.)

Dropping or resetting sess->ws between each request would be fine with
me.

--
Tollef Fog Heen
Technical lead, Varnish Software
t: +47 21 98 92 64

_______________________________________________
varnish-dev mailing list
varnish-dev [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev


phk at phk

Dec 9, 2011, 8:12 AM

Post #5 of 8 (465 views)
Permalink
Re: Varnish 3.1 becoming 4.0 instead (?) [In reply to]

In message <8762hpc1up.fsf [at] qurzaw>, Tollef Fog Heen writes
:

>> >As long as you can detect whether a 503 is internally generated or not,
>> >that's fine.
>>
>> That is an interesting idea, but why would that be important ?
>
>It's really part of a somewhat larger problem which currently is to
>figure out why you ended up in vcl_error.

Right, yes, that's an old wish too.

So far I have resisted inventing a bunch of internal numbers (7xx?)
because I fear they would leak into the internet, but suggestions
are welcome. It is also not obvious to me how many different values
we would need to communicate.

Suggestions, as always, welcome.

>The distinction isn't particularly important to me, we are in no risk of
>running out of integers.

Tell that to the FreeBSD ports people who saw autocrap shit itself when
FreeBSD went to 10.0 :-)

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk [at] FreeBSD | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

_______________________________________________
varnish-dev mailing list
varnish-dev [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev


tfheen at varnish-software

Dec 15, 2011, 1:47 AM

Post #6 of 8 (449 views)
Permalink
Re: Varnish 3.1 becoming 4.0 instead (?) [In reply to]

]] Poul-Henning Kamp

> In message <8762hpc1up.fsf [at] qurzaw>, Tollef Fog Heen writes
> :
>
> >> >As long as you can detect whether a 503 is internally generated or not,
> >> >that's fine.
> >>
> >> That is an interesting idea, but why would that be important ?
> >
> >It's really part of a somewhat larger problem which currently is to
> >figure out why you ended up in vcl_error.
>
> Right, yes, that's an old wish too.
>
> So far I have resisted inventing a bunch of internal numbers (7xx?)
> because I fear they would leak into the internet, but suggestions
> are welcome. It is also not obvious to me how many different values
> we would need to communicate.

I like strings, and we can use a error.reason or error.code or a similar
variable rather than inventing new status codes that, as you point out,
is likely to leak.

> >The distinction isn't particularly important to me, we are in no risk of
> >running out of integers.
>
> Tell that to the FreeBSD ports people who saw autocrap shit itself when
> FreeBSD went to 10.0 :-)

Ouch. :-)

But now you've fixed it, so we should be good for at least up to 100,
right? ;-)

Cheers,
--
Tollef Fog Heen
Technical lead, Varnish Software
t: +47 21 98 92 64

_______________________________________________
varnish-dev mailing list
varnish-dev [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev


kacperw at online

Dec 15, 2011, 8:06 AM

Post #7 of 8 (451 views)
Permalink
Re: Varnish 3.1 becoming 4.0 instead (?) [In reply to]

On Mon, Dec 5, 2011 at 1:35 PM, Poul-Henning Kamp <phk [at] phk> wrote:
>
> I've been mildly disciplined for not keeping the -dev mailing list
> in the loop, and that's perfectly true: I have not.

tsk tsk

What you are asking here elicits a response in me, and I'm sure in
many others on this list, however it is hard enough to articulate and
that may be why the list is silent on this issue.

[snip .. on streaming..]
> The thinking until now was that we would try to release Varnish 3.1
> with both of these as default-off features, and make them default-on
> feautures in 4.0

Well, there has been quite a lot of VCL breakage in Varnish over the
years, 2.0 -> 2.1 -> 3.0 has not been entirely painless, despite this
I'm pretty sure streaming support has a big thumbs up from most of us,
and the features gained have outweighed other considerations.

> However, as we work the code a couple of details and one 500 pound
> gorilla has materialized
[snip]
> The only reason why we added vcl_error{} was to avoid every vcl_fetch{}
> having to have to start with:
>
> if (beresp.status == 503) {
> /* do something */
> }

> But with streaming, you can only detect failures to fetch the
> headers, once you have started to receive the body, you have committed
> to a reply to the client, and it cannot be uncommitted.

But the reply to the client may fail or hit an exception at any point,
both from the source side of the data (backend timeout) and the sink
side (client timeout), and being able to do something in VCL on these
conditions is gold.

> That makes vcl_error{} basically pointless with streaming on.
[snip]
> The way I think it will look in 4.0 is that failures to fetch
> the reponse-headers from the backend, will be reported as
> a 503 reponse in vcl_fetch{}, from where a restart will
> be possible.
>
> If you are streaming, and the body fails, you won't hear about it
> at VCL level, there will be nothing we can do about it.

> If you are not streaming, and the body fetch fails, you will
> see a 503 in vcl_deliver{}.
>
[snip]
> return (response(812));

This may just be language aesthetics, but this is, how do we say it, fugly.

As far as I can understand the problem it's that the introduction of
streaming makes it real hard to do a callback?

There are some use cases for vcl_error are not being considered here.
vcl_error is not just "deliver $some synthetic" but, and this is the
main kicker, it's an exception mechanism.
Even Tollef's proposed solution of using identifiers instead of status
codes is not ideal. The big advantage of vcl_error is that you can
call it from the rest of the code and also be sure you land there when
an error occurs in the request flow.

> So if we do streaming in 3.1 as planned, I'll have to find some way
> to hack up vcl_error{} to still work as we are used to, and I'm
> increasingly finding that more trouble than it is worth and leaning
> more and more towards the 4.0 option where we can do away with
> vcl_error{} and avoid all the complications.
>
> This email represents your chance to come up with really good
> arguments for why we should not simply skip 3.1

Hopefully I've articulated some arguments for keeping vcl_error that
don't just involve the standard gripes with losing vcl compatability.

-K

_______________________________________________
varnish-dev mailing list
varnish-dev [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev


phk at phk

Dec 16, 2011, 1:07 PM

Post #8 of 8 (448 views)
Permalink
Re: Varnish 3.1 becoming 4.0 instead (?) [In reply to]

In message <CABaBnj7OS8i3NoM8AunKQO026g2338pqVJym5UvhhG4u56fmbA [at] mail>
, Kacper Wysocki writes:

>But the reply to the client may fail or hit an exception at any point,
>both from the source side of the data (backend timeout) and the sink
>side (client timeout), and being able to do something in VCL on these
>conditions is gold.

What would you do ? The half-baked reponse being half-sent to the
client cannot be recovered or salvaged in any way ?

> As far as I can understand the problem it's that the introduction of
>streaming makes it real hard to do a callback?

It's more that there is nothing the call-back can do, the damage is
done and there's nothing sensible we can do, but a cleanup.

>There are some use cases for vcl_error are not being considered here.

They are considered, but I may not have explained it well enough:
Instead of vcl_error{}, you will use vcl_deliver{}, and in vcl_deliver{}
you can build synthetic responses.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk [at] FreeBSD | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

_______________________________________________
varnish-dev mailing list
varnish-dev [at] varnish-cache
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Varnish dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.