infrastructure setup using ESI

Fri Oct 22 14:44:13 CEST 2010

Thanks -  the rant was awesome - this has been extremely helpful.

Here are responses to some of your questions:

How many documents do you have?

[AG] Approximately 75,000 pages of unique content. Since we are using
Akamai, we would not need to cache static assets (images, static html
files, css, javascript, etc) only pages rendered by the CMS (see below).
We plan on using ESI to support dynamic portions of the pages.

Is your backend good?

[AG] We're using an open source CMS (Concrete5). This CMS features very
flexible UI manipulation tools, but I believe like all of these CMS
systems there is a price to pay for flexibility, and this is usually in
performance. Because the database schemas cannot be optimized to support
a specific data types, they generally do not perform as well. 

Like most CMS systems, there is caching at the application layer - or we
can use memCache - but it seems the complexity of implementing these
caches are higher than putting Varnish in front. Additionally, these
caches do not support anything nearly as elegant as saint mode -
particularly when used in combination with ESI.

So, the answer for the purposes of this discussion is - not bad but not
good enough that we can use it comfortably without caching. 

How much traffic is backend seeing?

[AG] Peak traffic is about 150-200/requests per second

Does backend scale good/cheap?

[AG] We are using Xen virtualization and we have a fair amount of
capacity on our data center, so scaling out is not hard and/or
expensive.

What's your budget?

[AG] We already have our own data center so the incremental costs would
be not be high. This is a new project so the cost would be rolled into
the budget for the project.

What hardware do you have/plan on getting?

[AG] We have 24 HP BL460c blades with 24 GB of RAM each. We are using
Xen virtualization on most blades. We could dedicate two blades to
Varnish in an HA setup, but this would create a single point of failure
(even HA can fail).

I was thinking we would probably have multiple Varnish HA clusters
running on Xen Vms, one in support of each app or split out using the
hashing method on the load balancers that others have been suggesting
here.

________________________________

From: varnish-misc-bounces at varnish-cache.org
[mailto:varnish-misc-bounces at varnish-cache.org] On Behalf Of thebog
Sent: Thursday, October 21, 2010 7:39 PM
To: varnish-misc at varnish-cache.org
Subject: Fwd: infrastructure setup using ESI

Oppss, forgot to include the list.

---------- Forwarded message ----------
From: thebog <thebog at gmail.com>
Date: Fri, Oct 22, 2010 at 1:38 AM
Subject: Re: infrastructure setup using ESI
To: "Gresens, August" <AGresens at scholastic.com>

Hi,

I'll try and give some advice in general terms. You are asking if this
rope is long enuff, and that question has no good answer :)

Varnish is "most often" used close to the client (in front or behind
loadbalancer). A main reason is that it handles alot of webtraffic good
and cheap. This is where it's written to shine. But it shines in other
layers as well. depending on what you are trying to do:

Varnish works good in front of crappy backend, because it's
easy/flexible (configurationwise) to reduce/shape traffic to backend.

If your hot dataset is huge, you will need much RAM, and there the
budget kicks in. Some people dream of 64 GB RAM, some buy it by default,
and for some 64 GB is such a little part of the dataset that it really
does not help much. While others have a dataset where 4 GB RAM is more
than enuff, so it's cheap to do it. For some it does not matter in if
there are separate cached copy's, because it's free, so why not. For
some it does. Hard to answer :) So are the secondary requests to the
backend.

With Varnish you can manipulate HTTP headers that otherwise does not
make sense because you have a backend you can not tweak to get what you
want (Or this is more expensive than using Varnish). Some use Varnish in
front of many different backend systems, some use it in front of crappy
closed source backends. Many find VCL (Varnish configuration laguage) to
be really good and easy (some don't bother ever to learn it because they
don't need it), I can't think of many scenarios where you can't get VCL
to do what ever you'd like with HTTP and to some extent most of the HTTP
traffic.

So I would use Varnish where I have much traffic, where I need to reduce
traffic, and where I would like to shape traffic if I had to. It's a
tool, when you learn how to use it, you know when it makes sense to use
it. And it can be used many places in the stack.

I would also not install anything other than a 64 bit OS. And focus on
getting the right amount of RAM. As much as possible is always a good
start :)

Hope this answered some of your questions :) Sorry for the rant.

YS

Anders Berg

On Thu, Oct 21, 2010 at 11:14 PM, Gresens, August
<AGresens at scholastic.com> wrote:

	Hello

	Varnish is a key part of a new set of apps we are building - the
ESI feature in particular is something we want to take advantage of
extensively.

	Where does Varnish typically reside in the network architecture?
I would imagine in a scenario in which we would be using ESI, we would
want Varnish in front of the application load balancers. In this way,
Varnish would be the primary page assembler. We would likely run an HA
setup for fault tolerance.

	We were also considering if Varnish could be used much farther
downstream - in between the load balancer and the application. We
thought is might provide for more fault tolerance, but it seems the
disadvantage would be that there would be a separate cached copy in each
redundant varnish instance, and with ESI secondary requests would be
made back out to the same web server potentially, setting up a feed back
loop that could cause problems.

	Thanks for your responses in advance.

	August

	August Gresens
	Director of Technology, eScholastic

	Scholastic Inc.
	557 Broadway, NY, NY 10012

	Email :: agresens at scholastic.com
<mailto:agresens at scholastic.com> 
	Phone :: 917 363 3662

	_______________________________________________
	varnish-misc mailing list
	varnish-misc at varnish-cache.org
	http://lists.varnish-cache.org/mailman/listinfo/varnish-misc

<html><img src="http://www.scholastic.com/readeveryday/images/mailsig.jpg"></html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20101022/d7ccbdfd/attachment-0003.html>