-Message d'origine-
It's probably simplest to paraphrase the code:
Calculate hash over full complement of backends.
Is the selected backend sick
Calculate hash over subset of healthy backends
Let's get back to consistent hashing and it's use...
Correct me
]] Ken Brownfield
| 3) Hash/bucket URLs to cache pairs.
|
| Same as 2), but for every hash bucket you would send those hits to two
| machines (think RAID-10). This provides redundancy from the effects
| of 2a), and gives essentially infinite scalability for the price of
| doubling your miss
In message 53c652a09719c54da24741d0157cb26904c5f...@tfprdexs1.tf1.groupetf1.fr
It's probably simplest to paraphrase the code:
Calculate hash over full complement of backends.
Is the selected backend sick
Calculate hash over subset of healthy backends
Let's get back
Hi all,
we are considering changing the defaults on how the cache-control header
is handled in Varnish. Currently, we only look at s-maxage and maxage
to decide if and how long an object should be cached. (We also look at
expires, but that's not relevant here.)
My suggestion is to also look
2010/1/18 Tollef Fog Heen tfh...@redpill-linpro.com:
Hi all,
we are considering changing the defaults on how the cache-control header
is handled in Varnish. Currently, we only look at s-maxage and maxage
to decide if and how long an object should be cached. (We also look at
expires, but
On Jan 18, 2010, at 5:20 AM, Tollef Fog Heen wrote:
we are considering changing the defaults on how the cache-control header
is handled in Varnish. Currently, we only look at s-maxage and maxage
to decide if and how long an object should be cached. (We also look at
expires, but that's not
On Jan 16, 2010, at 7:32 AM, Michael Fischer wrote:
On Sat, Jan 16, 2010 at 1:54 AM, Bendik Heltne bhel...@gmail.com wrote:
Our Varnish servers have ~ 120.000 - 150.000 objects cached in ~ 4GB
memory and the backends have a much easier life than before Varnish.
We are about to upgrade RAM
Hey there,
Anybody knows what's the plan to release saint mode ? :D
Thanks a lot,
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
On Jan 18, 2010, at 12:58 PM, pub crawler wrote:
This is an inquiry for the Varnish community.
Wondering how many folks are using Varnish purely for binary storage
and caching (graphic files, archives, audio files, video files, etc.)?
Interested specifically in large Varnish installations
In message a8edc1fb-e3e2-4be7-887a-92b0d1da9...@dynamine.net, Michael S. Fis
cher writes:
What VM can overcome page-thrashing incurred by constantly referencing a
working set that is significantly larger than RAM?
No VM can overcome the task at hand, but some work a lot better than
others.
On Jan 18, 2010, at 1:52 PM, Poul-Henning Kamp wrote:
In message a8edc1fb-e3e2-4be7-887a-92b0d1da9...@dynamine.net, Michael S.
Fis
cher writes:
What VM can overcome page-thrashing incurred by constantly referencing a
working set that is significantly larger than RAM?
No VM can overcome
Most kernels cache recently-accessed files in RAM, and so common web servers
such as Apache can ?already serve up static objects very quickly if they are
located in the buffer cache. (Varnish's apparent speed is largely based on
the same phenomenon.) If the data is already cached in the
On Jan 18, 2010, at 2:16 PM, pub crawler wrote:
Most kernels cache recently-accessed files in RAM, and so common web servers
such as Apache can ?already serve up static objects very quickly if they
are located in the buffer cache. (Varnish's apparent speed is largely
based on the same
On Jan 18, 2010, at 3:08 PM, Ken Brownfield wrote:
I have a hard time believing that any difference in the total response time
of a cached static object between Varnish and a general-purpose webserver
will be statistically significant, especially considering typical Internet
network
Differences in latency of serving static content can vary widely based on
the web server in use, easily tens of milliseconds or more. There are
dozens of web servers out there, some written in interpreted languages, many
custom-written for a specific application, many with add-ons and modules
In message 4c3149fb1001181416r7cd1c1c2n923a438d6a0df...@mail.gmail.com, pub c
rawler writes:
So far Varnish is performing very well for us as a web server of these
cached objects. The connection time for an item out of Varnish is
noticeably faster than with web servers we have used - even where
On Jan 18, 2010, at 3:37 PM, pub crawler wrote:
Differences in latency of serving static content can vary widely based on
the web server in use, easily tens of milliseconds or more. There are
dozens of web servers out there, some written in interpreted languages, many
custom-written for a
The average workload of a cache hit, last I looked, was 7 system
calls, with typical service times, from request received from kernel
until response ready to be written to kernel, of 10-20 microseconds.
Well that explains some of the performance difference in Varnish (in
our experience) versus
On Jan 18, 2010, at 3:16 PM, Michael S. Fischer wrote:
On Jan 18, 2010, at 3:08 PM, Ken Brownfield wrote:
In the real world, sites run their applications through web servers, and
this fact does (and should) guide the decision on the base web server to
use, not static file serving.
I
On Jan 18, 2010, at 3:54 PM, Ken Brownfield wrote:
Adding unnecessary software overhead will add latency to requests to the
filesystem, and obviously should be avoided. However, a cache in front of a
general web server will 1) cause an object miss to have additional latency
(though small)
In message 02d0ec1a-d0b0-40ee-b278-b57714e54...@dynamine.net, Michael S. Fis
cher writes:
But we are not discussing serving dynamic content in this thread
anyway. We are talking about binary files, aren't we? Yes? Blobs
on disk? Unless everyone is living on a different plane then me,
then I
In message 364f5e3e-0d1e-4c95-b101-b7a00c276...@slide.com, Ken Brownfield wri
tes:
A cache hit under Varnish will be comparable in latency to a
dedicated static server hit, regardless of the backend.
Only provided the dedicated static server is written to work in
a modern SMP/VM system, which
In message 87f6439f-76fe-416c-b750-5a53a9712...@dynamine.net, Michael S. Fis
cher writes:
I'm merely contending that the small amount of added =
latency for a cache hit, where neither server is operating at full =
capacity, is not enough to significantly affect the user experience.
Which
In message de028c9e-4618-4ebc-8477-6e308753c...@dynamine.net, Michael S. Fis
cher writes:
On Jan 18, 2010, at 5:20 AM, Tollef Fog Heen wrote:
My suggestion is to also look at Cache-control: no-cache, possibly also
private and no-store and obey those.
Why wasn't it doing it all along?
On Jan 18, 2010, at 4:15 PM, Ken Brownfield wrote:
Ironically and IMHO, one of the barriers to Varnish scalability is its thread
model, though this problem strikes in the thousands of connections.
Agreed. In an early thread on varnish-misc in February 2008 I concluded that
reducing
On Jan 18, 2010, at 4:35 PM, Poul-Henning Kamp wrote:
In message 97f066dd-4044-46a7-b3e1-34ce928e8...@slide.com, Ken Brownfield
wri
tes:
Ironically and IMHO, one of the barriers to Varnish scalability
is its thread model, though this problem strikes in the thousands
of connections.
Wanted in inject another discussion heady item into this thread and
see if the idea is confirmed in other folks current architecture.
Sorry in advance for being verbose.
Often web servers (my experience) are smaller servers, less RAM and
fewer CPUs than the app servers and databases. A typical
27 matches
Mail list logo
