[APPLAUSE] So hi everyone.

Can everyone hear me all right?

At the back?

Yes?

How are we feeling today.

>> Awesome.

>> Awesome.

People are feeling awesome.

I like that.

This talk's called Varnish In Action, making your

website bulletproof, and I hope we achieve that today.

So anyway, my name is Thijs.

Hi.

I know it's weird-sounding name but will do fine.

I'm ThijsFeryn on Twitter in case you wanna follow

me, heckle me, ask me questions, or just engage later.

As Ian told you guys, I work at a hosting company.

I'm a tech evangelist, which is a fancy term for talking to

people, taking an input to the company, and trying to do interesting stuff.

Again, repetition.

I am a, a board member at a PHP user group for Belgium, Netherlands and Luxembourg.

So that's three countries we're covering.

And I am Belgian, and that poses a problem

right now, because okay, I, no need to explain, right?

There is a World Cup game going on right now.

Belgium is playing right now.

I've seen the first half from my room.

And we're 0-1 behind Algeria on a penalty kick, so I will compensate

for that poor performance and represent my country right here, right now.

So what's Varnish?

I would like to see some hands, let's keep it interactive.

Oh, before we can continue, is anyone following

the game, the second half on the game?

[INAUDIBLE].

>> Okay, Ian that's your responsibility, right?

If this score changes, just wave at me, >> I got it.

>> Okay, thanks man.

So what's Varnish?

Anyone familiar with Varnish?

Okay, cool.

I expect the other people either not to be familiar or a bit shy.

Anyway, a Varnish what is it?

It is, it does three things, or, it, it does caching.

It's actually a reverse proxy too.

A lot of people seem it as, see it as a load balancing system as well.

The people at Varnish themselves tend to call it an

HTTP accelerator, which is just a term that covers it all.

Why would we use such a system?

Anyone?

Why should we use a system that does caching or, or reverse proxying?

Anyone have an idea?

>> It's expensive for a website to gather more traffic.

>> Yeah, that's, that's one of the things.

What people use reverse proxies for is hiding the origin server,

that's something people usually do, SSL termination is a big one.

Varnish doesn't do that, spoiler.

Load-balancing, caching and compression.

And caching is the big one today.

Where, we'll mainly be focusing on caching.

And, what caching does for you, in, in

this modern-day and age, it's protecting your backend server.

Like, the term proxy, is, is, is old, we've

been using that term for, for more than a decade.

And back in the day these were

just regular forward proxies because internet connectivity was

kind of slow, and people needed a way to compensate for that, but that has changed.

We have broadband, very fast connections and we

shifted that to the other ends of the spectrum,

to the data center and because there's so

much connectivity, that lines get saturated boxes get attacked.

So we need to protect our backend server.

And that is exactly what this talk is about today.

Is it any good?

Is the question.

Can I see those hands again, who, who uses Varnish already?

Let's see, then tell me, is it good?

Is it good?

People think it's good.

I find it to be very good.

If you put it in front of your web server, it is so intelligent and so optimized.

It uses a lot of kernel tricks.

I won't discuss those right now, but the thing

is that memory and CPU usage you hardly see it.

There are websites that have 40 million

visitors a day with only two Varnish servers.

Why two?

Not because they get hit so much, because you need a fail over plan, of course.

If one falls down you need the other one, so it's a, it's a very good system.

And it's especially good when the pressure is on.

So, when you get a lot of visitors, tha's when you need to use it.

I tend to compare it to the blockbuster movie The Bodyguard.

Anyone see that one?

90s movie.

So, what essentially happens, and that is what Varnish does.

You put your varnish in front of your web server.

So Kevin Costner, Frank Farmer in the movie, is standing

in front of Whitney protecting her from evil, stalky fans.

I've been using this picture for a long time and I realized last week that this

is actually a horrible picture because Whitney Houston

died by over dose if I'm not mistaken.

So, too much HTTP traffic for her.

HTTP is the pro, I'm sorry if I insulted anyone.

[LAUGH] HTTP is the protocol, that, that we're gonna be using.

And we've been using it for a while.

And the caching, we've been using, we've been using it

since the 90s in browsers everyone familiar with browser cache?

I used to hate browse cache.

I use to absolutely hate it.

Why would I want a system that doesn't give me the latest updates?

Cuz it, it stores old content.

I don't want old content, I want new content.

I was kind of stupid, I was a kid back then.

But now I realize that there's, there's tremendous power in

HTTP, especially in terms of caching, you have a really good

cache control header that has a variety of, of, of

verbs you can use, and these are ones we often use.

We have the maxage and the s-maxage.

Max age is defined for browsers, s-maxage

is defined for servers, yes for proxy servers.

Varnish prefers s-maxage.

If it doesn't find an s-maxage it will take the maxage.

if it doesn't find that, it will just use this header, Expires, which is pretty

much the same thing, but in term, instead

of using relative timing it uses absolute timing.

But our problem's with browser cache, right?

And I'm preaching to the choir, browser cache,

you can flush it, so it defies the purpose.

Everyone has its own cache, there's no central cache.

Huge problems with browser cache, every now and then

I, I enable it when I have a slow connection.

But, connections, they're not fast enough, I guess.

A bit of history, before we start seeing some codes and doing some set up.

Varnish is invented by a Danish guy called Paul-Henning Kamp,

and he developed it for a Norwegian, newspaper called Verdens Gang.

It was a custom project.

He, he didn't build it to release it as an open source project, he built it

for Verdens Gang, and that was ordered by

Redpill Linpro, which is a Norwegian consulting company.

So they had Paul-Henning working on the project for Verdens Gang.

It was such a success that they decided to open source it.

And nowadays the product is so successful

that there's a separate company these days.

Varnish software they do enterprise.

Tools on top of it training professional services.

You know how that works, right?

With open source.

They find a way to fund the project.

It started out in 2005.

V1 2006.

V2 2008.

V3 which is still the most popular version in 2011.

And look what we have.

In 2014, April 29, so less than two months ago.

Version two.

A version four was released.

And that poses a bit of a problem in this talk, because version four is

not mainstream enough yet to be to just drop all the vtrees stuff on my slides.

But then again, if you're not familiar with Varnish and we want to send you out

with some, a brief overview it would be sad that I don't show you the latest.

So, it'll be like a trade off.

This is how you do it in V3, V4.

I know it's quite annoying, but I hope it will help you.

So, let's install it.

It's pretty simple.

We're all Linux people here?

Any Windows folks?

Windows is absolutely fine.

We have hybrid setups where we put Linux

boxes with Varnish right in front of IIS's.

But for the purpose of this talk we'll focus

on Linux and I'm more of a deviant Ubuntu guy.

So these are the installation procedures using

the APT get, Varnish has its own channels.

I would say don't depend on the operating

system channels because they tend to be outdated.

So go for eh, the ones that Varnish offers you.

And I put some color in it, the yellow color is the distribution.

So change that accordingly.

And V3, Varnish 3.0, you can change that with

4.0 and you have the most recent version available.

So once we've installed it we need to configure it of course.

And configuring it is quite easy.

There is a file that has your demon startup options, and you can

see at the minus A parameter points to port 80, which is just

saying on what, which port should it listen and it totally makes sense

to put it on 80 because that is the HTTP port of course.

And I didn't, before the colon, I didn't mention any

IP address so it just binds to everything it can find.

The minus T capital is the admin interface which is

a telnet kind of interface so it's not encrypted, be careful.

Don't put it open.

Minus F is where the magic happens.

It points to a VCL file, which stands for Varnish Configuration Language.

And is the sort of DSL to the main specific

language that we'll be using for caching policies request handling.

So this defines how Varnish should behave.

If we connect over to minus T, so over Telnet,

we should add a layer of security because it's not encrypted.

That's why there's a secret key there that will be used in a sort

of challenge system, and eventually the storage

is in RAM, malloc RAM, and 1 gigabyte.

So, that's it.

And if we open the VCL file, the only thing that needs to be in there is

a reference to the backend, and that's, in

this case on the local system on port 8080.

But, this sometimes requires changing some web server parameters.

So if you host your Varnish on the same box as your Apache or

your Engine X or whatever you're using you might want to change the ports.

I always use 8080.

So if you go to your process list and it

runs on 8080, some systems see it as HTTP alternative,

so it's actually considered as an alternative port for HTTP

or on another IP if you host it on another box.

Speaking of boxes, out of the box behavior is pretty common.

It respects your HTTP caching headers, which we've discussed a minute

ago, so those cache control headers expires headers, it will use those.

But what it wont do, and this is where you need to pay attention, because

this has bitten me in the ass, number of times when I started out with Varnish.

If it's a post, a delete, or a put it will not cache.

Why is that?

Anyone?

You can use a fancy word for it.

There is a fancy word for these kind of HTTP methods, anyone?

[UNKNOWN] >> Yes, there we go.

[UNKNOWN] is that what you were saying?

Okay, am I pronouncing it right?

I'm not a native English speaker.

Okay, thank you.

So what this actually implies is, if you use a post, a delete, or a put verb, it

actually changes the data, so and if it changes it, you can't cache it.

So Varnish will proactively pass these along to the backend.

If it sees cookies, it won't cache it, why?

Because cookies imply that there's user specific data.

And user specific data like, remember the shopping cart, hello Jack.

Well if everyone see's hello Jack, my name is Tase and I

see hello Jack, I know clearly something went wrong with the caching system.

I've made that mistake before.

Aggressive caching in shopping cart, went completely nuts.

Authentication headers also imply user specific

data, so it won't cache those hitters.

You know, those service that pop-ups.

Username, passwords.

Varnish won't cache those either.

If there is a set cookie header being sent from the back, so if the Apache

or whatever you're using is requesting the client

to store a cookie, Varnish won't cache either.

And if the TTLs, so the time to live, defined by

expires cache control, is equal zero or less than zero, it

wont cache either, and finally, and this is a new v4

feature, it will dig more in, into the grammar of cache control.

If it sees a no-cache, a no-store, or a private, it won't cache either.

So let's talk about cookies for a minute.

I personally don't quite like cookies, but they're out there.

I've heard in a new version of HTTP, which is decades still,

decades still to come so we have a lot of time yet.

There will look, be looking for a session mechanism, but in

the meanwhile we often use cookies for sessions or for other state,

mechanisms of state because HTP is is stateless protocol and we're trying

to figure out state in there so cookies are there for it.

And there's two kinds of cookies.

So if you got to a website you've never visited

before, your cookie store on your browser will be completely empty.

Once you connect with the server and the server

sends a set cookie, then it will be stored

on your local computer and every next request, the

cookie will be sent as well as a string.

So, that's what implies cookies and, and that way you know you're,

there are two kinds of cookies; set cookie and a regular cookie.

Okay, let's talk about the flow for a minute because that's an important one.

And I've, I've done three hour tutorials on this topic, and

that's where I tend to lose a lot of the people.

So I'll try to focus extra on the flow because the flow is important.

If you do not understand the flow, you're pretty much in trouble.

So this is taken off the Varnish website and it's, it's

three slides I have for you three, three kinds of flows.

So what happens here is that you, the

requests come in in a hook called VCL receive

and all these, all these little, balloon type

thingie, are hooks that you can hook into programatically.

So we'll be digging into code later.

And those aren't just clever names, those are important too.

VCL stands for Varnish Configuration Language,

and then, underscore and whatever it means.

So regv means receive, every request gets receive.

That's your point of entry.

And then there's decisions to make, red, green, yellow as you can see.

So if it's green, if it meets certain criteria, and

those were the criteria I mentioned here, some of the criteria.

It will look it up and will create a hash, and the hash is based on the URL.

And the host name, it will look it up in memory, and if

it finds it, you have a hit, if it doesn't, you have a miss.

If it doesn't meet those criteria, it will just pass.

You see the red line there?

Going directly to the back end?

And if it's something it doesn't understand,

it will bypass the engine completely and

create a pipe, a TCIP connection directly

to another system will completely ignore the cache.

If it's a hit you can still decide to pass it,

if it's a miss there's passing opportunities or you can fetch.

And fetching is connecting to Apache, connecting to IIS, connecting to

Engine X, connecting to whichever system you use that speaks HTTP.

And after the fetch, and that's page three, you can either deliver it, store

it in cache, or decide not to cache it and send it to the client.

Does that make sense?

It's like receiving, seeing if it's in

cache, or bypassing, fetching it, delivering it.

So far so good?

Everyone still with me?

Okay.

And this is a typical flow in v3.

And this is where the v3, v4 game starts.

You'll be seeing a lot of that.

If it's a hit, so if you request something and it is in cache and you don't

wanna connect to the backend but immediately deliver

it, this is the typical thing you'll be seeing.

You receive it, you look it up, it's a hit, you deliver it.

And those words, if I were you I would remember those, because those

will come back in the, in the syntax and the, and, and the coding.

If it's a miss, typically you will receive it, you look it

up, it'll be a miss, you will fetch it, and deliver it.

Now there are changes in v4.

Look.

See?

Changes.

Hash and look up have now been switched.

According to me, it makes much more sense, because looking up

is something you do after the hash has been made, right?

So if you create a hash first, then you look it up in memory.

So they, they did it right.

So first you receive it, then you hash it, it's a hit you deliver.

Otherwise, you receive it, you hash it, it's a miss

and see what they did here, and this is a

major feature of v4 in Varnish, they split up, the

request coming in and the backend connection in two separate trends.

This used to be one single trend, so that

caused a slow down for the person who got to

the cache and notice that it wasn't there, and it

needed to be fetched so that person had to wait.

And all the others got served stale data.

So now what happens is they break it up in two process or two treads.

Request comes in, fetch gets initiated, while that happens everyone gets all

data, no one has to wait and then the stuff gets in.

So they split that up in two methods.

The back end fetch and the back end response.

Whereas fetch in v3 was done after the fact.

So, after you have retrieved your data from the backend system, this happens.

And then eventually, you deliver.

And we have been talking an awful lot about

VCL, about the varnish configuration language, the tool we use.

Is that red readable for you people?

Yeah?

Somewhat?

And it's the main specific language, and I tend to call it curly braces style.

So for people who are familiar with PHP, Pearl, C#, C,

C++ this is something you'll understand and something you will appreciate.

It describes, as I mentioned before, request handling and caching polices.

And it get compiled so if you restart your

Varnish, it get compiled to C and is very optimized.

It's loaded as a shared object.

It has a bunch of hooks, as you noticed in the flow.

And there has been a syntax change that you are now aware of.

So those are the hooks, let's not spend to much time on this.

But just to show you that there's a tremendous amount of hooks.

And in these hooks you have behaviors, you have actions you can take.

So, if you receive a request, you could look it up.

And this is v3 stuff, you can look it up.

Pipe, pass or error.

Error is like exception showing that you do in your, in your programming language.

You just skip whatever you're doing and send data.

And then you can pipe, you can hash.

Let's not spend too much time on

this slide, these slides will be available online.

So if you wanna peek in later, be my guest.

In v4, see, I've added red.

There's a tremendous amount of changes.

The VCL backend response is now there instead of the fetch.

Instead of error we have now VCL sent.

What that means is like, if you wanna escape, if you wanna stop

your execution and want directly deliver HTTP output that is created in Varnish.

Let's say you have a 200, everything is fine, output

you wanna give to the, to the client, you do error.

But that's not really an error, 200, HDP200 code is

not an error code, it's, it's says that everything is okay.

So what they did is they changed that to synthetic output.

That's output created in Varnish, output that doesn't come from the bracket.

So they have a syn, VCL syn for that, and you can

directly purge, you have a purge hook where you can hook into.

But that would make sense.

This might sound like Chinese to you, if you're not Chinese,

this might sound Dutch to you, but we'll, we'll get there.

And finally, before we dig into the fun stuff, every VCL hook can

access certain objects, and you have four or five objects, you have a request.

That's what the client sends you.

You have a response in the end is what gets served to

the client, gets served back, and

everything in between depends on the behavior.

So if it gets stored in cache, we have the

object for it obj, if if it's not stored in

cache, you're gonna request it, and you will use the

backend request object, with all the proper fees that are there.

And if the backend responds, then its beresp backend response.

So, let's see some actual code, right?

The, I've been talking about default behavior and the flow.

This is the flow in action, okay.

Let's, let's go to this side for a minute, and go over it.

Is the print okay, can you read this in the back.

Is it.

Yeah?

Doable.

So, we received a request.

This is the hook where we dig into it.

If you don't specify any of this code, Varnish Retreat will behave like that.

This is behavior without even typing a single character.

But if we had to write it down, this is what it would look like.

So if there is no restart request, so if it just comes in for the first time, it's

gonna add a [UNKNOWN] foreheader so that your backend

application can retrieve the IP of the original request.

If it's not get, heads, put, post, trace, options or

delete, if it's just some sort of weird HTTP verb.

It will just wipe it off, and it will say I have no clue what you're talking

about, I will send this to the back end, and I'm not interested in what comes back.

If it's non-item quotient, it will pass it along to the back end, so if it's

not a get, or not a hit, we will pass, and pass means send it off.

This is criteria not met.

I don't wanna deal with this, I'm gonna send it back.

Same thing applies with authorization and cookie, user specific data.

Varnish doesn't wanna deal with that, sends

it back, and if all those criteria are

not met, we have a valid thing we can look up in the cache, return lookup.

Seems pretty simple, right?

If we can continue there is a piping mechanism that

doesn't do much but you can add logic to it.

Passing hook, that you can add logic to it, doesn't do much or anything special.

But, if you look at VCL hash.

This is how the hash is composed.

There is a hash data function that you use to create that hash.

And the first thing you do is, you add

your URL, because that's a clear identifier of a page.

But there could be multiple sites on a single server.

So you need a way of identifying the host.

If the host is set, use it, use request.htp.host.

See it as a request object in action.

And if it's not there, you use the server IP, because

you could just use an IP address to identify a page.

So that's that.

And it will return a hash tag that gets locked up in the cache.

If it's a hit you deliver it.

If it's a miss we'll fetch it from the back end.

And this is that fetching logic I've been talking about.

So if a TTL, so if a cache control header resulted in a time

to live less than zero or if there was set cookie, user specific data.

Something I haven't mentioned before.

Variation headers.

You can add cache variations if every single header

in your request is used for variation and it

doesn't really make sence, and we will, and this

is something, a new concept that I haven't explained before.

We're gonna head for pause.

So what that means is that we're going to store it in cache.

But as a sort of blacklist thing.

Because we have these mechanisms to determine

if it should be cacheable or not.

But if you store it in the hit for past cache, for 120 seconds as you

can see, the next 120 seconds we will make no decisions any more on future requests.

So that means that every time someone is.

Requesting that URL or, or, or, or that hash.

So combination of URL and host name, it will say don't store it.

Don't store it.

And that's a way of dealing with these kind of things.

And then you have your error which is synthetic output.

As you can see it's a place holder where variables go.

You can tweet that accordingly.

It always sends google mediation kinds of output.

Like its that's Farnish humor, but you change it to whatever you want it to be.

So it looks a little more branded you can

add your Cezzes and your java script to it.

Okay, so, what have we done so far?

We're half way to talk, I guess.

I hope I'm half way in terms of slides, too.

Yes?

We're looking good.

As we've set it up, we've configured it.

We know how it behaves.

We know what VCL look like, looks like.

And now we're gonna put it in production and see what happens.

And you have a nice set of tools.

That allow you to dig in and see what's happening.

Because no use in setting up a Varnish if you don't know what the response will be.

What the, what the behavior will look like and how effective it will be.

So first tool we're gonna use is

Varnishstat is a sort of continuously updated list

of parameters of your server, not request base

just the server, how is the server behaving?

And this is vTree stuff.

This is what it looks like in vTree.

You see your hit rate over the last ten

seconds, last 100 seconds, and the last 254 seconds.

That's because the, the screen was open for 254 seconds.

If I were to leave it open half an hour, it would be there.

And then you see all the kinds of action that you can do.

You see the share amount of connections coming in.

Or the amount of requests per seconds coming in.

You see the client requests, how much hits, how much

misses, back end connectivity because it can optimize the usage of

back end connections such as blah, blah, blah, blah and

then you can see, and that's an interesting one, end object.

That's the amount of object stored.

There's another one that is not visible right

here because the screen is not large enough.

It's a NLRU nuked and LRU stands for least recently used so if your

cache is full, if you have 1 gigabyte of caching memory and you have 2 gigabytes of

data that gets requested, let's say a lot of images, lots of, lots of video footage

that you, you want to be, you want to have stored, and if it gets full.

It drops the least recently used one, and if

that counter increases, you know you're running out of memory.

That could be a problem if you wanna serve all that data.

But if you have an entire stack of data and you just want

to serve the most popular things, you shouldn't worry too much about that.

Varnishstat has been optimized to v4.

This is what it looks like now, it's.

It looks a bit better I guess, but you don't see the hit rate anymore.

I read some mailing lists in for, some posts about this and

they say that the original, this one here, hit rate was a lie.

It was like an estimation.

It wasn't anything near close.

So this gives you an overview on what's happening

on our server, how much connections are we getting,

are there hits, are there misses, are we fetching

from the back end, and so on and so on.

Varnishlog.

That's where it gets really interesting.

It allows you to dig in and filter out specific requests coming in.

And I have to warn you, it's very verbose.

It doesn't get stored on disk, because if it

would've been stored on disk your disk would explode.

It gets stored in memory and you can hook into the memory and you can

look through whatever is there and it gets buffered and you can read that buffer.

If you run Varnish log on a production system, this will happen, but

it will be so fast that you won't be able to read it.

So it would be better to filter.

>> Boys have timed it up.

>> Yes!

[SOUND] Oh I'm sorry about that they have tied

it up thank you Ian for this very informative intermezzo.

okay, I feel, I feel better right now.

I feel a lot better they have tied it up who scored?

>> Just happened so I haven't seen it.

>> Okay we'll, we'll see that in a minute we'll hear about that in a minute.

so, as you can see,it's, it's very, very verbose,

and it allows you to see exactly is happening.

The first column is a sort of sequential number that

identifies the session, and then you can see the action happening.

So, we open a session, and your next column is either C

or B now, with C, it implies that these are client requests.

Request coming from the browser to the varnish,

and you can see we are connecting to

server 12121, this is a vm on my computer of course, and we're doing a get, we

are doing a rx kind of stuff, receiving kind of stuff, there you can see all the

headers coming in, and then you can see

vcl call, it receives it, you see, these verbs.

Or these keywords and hooks start coming useful.

You receive it, and all the criteria were

met, so there no cookies, no authorization headers.

It was a get, it was not a post.

So we'll look it up in cache, and it will create a hash as you can see, VCL call.

And then below you see the actual hash being built.

It was the homepage, so the slash.

And there was no host name.

I used the IP address, IP address was

used, we have our hash, but it wasn't stored

in cache, it was amiss, as you can see here, it was amiss, so we fetch it.

And if we fetch it, we're gonna use a back

end and that back end is going to be identified

by number 13, so if we go to one of

the next slides, you will see what happens in 13.

It's a clear tread.

You can follow and the back end is called default and in

the end, this is a kind of spoiler of what's about to happen.

RFC0TTO, so I didn't specify a cash control header that was bigger than zeo.

It was zero.

So, what it will do is it will fetch.

It will store it for 120 seconds according to the VCL.

So the VCL this side needs to be stored for 120 seconds.

Where?

In our hit for POD cache.

So it'll be blacklisted for the next 120 seconds.

And then we store that in an object and then we transmit that data to the user.

Pretty verbose right?

You can see a lot of stuff happening.

And then you can see 13 this is our back end request.

And as you see wait, wait, wait where does it happen?

Here?

Cache control no cache max H 0.

So if a client ask why isn't this page in cache you

want varnish log you dig in and you see exactly what is happening.

And these are the filtering options you can use.

So the minus C tells you only the filter on client interaction.

So that's connections coming into Varnish and

connections that Varnish sends back to the client.

You can use the minus M to filter on certain tags.

Tags are the second column.

And you can, make sure you filter out the hits or whatever you need to do.

There's more you can store these in files and append them to a binary file,

and that binary file could be used to replay or to look at later on.

Varnishlog in v4 looks pretty similar.

They've changed the way these things are named.

They've given him a clearer name, that is, is, makes much more sense.

But, and the sessions are, are, are, are separated much clearer.

But what's es, specifically spectacular about this tool in v4,

is that they now have a query language like SQL alike.

And it allows you to filter out tags.

And to because this was not possible in vTree.

So you wanna have all the urls of all the requests that have hits.

So you can see all the hits and all the misses.

Or you wanna make sure that you have all the pages only the

urls, where the fetch to the back end took longer than two seconds.

Very valuable information.

Or you can make sure that you have all the data.

Where the response header was, between 400, and 404, so, where the clients,

kind of screwed up, if you want to know, those kinds of things.

Varnishtop does the same thing.

But, it, does it, incrementally.

So, if we filter out, on the user agent you can see the top user agent.

And it's a mess, right?

Because there's so many variations of user agents.

And VarnishTop uses the similar syntax you can use minus i to get to filter

out tags minus capital I to do regular expression matches and so on, and so on.

In v4 it looks similar but using the minus Q

we have our nice little filtering language very powerful stuff.

Varnish NCSA is for those people who still want Apache style logs.

Because the apache of this, are gonna be empty once you have a good hit grade.

Because everything gonna be served, on the varnish, your apache is

not getting any hits so there's nothing in your access logs anymore.

But if you still want to replicate that behavior you can run Varnish NCSA as

a demon and these are the requests coming out, so very useful kind of stuff.

Who remembers that phrase, that popular phrase there

were only two things hard in IT, right?

Can anyone recite that?

One is what?

Naming things and two is?

'Kay, and there is a joke, there is only three things hard in computer science.

It's naming things,.

Cache purging and off by one error.

Yeah, kind of a stupid joke, but still.

You can purge and varnish and you can use the power of VCL to accomplish that.

So, as you can see, if you receive a request and its purged then look it up.

Why do you need to explicitly do that and return look up?

If you just let it continue.

It will drop into default behavior and default

behavior says if it's not gets put, whatever, it

will pipe it off and purge is not

really an official HTTP verb, it's something we invented.

So make sure to return immediately and look it up in the cache.

We look it up and again we filter our own purge.

And if it is there we.

Apply the purge message there and it will empty that specific page out

of the cache and will use synthetic output as you can see here.

To stop the execution until the user the client

that his has succeeded if it was a miss.

It was not in cache and you do a 404.

In V4 it just got a lot simpler this is V3.

This is v4 so if the method is purged return purge and there is a

separate hook that deals with all of this so very simple not a lot of logic.

To implement but varnish also have a every since V3

have a very powerful banning syntax so instead of just saying

we're gonna use a URL you can match on a lot

of things that are stored in the request for redirect objects.

So what you see here is, if the hosts equals our host

and the URL equals our URL, bannet, which is the same syntax.

But see what we do here.

We use a tilde, that does regular expression matching.

So if your request URL starts with something, then you can purge it.

And that means that you can.

Per jobs an entire tree.

Let's say you have a higher, higher tier structured website.

products, my products, product properties etcetera, etcetera.

It will purge it.

It will ban it immediately.

So, you have a lot of flexibility of

banning more than one page in that request.

In v4 they change things.

I'm gonna switch back and forward so you can see it.

They changed the syntax of.

Request, they named it to Method, which kind of makes sense.

And they use synthetic output instead of an error

because this is not an error, this is expected behavior.

So, 200 ban, that's basically it.

If you want to execute it, because that's where it gets useful,

you can hook that into your program and your logic of your software.

You can use curl or whatever other library you

sue to do HTTP requests from code and you can

just change the method to purge and it will purge

it like let's say you have a sort of hook

in your CMS where you have your delete or your

update or whatever you have and once you click it

it will update in the database and then in the

end it will trigger an HTTP call to your varnish.

To serve the fresh content.

That's something typical what you do when you have breaking news.

How long are you gonna cache something?

Infinitely.

It could be cached for days, weeks, months, years but

the moment that the update comes in, you wanna publish immediately.

And that's how you could do it.

A lot of people use the HTTP syntax with the purge method.

Other people use a telnet connection.

I use the binary here so if you, if you execute the binary it works as well.

So, varnish ADM is another binary and this is

just a wrapper around the telnet protocol that I

mentioned at the beginning of this thug, the minus

capital T which has a host in a port.

Well if you connect to it over telnet you can do the same things.

I've had a look at various CMS system like WordPress and Drupal, also Magento, like

popular CMS's and every single one of them implements it in, in, in a similar way.

And the dejupal plugin specifically allows you to choose between HTTP

or telnet, depending on the way you want to do it.

Like, if you want all the flexibility at your

software's end, like at your jupals end, you're going

to use the telnet, because you're free to type

in whatever you want, all the matching that you want.

If you want it to be easy and you don't want a lot of responsibility.

Just stick with that.

Purge security's important as well because everyone, like if

I'm clever and I know there's a varnish behind it

and I wanna be a punk, I just go to

every single site and purge it, purge, purge, purge purge.

Every single URL and the website will go down in minutes.

So you don't want that.

You want security, you want added security.

So what you do then is define an ACL, and that ACL, you can match it here.

If the client's IP is not in the list of IPs, subnets, host names, don't allow it.

Do an error, 405 no allow it.

In v4 we're going to use the syn C syntax, and

we're going to use the purge method here and a work.

Just fine.

Okay, quick infomezzo.

I have officially ten minutes left, but I'm gonna skip the Q&A.

I'm gonna use that for extra content, if you don't mind.

It does load balancing too.

Im gonna show you that pretty picture again.

It does load balancing to Varnish, and it distributes loads either

across the back ends or could be used as fail over strategy.

And for that it uses a term called Directors.

And Directors.

Yes?

Got up to 2 1.

>> Whoa, that's huge.

Thank you Ian, you made my day.

That's so nice.

I, I didn't expect them to know.

So my initial plan was to shut down all

social media, shut down every notification system I had,

and find a way to look at, like, pause the game on my iPad and just, it doesn't work.

So I'm very grateful, Ian.

That being said.

Directors are, behave like a back end, but they group several back ends within.

And you have several strategies of doing it.

You can do your typical round robin, the one

two, one two, just sequencing around your back ends.

Or you can use a random strategy.

Or you could do client hashing, which is a very interesting way of doing this.

Let's say you use sessions in your code, but the sessions get stored on this.

And if you load balance and you com, you, you get to reach another server, and

that one doesn't have your session on it,

you're shopping cart will just pff, be blank.

So in those cases if you don't do session clustering, you want

to use sticky IP as they call it, and this is sticky IP.

It will check your IP and will only route you to that very specific server.

The hash.

Is based on the URL, so, it will use URLs and distribute it evenly.

Every URL goes to a unique back end.

And you can use fallback.

You just stack several varnishes, and use them in priority.

DNS, look it up if you're interested.

It's too complicated.

I don't understand how it works.

We use health probes to define if a back end is healthy or not,

and you can specify all the parameters,

how much you should check, how many failures

before your back end is considered unhealthy,

how many successful pings should it have to

consider it healthy again, the expected responds, you can even add raw http to it.

For, for these purposes.

And I didn't mention this before, but you can, you can

add an extra parameter probe and link it, or do this inline.

And you're back end will, have these checks and that's

ideal to determine if a back end is helped or not.

And this especially important when you do fallback.

This is round robin, so you have your two back ends,.

One and two.

And you have your directory that behaves as a back hand.

An that is named local hosts.

And we use a round robin strategy.

We have back hand one and back hand two.

But just for the fun of it I show you that

there is a way of adding a third host in line.

And the only thing you do is set it here and you have a round robin load balancing.

See what changes here, not much right?

If you use random, we just change a keyword random, you can add weights to it.

Lets say you have a, a less reliable server you gonna send it best traffic.

Fallback, as I mentioned use health probes.

They are important, otherwise you're varnish won't be able

to determine if a system is healthy or not.

And order matters, so the first one is gonna get selected first.

If the first one drops.

Second one is gonna be used.

IP hash very simple, and it uses a client identity.

I've set this, just to show you, if you

don't set it it will still use the client IP.

And this is sticky IP in action.

If you don't want the IP to be the identifier, you can

add whatever you want here, and this will be used to distribute evenly.

URL hash.

Uses in the same way, but no extra parameters need to be mentions.

You can add weights to and it will distribute evenly using your URL.

And the URL, this is something, that can be kind of useful.

This is a, I don't really have time for intermezzo's but I"ll show you that.

Lets say that you have 1 gigabyte.

Of memory.

And you have 10 gigabytes of data and you want all of that stuff to be in cash.

One Varnish is not going to do it.

So what you can do is have a bottom

layer of Varnishes that you can use for horizontal distribution.

Distributed computing, right Aaron?

Distributed.

And you can store all your stuff on there, let's say you have a lot of

images, you'll store it and you put an

extra layer of Varnish on top of it [INAUDIBLE]

distribution that will send every URL for every

request, like every resource to a specific server, that

way you can spread it evenly and this one will be very fast and will be tuned.

To serve the most popular data.

And this will be tuned to surf all data so,

this will be stored here and this will be stored there.

You're not forced to Varnish as your top layer.

Any reverse proxy will do.

You can use Engine X, or, or whatever you wanna use.

But this is, an excellent strategy if you have more, you have, if

you don't have enough ram, and you have, a boat load of data.

So I hear the question already.

What about v4, how do you do loadbalancing in v4.

Well directors are no longer there in the core, they moved

them away, and created what they call vmods, va, varnish modules.

And these are C.

Modules that are available in the system or on GitHub.

There is a community out there and what you

do here is, you, every varnish before starts with v4.

It doesn't mean that if you mention, if you

don't specify this feature here feature is no longer compatible.

You mentioned v4 you imported the directories and in your in

it you'll do a bit of like seal like magic you're gonna.

Instead of using all the hooks, you will actually do a bit of programming.

You will initialize a new a, a new director, a virtual

director, and add your Apache and your Engine X back end, and

the only thing you need to do instead of [UNKNOWN] back

end, [INAUDIBLE] back end to video back end, and it will work.

Slight change, it, it seems that the impact is big on your VCL.

But I find it to be quite interesting and I find this

to be the way forward, randomization, see not much changing, just change the

innards from round robin to random, adds the weights, fallback, you

do the same thing so not much changes, add your probes that you've defined elsewhere.

IP hashing is no longer done separately, it's just hash and you just

mention what you want to hash here, out here, and you say client identity

or request IP or whatever you want it to be and for C

nothing changes actually if you wanted to be distributed using the URL, user URL.

Plain and simple, they narrowed it down.

So last minutes.

Let's show you the power of VCL and do some very useful things.

Let's say your application you're does not support cache

control headers or you've not been disciplined in that way.

And it's a mess and you don't have any control of

how long things are gonna get cache from the application level.

Luckily you can use your VCL fetch logic and say if the URL that I'm fetching.

Starts with Blah, so blah1, blah2 is match

two, fairly logical names for URLs of course.

You can set the back end response DTL, you can over-ride

it to 10 seconds, in all our cases, use an hour.

In v4 it changes a bit because the requests you see

here, we don't use reg, we use dereg, so the back-end requests.

Is the one we should use now and the fetch has been renamed to back end response.

Other things.

Removing cookies.

Let's say cookies get generated on the

system and you don't need them for anything.

Just remove them that way.

Unset the cookie and or when the cookie comes

in from the back end instead of this way.

I've done this number of times.

In v4 the only that changes is the methods.

This is something you should have in every single varnish configuration you use.

Who uses Google Analytics?

Everyone, right?

Google Analytics.

There are people who don't use Google Analytics, wow!

Spectacular.

So Google Analytics is just a piece of JavaScript

you include and what it does, it starts setting cookies.

Those UTM style cookies, and these are very annoying.

But you should know that your server itself, your Apache,

or IIS, or whatever you're using, does not look at these.

This is just interaction between JavaScript and your local cookie store.

So, if you just drop them, nothing will happen to your Google

Analytics results, but it will make sure that you can actually catch things.

So, on setting, that way, you can use regular expression magic to match those.

And if, in the end, after you've removed all those

cookies, it's just an empty screen, just drop the cookie entirely.

Or you can hash a cookie.

That's interesting.

A lot of people use try to specify languages or

region, lo, location, based on a splash page, you know, right?

You enter a splash page, you see a map of the world.

And you have to select your region or your language.

Not a lot of people do that using the URL or using the header for that.

Like the language header that is there they accept language.

They use it using a cookie so if you don't

take care of that cookie the site will not work.

And depending on the first hit let's say you have three languages on your

website or ten languages and the first one is a Frenchies and he goes there.

Every English guy will see the french language.

So that's not something you would like I guess so what you do here.

It's in the hashing, if you, if the cookie contains it's

a tilde, if it contains a language cookie; extract that language.

And hash it, hash it accordingly.

So what you do is you have your URL, your host

and in additionally you have a variation based on that language cookie.

And so you have Deutsch.

An English, a German, an Italian, and that way you can spread it.

And you can use actually the power of cookies

to not break your website and make sure it

still works.Cacheing static files, once a cookie is being

set, it gets set for everything, even for images.

So, this is a default you should add to your VCL's as well.

Remove your cookies if it is anything like this.

Look it up in cache.

And in v4 it changes a bit, this is one I use when I start working on

a, on a varnish assignment to, to see if it, if it's a hit or not, I add

an extra header an xheader because that's what

you're allowed to do if you're, you adding extra

headers you can't name it whatever you want, It

should be named very specifically, a hit or miss.

Final.

Do I have five minutes more?

Can I get five more minutes of your attention, please?

Score still the same?

Etch side includes.

Anyone heard of etch side includes?

Do you like etch side includes?

Stumps.

Okay.

People like it, so you should use it if possible.

It's actually adding pieces to the puzzle, as this image shows you.

Imagine this set up.

I'm a PHP guy, I'm sorry for that you can throw stones, rocks at me

for whatever reason, but this is something you will see in a lot of cases.

Your typical page layout, a header.

A footer, a menu, and your main page for all the content list.

A header will usually contain welcome Peter

or welcome Stephanie or welcome whoever, so

that's all going to ge cached because you are going to use cookies for that,

or you're going to use specific things to take care of that, so let's say

we don't want caching here and our menu can only be cached for ten seconds.

On our main page for two seconds and our header for five seconds.

You kind of do this in Varnish because a

page is a single request and it has one TTL.

But, it is possible and I'll show you the trick.

Let's say we use this HTML.

I still use tables, I know, this is just

for the purpose of showing you how this works.

And we load these various.

Blocks of content.

But what if, see how we change it, what if we can use

these kind of tags, ESI tags, which are official, they are in the

W3C spec and you load them there, and Varnish can understand ESI, and

will render these pages separately, so will, will open up a set of requests.

Get all the data, respect that specific TTL, so if you say I want

that page 10 seconds, that one 5 minutes, that one 1 hour, that one

infinitely, it will respect that and it will pass it along as a single

document, so that is hugely powerful, because

if you don't want caching on your header.

The minimum TTL is the one of the, the least cacheable.

So if you have something you can cache for an hour and something you

can cache for a second, you will always take that one for a second.

But now you don't have to make that trade off anymore.

You can use it that in that way.

And this is how you do it in ESI.

You add an extra header or you can do it

explicitly under URL basis, but there is a standard for it.

There is an official header called the surrogate capability header.

And if you say in the key that ESI supported, your back end, your Apache,

your IIS, your EngineNext will know that

the system that is sending this supports ESI.

So in your PHP, your Python, your Ruby, whatever you're

using, your NodeJS, it's gonna know like okay, the system in

front of me supports ESI, so instead of loading it

as a single page, I can just put the tags there.

And Varnish will take care of it.

And once it comes back and your application

sends a surrogate control header, it's a sort of

confirmation like, okay, so that system that I

exposed ESI to, it now understands ESI as well.

And it sends ESI and just you, ESI.

It's just a matter of reading the capability header and sending back the.

Control header and you're doing fine.

In v4 it only changes the back end response and you're good to go.

Ending.

This is the final part.

Remember Varnish does not support SSL.

It's a political thing, they don't want SSL, so terminated elsewhere

you can put an Engine X in front of, or a pound,

or a h, a proxy, put something in front of your varnish

if you're using SSL because Varnish is not gonna deal with it.

And to end this very nice session, thank

you for being here, what about your projects?

Think about it.

If you're considering using Varnish and you have something custom

tailored like, not something CMS will like, think about your URLs.

What are the URL patterns that we're using?

Is there anything that is not cache-able?

What about cookies?

Am I using cookies?

Can I use certain cookies to do cash variation?

Should I drop certain cookies?

Are there pages that will still use cookies and that are not cache-able.

Think about these things very throughly if you're starting a new project.

Think about these things from the get go because if that is in your

architecture, it's just a matter of putting

varnish in front of it and it'll work.

And with that, I'll like to send you to

the break because there is a break right now.

I am very grateful for you being here.

I'm grateful that Ian kept me up to date on the score.

And thank you.