Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
U
unique-xids
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
uplex-varnish
unique-xids
Commits
cf66e086
Commit
cf66e086
authored
Oct 31, 2011
by
Tollef Fog Heen
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Typographical corrections, spelling
parent
2fceda5d
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
9 additions
and
9 deletions
+9
-9
backends.rst
doc/sphinx/phk/backends.rst
+9
-9
No files found.
doc/sphinx/phk/backends.rst
View file @
cf66e086
...
...
@@ -9,10 +9,10 @@ question answered conclusively long time ago, but once you try to
be efficient, things get hairy fast.
One of the features of Varnish we are very fundamental about, is the
ability to have multiple VCL
'
s loaded at the same time, and to switch
ability to have multiple VCLs loaded at the same time, and to switch
between them instantly and seamlessly.
So
I
magine you have 1000 backends in your VCL, not an unreasonable
So
i
magine you have 1000 backends in your VCL, not an unreasonable
number, each configured with health-polling.
Now you fiddle your vcl_recv{} a bit and load the VCL again, but
...
...
@@ -25,7 +25,7 @@ be up to date the instant we switch to the other VCL.
This basically means that either all VCLs poll all their backends,
or they must share, somehow.
We can dismiss the all VCL
'
s poll all their backends scenario,
We can dismiss the all VCLs poll all their backends scenario,
because it scales truly horribly, and would pummel backends with
probes if people forget to vcl.discard their old dusty VCLs.
...
...
@@ -39,7 +39,7 @@ It would be truly stupid to close 100 ready and usable connections to
a backend, and open 100 other, just because we switch to a different
VCL that has an identical backend definition.
But what is an identical backend definition in this context
?
But what is an identical backend definition in this context?
It is important to remember that we are not talking physical
backends: For instance, there is nothing preventing a VCL for
...
...
@@ -48,7 +48,7 @@ backends.
The most obvious thing to do, is to use the VCL name of the backend
as identifier, but that is not enough. We can have two different
VCL
'
s where backend "b1" points at two different physical machines,
VCLs where backend "b1" points at two different physical machines,
for instance when we migrate or upgrade the backend.
The identity of the state than can be shared is therefore the triplet:
...
...
@@ -78,11 +78,11 @@ is a wildcard-ish scheme, where you can write things like::
b1() # All backends named b1
b1(127.0.0.1) # All b1
's on Ip
v4 lookback
b1(127.0.0.1) # All b1
s on IP
v4 lookback
b1(:8080) # All b1
'
s on port 8080, (IPv4 or IPv6)
b1(:8080) # All b1s on port 8080, (IPv4 or IPv6)
b1(192.168.60.1,192.168.60.2) # All b1
'
s on one of those addresses.
b1(192.168.60.1,192.168.60.2) # All b1s on one of those addresses.
(Input very much welcome)
...
...
@@ -112,7 +112,7 @@ the backend gets retired anyway.
We should either park a thread on each backend, or have a poller thread
which throws jobs into the work-pool as the backends needs polled.
The patternmatching is confined to CLI and possibly libvarnishapi
The pattern
matching is confined to CLI and possibly libvarnishapi
I think this will work,
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment