From des at linpro.no Wed Sep 12 14:28:38 2007 From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=) Date: Wed, 12 Sep 2007 16:28:38 +0200 Subject: Degraded operation Message-ID: What follows is my design proposal for degraded operation, i.e. the ability to serve expired content when a backend is not responding. - The first step is to stop discarding objects when they expire. Instead of placing the object on death row, the misnamed exp_prefetch() simply marks it as expired. If the expired object is never needed again, it will eventually be discarded by LRU_DiscardLocked() (or not, if the cache never fills up) - As a consequence, Varnish will start getting cache hits for expired objects. Therefore, vcl_hit() must be able to inspect the object's expired flag and decide whether to serve the expired object or fetch a new copy. - In order to make that decision, vcl_hit() must be able to figure out which backend the object came from in the first place and inspect that backend's health metric. This opens up a number of interesting possibilities - things like "if the backend is starting to get bogged down but not quite dead yet, only refresh objects that are more than N seconds past their expiry time". - Now that vcl_miss() is no longer the only path to a backend request, we need to take a closer look at it. It really performs two distinct functions: one of them is to react to a cache miss, the other is to prepare a backend request. We need to separate these two functions, so if vcl_hit() decides to fetch a new copy, control can pass straight to the prepare-a-backend-request bit without passing through the react-to-a-cache-miss bit. I would like to name that last part vcl_fetch(), but that name is already taken by the verify-the-result-of-the-backend-request bit. We should rename vcl_fetch() to something else, though I'm not sure what. - It would be nice to be able to define global variables that can be manipulated in the management interface as well as in VCL; for instance, an admin might want a "no-modify" flag that when set, causes VCL to never refresh objects which are already in cache. On the other hand, this can be done by loading a different VCL config. There are still a few gaps: - If we try to refetch an expired object, not knowing (yet) that the backend is dead, what happens to the old copy of the object? Preferably, it should remain in the cache so we can serve it instead of the non-existent fresh copy. - This does not address prefetching at all - I will have to think about how to implement it once the above is in place. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Wed Sep 12 15:33:25 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 12 Sep 2007 15:33:25 +0000 Subject: Degraded operation In-Reply-To: Your message of "Wed, 12 Sep 2007 16:28:38 +0200." Message-ID: <18461.1189611205@critter.freebsd.dk> In message , =?iso-8859-1?Q?Dag-Erling_Sm=F8rg rav?= writes: (I'm in the middle of EuroBSDcon2007, so please bear with me if my replies are short and delayed the next week.) >What follows is my design proposal for degraded operation, i.e. the >ability to serve expired content when a backend is not responding. I'm not entirely happy with this proposal for a large number of reasons, but instead of picking it apart, here are my thoughts on the subject. The first observation is that the entire concept of degraded mode is a minefield of decisions and trouble once you have multiple backends. There is simply no way we can satisfy the countless and generally unique configurations with any kind of one-size-fits-all policy decision. The second observation is that everything in Varnish should be controlled/-able from VCL. Once those two are nailed firmly in place, it follows that we will not have a "degraded mode" but merely switch between different VCL programs. And that's roughly speaking, the end of any discussion on degraded mode. An entirely different, but not unrelated subject, is what facilities Varnish offers, and one of those most relevant to a degraded mode is to serve content which is technically expired. The way things are planned in that area is something like: An object gets fetched in from backend. A timeout and ttl gets assigned. when timeout expires vcl_timeout() can decide: - to set a new timeout - to gzip object - to discard object - to prefetch new copy of object (possibly others) What you might want to do to implement a degraded mode would be to only discard objects for which you have a newer copy, this could look something like this in VCL code: sub vcl_fetch { set obj.ttl = $mypolicy; /* check for gzip necessary early in lifetime */ set obj.timeout = obj.ttl / 10; } sub vcl_timeout { /* Only discard if we have a newer version */ if (obj.has_replacement) { discard; } /* Try to prefetch up to four times in the last 2 minutes */ if (obj.ttl <= 120s) { set obj.timeout = 30s; prefetch; } /* Call again two minutes before expiry */ set obj.timeout = obj.ttl - 2m; /* Gzip if we use it a lot */ if (obj.usage > a_lot) { set obj.gzip = true; } } And then degraded mode, more or less, comes down to ignoring the TTL check. The TTL is currently implemented in C and it may not be suitable to move it to VCL, but this could be handled with way for vcl_hash() to ask for it to be ignored, so the degraded version of the VCL code would have something like: sub vcl_hash { req.hash.ignore_ttl = true; } Which would then return the youngest matching object, even if it has expired. There are a lot of other tricky issues to resolve though, mainly "what tools do we offer to decide that we should hit degraded mode" and even worse, "how do we know when to get back into normal mode". The answer to the first one is probably the backend statistics and a check somewhere in the VCL program, possibly in the yet-to-come vcl_error(). The answer to the second one is much more tricky, because how do we know that the backend is back, when we don't ask it ? The first option, which I think will be quite complex and not anywhere near good, would be to use prefetching to detect when the backend comes up again. One would have to decided what to pretech and to add a level of detection to the results. All undesirable overhead in my eyes. The other, much simpler option is to keep sending a small fraction of the requests to the backend: sub vcl_hash { if (random() > .001) { /* random returns [0...1] */ req.hash.ignore_ttl = true } } And then keep monitoring the backend statistics and return to normal mode once it looks good. The really interesting thing about this concept, is that an administrator could implement multiple levels of degraded mode: Normal Send only 50% of traffic to backend when needed. Send only 25% of traffic to backend when needed. Send only 10% of traffic to backend when needed. Send only 1% of traffic to backend when needed. Send only 0.1% of traffic to backend when needed. Anyway, I have dinner to cook and a conference to organize... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From des at linpro.no Wed Sep 12 17:00:15 2007 From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=) Date: Wed, 12 Sep 2007 19:00:15 +0200 Subject: Degraded operation In-Reply-To: <18461.1189611205@critter.freebsd.dk> (Poul-Henning Kamp's message of "Wed, 12 Sep 2007 15:33:25 +0000") References: <18461.1189611205@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > I'm not entirely happy with this proposal for a large number of > reasons, but instead of picking it apart, here are my thoughts > on the subject. > > The first observation is that the entire concept of degraded mode > is a minefield of decisions and trouble once you have multiple > backends. I know that you're allergic to the word "mode", and to a certain extent I both understand and agree. However, you are fighting a strawman, because I didn't use that word. There is nothing modal about what I propose. You're right that we can't keep objects around forever, because it will cause swapping in situations where it otherwise wouldn't occur - but don't throw out the baby with the bath water. The rest of my proposal is still valid: vcl_hit() still needs to be able to make a decision about using the existing object or replacing it, vcl_miss() still needs to be split in two, etc. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Wed Sep 12 17:14:12 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 12 Sep 2007 17:14:12 +0000 Subject: Degraded operation In-Reply-To: Your message of "Wed, 12 Sep 2007 19:00:15 +0200." Message-ID: <24039.1189617252@critter.freebsd.dk> In message , =?iso-8859-1?Q?Dag-Erling_Sm=F8rg rav?= writes: >"Poul-Henning Kamp" writes: >The rest of my >proposal is still valid: vcl_hit() still needs to be able to make a >decision about using the existing object or replacing it, vcl_miss() >still needs to be split in two, etc. I don't agree. We can just allow vcl_hit() to issue a miss action (ie: "sorry can't use this hit") and go directly to vcl_miss(), just like we can go to vcl_pass() already. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Mon Sep 24 20:45:08 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 24 Sep 2007 20:45:08 +0000 Subject: Another fine point of C-language Message-ID: <81115.1190666708@critter.freebsd.dk> Some of the FreeBSD files include , for instance and That means that sometimes we get the official FreeBSD version of queue.h and sometimes we get the Varnish copy of the same. By definition we cannot use the Varnish copy for the FreeBSD system includes, but we could use the FreeBSD copy for the Varnish sources, if we wanted to. As long as they are identical, this is not a problem for anything but really anal souce-code-groking tools like FlexeLint, but down the road, if FreeBSD changes in any significant way, this would be a nasty bug to spot. I think I would prefer if we stick with the system version of if there is one we can use and reserve or private copy of it for systems that don't have it already. I have no idea how much autocrap magic that requires... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From darix at web.de Mon Sep 24 22:06:25 2007 From: darix at web.de (Marcus Rueckert) Date: Tue, 25 Sep 2007 00:06:25 +0200 Subject: Another fine point of C-language In-Reply-To: <81115.1190666708@critter.freebsd.dk> References: <81115.1190666708@critter.freebsd.dk> Message-ID: <20070924220625.GO3523@pixel.global-banlist.de> On 2007-09-24 20:45:08 +0000, Poul-Henning Kamp wrote: > I think I would prefer if we stick with the system version of > if there is one we can use and reserve or private > copy of it for systems that don't have it already. > > I have no idea how much autocrap magic that requires... #ifndef HAVE_SYS_QUEUE_H #include "queue.h" #endif ? darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From varnish at lukem.org Tue Sep 25 00:12:23 2007 From: varnish at lukem.org (Luke Macpherson) Date: Tue, 25 Sep 2007 10:12:23 +1000 Subject: Varnish minus VCL? Message-ID: <29f77e8a0709241712k2092c712u6fa3e7844f7ea52@mail.gmail.com> I am looking to deploy varnish in a configuration which has a large number of backends, and integrate it with our existing management infrastructure. I'd like to solicit your opinions on the best way to do that. What I'm thinking of doing is using replacing the compiled VCL configuration object with a custom-written object. This C library could talk to our existing infrastructure to keep track of live backends and choose the appropriate one at run-time based on availability, load and other factors. Is this a reasonable approach? Is the VCL api stable and well-defined enough? Is there a better place to plug-in this kind of functionality? -- Luke From phk at phk.freebsd.dk Tue Sep 25 06:16:35 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 25 Sep 2007 06:16:35 +0000 Subject: Varnish minus VCL? In-Reply-To: Your message of "Tue, 25 Sep 2007 10:12:23 +1000." <29f77e8a0709241712k2092c712u6fa3e7844f7ea52@mail.gmail.com> Message-ID: <6865.1190700995@critter.freebsd.dk> In message <29f77e8a0709241712k2092c712u6fa3e7844f7ea52 at mail.gmail.com>, "Luke Macpherson" writes: >I am looking to deploy varnish in a configuration which has a large >number of backends, and integrate it with our existing management >infrastructure. I'd like to solicit your opinions on the best way to >do that. > >What I'm thinking of doing is using replacing the compiled VCL >configuration object with a custom-written object. This C library >could talk to our existing infrastructure to keep track of live >backends and choose the appropriate one at run-time based on >availability, load and other factors. VCL has a mechanism for including C language, so in theory you can do that from a VCL program. >Is this a reasonable approach? Is the VCL api stable and well-defined >enough? Is there a better place to plug-in this kind of functionality? VCL doesn't guarantee stable internal APIs, that's one of the reasons why we go to such great lengths to make it one single executable that contains everything. That said, I don't see anything very hard or impossible in what you are proposing, but it takes a good programmer to get it right. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Tue Sep 25 09:17:06 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 25 Sep 2007 09:17:06 +0000 Subject: Source Code paranoia in Varnish Message-ID: <21899.1190711826@critter.freebsd.dk> "Source Code Paranoia" is about how much, or little, the programmer trusts that things are as expected. My usual trick question to junior programmers on this topic is: "What is the correct thing to do if close(2) fails ?" and I've enjoyed seeing faces change from "You think you're so smart" over "uhm, that's actually a very good question" to "I have NO idea..." many many times. Varnishd is not a very big program, just shy of 30k code lines, but that should not be confused with varnish being a simple program. Between shared memory, threads and processes and advanced memory management, there are a lot of things that need to be "just right" for things to work. And given the speeds at which users run varnish, any minor problem will escalate into a major problem in fractions of a second and the evidence destroyed in the process. That's why, about one line in 20 in varnishd sources are assert(3) like checks. Assert(3) will coredump the process if things are exactly the way the programmer expects them to be, "this pointer is before that pointer", "this systemcall returns success" and so on. So far, most of the coredumps that our patient users have reported, have been one of those asserts doing exactly what it was put there for. Unfortunately, some users are (still) seing what looks like pointer-tango and absent any obvious leads, I spent half the night running FlexeLint on the Varnishd sources, this time with even more paranoid settings. Until now I have used "it shouldn't make the source unreadable" as yardstick for source-code paranoia, but I'll crank that up a notch now, accepting minor eye-sores in order to catch even more bugs. I am not willing to take the cost of the entire signed/unsigned "cast all over the place" thing yet, but I accept the cost of the "pointer difference" paranoia thing. And I found two bugs, none of which seems to be able to explain the pointer-tangos, but they were bugs nontheless. So what is the correct way to deal with the return value of close(2) system calls ? You assert(3) that it succeeds and hope to never see that coredump. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From varnish at lukem.org Wed Sep 26 01:46:19 2007 From: varnish at lukem.org (Luke Macpherson) Date: Wed, 26 Sep 2007 11:46:19 +1000 Subject: Varnish minus VCL? In-Reply-To: <6865.1190700995@critter.freebsd.dk> References: <29f77e8a0709241712k2092c712u6fa3e7844f7ea52@mail.gmail.com> <6865.1190700995@critter.freebsd.dk> Message-ID: <29f77e8a0709251846q59a3aed0g16b4f5f07d8653c3@mail.gmail.com> I'm still kicking around ideas here. I'm trying to think of a solution which is workable in the presence of larger numbers of backends, without sacrificing performance or configurability of smaller setups. I imagine there are others running into the same problems. There are, I think, two main problems to solve: 1) Managing large numbers of dynamically changing backends. 2) Improving performance of request to service mapping when the number of services is large. (Or is there a nice way to do it I'm not aware of?) One option would be to introduce another shared-memory area for use between a management daemon and varnishd. I imagine this area would contain data-structures to be updated by the management daemon periodically, and read by varnishd when processing requests. A reader-writer locking scheme should give reasonable performance, since writes to the structure by the management daemon would be very infrequent. Here is how I think it should work: * shared hashtable of services * each service has a list of backends (and assigned weights, strategy params etc) * default service or 4xx/5xx configurable for hashtable misses Instead of deciding on a backend name, the VCL code should decide on a service name. It should be able to either specify a literal name, or generate a name string based on the Host/URL/other parameters. For example: sub vcl_recv { req.service = req.http.host; } would give good performance on large service maps, without precluding long lists of regular expressions for those that really need them. (is this legal VCL?) Initial values for the shared data-structures could be set by the VCL file to enable varnishd to operate as usual if an external management daemon is not present. I guess another (somewhat hacky) solution would be to continually generate and update VCL on the fly. Does anyone have further thoughts on this? On 9/25/07, Poul-Henning Kamp wrote: > In message <29f77e8a0709241712k2092c712u6fa3e7844f7ea52 at mail.gmail.com>, "Luke > Macpherson" writes: > >I am looking to deploy varnish in a configuration which has a large > >number of backends, and integrate it with our existing management > >infrastructure. I'd like to solicit your opinions on the best way to > >do that. > > > >What I'm thinking of doing is using replacing the compiled VCL > >configuration object with a custom-written object. This C library > >could talk to our existing infrastructure to keep track of live > >backends and choose the appropriate one at run-time based on > >availability, load and other factors. > > VCL has a mechanism for including C language, so in theory you can > do that from a VCL program. > > >Is this a reasonable approach? Is the VCL api stable and well-defined > >enough? Is there a better place to plug-in this kind of functionality? > > VCL doesn't guarantee stable internal APIs, that's one of the reasons > why we go to such great lengths to make it one single executable that > contains everything. > > That said, I don't see anything very hard or impossible in what > you are proposing, but it takes a good programmer to get it right. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > From ask at develooper.com Wed Sep 26 09:02:31 2007 From: ask at develooper.com (=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Wed, 26 Sep 2007 02:02:31 -0700 Subject: Varnish minus VCL? In-Reply-To: <29f77e8a0709251846q59a3aed0g16b4f5f07d8653c3@mail.gmail.com> References: <29f77e8a0709241712k2092c712u6fa3e7844f7ea52@mail.gmail.com> <6865.1190700995@critter.freebsd.dk> <29f77e8a0709251846q59a3aed0g16b4f5f07d8653c3@mail.gmail.com> Message-ID: On Sep 25, 2007, at 18:46, Luke Macpherson wrote: > I'm still kicking around ideas here. I'm trying to think of a solution > which is workable in the presence of larger numbers of backends, [...] How many servers do you have that this is a concern? Have you considered just putting perlbal or a load-balancer appliance between varnish and your backend servers? Then the dedicated device can take care of load-balancing, fail-over and all that fun - and you can use the management systems there to take backend servers in and out. Varnish then will just have to do what it does so well, caching. - ask -- http://develooper.com/ - http://askask.com/ From surendarmts at gmail.com Wed Sep 26 12:48:42 2007 From: surendarmts at gmail.com (surendar p) Date: Wed, 26 Sep 2007 18:18:42 +0530 Subject: Error Message-ID: Hi, When i compile the code,i got this error "Expected positive indentation". what is the actual error it is? Regards Surendar -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Wed Sep 26 12:50:28 2007 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 26 Sep 2007 12:50:28 +0000 Subject: Error In-Reply-To: Your message of "Wed, 26 Sep 2007 18:18:42 +0530." Message-ID: <15329.1190811028@critter.freebsd.dk> In message , "sure ndar p" writes: > >Hi, >When i compile the code,i got this error >"Expected positive indentation". > >what is the actual error it is? file and line information, please ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From varnish at lukem.org Thu Sep 27 00:29:12 2007 From: varnish at lukem.org (Luke Macpherson) Date: Thu, 27 Sep 2007 10:29:12 +1000 Subject: Varnish minus VCL? In-Reply-To: References: <29f77e8a0709241712k2092c712u6fa3e7844f7ea52@mail.gmail.com> <6865.1190700995@critter.freebsd.dk> <29f77e8a0709251846q59a3aed0g16b4f5f07d8653c3@mail.gmail.com> Message-ID: <29f77e8a0709261729v1fa7d0a5gd12549fbfd89fe2e@mail.gmail.com> > How many servers do you have that this is a concern? Enough. Though frankly, even if you had a small number of servers it would still be nice to support pluggable load balancing and failover models. > Have you considered just putting perlbal or a load-balancer appliance > between varnish and your backend servers? Then the dedicated device > can take care of load-balancing, fail-over and all that fun - and you > can use the management systems there to take backend servers in and > out. Varnish then will just have to do what it does so well, caching. Inserting a bottleneck and single point of failure doesn't sound like a good idea. Having m varnish servers talking to n backends gives a much better failover and redundancy model. By the way, I'm not asking anyone to implement this for me. I am a software engineer (not a network administrator), and since I have to do this anyway it's worth doing it in a way that can potentially contribute back to the project. From jallspaw at yahoo.com Thu Sep 27 04:09:50 2007 From: jallspaw at yahoo.com (john allspaw) Date: Wed, 26 Sep 2007 21:09:50 -0700 (PDT) Subject: Varnish minus VCL? Message-ID: <684386.93255.qm@web31814.mail.mud.yahoo.com> Not to take away from what sounds like a fun and sensible idea, but done correctly, the suggestions that Ask made (perbal, or an LB) don't have to be viewed as "bottlenecks" or a single-point of failure. Load balancers can be very good things to have. :) -j ----- Original Message ---- From: Luke Macpherson To: Ask Bj?rn Hansen Cc: varnish-dev at projects.linpro.no Sent: Wednesday, September 26, 2007 5:29:12 PM Subject: Re: Varnish minus VCL? > How many servers do you have that this is a concern? Enough. Though frankly, even if you had a small number of servers it would still be nice to support pluggable load balancing and failover models. > Have you considered just putting perlbal or a load-balancer appliance > between varnish and your backend servers? Then the dedicated device > can take care of load-balancing, fail-over and all that fun - and you > can use the management systems there to take backend servers in and > out. Varnish then will just have to do what it does so well, caching. Inserting a bottleneck and single point of failure doesn't sound like a good idea. Having m varnish servers talking to n backends gives a much better failover and redundancy model. By the way, I'm not asking anyone to implement this for me. I am a software engineer (not a network administrator), and since I have to do this anyway it's worth doing it in a way that can potentially contribute back to the project. _______________________________________________ varnish-dev mailing list varnish-dev at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC From varnish at lukem.org Thu Sep 27 04:41:33 2007 From: varnish at lukem.org (Luke Macpherson) Date: Thu, 27 Sep 2007 14:41:33 +1000 Subject: Varnish minus VCL? In-Reply-To: <684386.93255.qm@web31814.mail.mud.yahoo.com> References: <684386.93255.qm@web31814.mail.mud.yahoo.com> Message-ID: <29f77e8a0709262141k25b71b5ciba050fe395b304cf@mail.gmail.com> > Not to take away from what sounds like a fun and sensible idea, but done correctly, > the suggestions that Ask made (perbal, or an LB) don't have to be viewed as "bottlenecks" > or a single-point of failure. Load balancers can be very good things to have. :) I kind-of agree. Obviously I want load balancing, it's just I don't want to have to insert yet another layer to get it. If we add another layer, that layer has to be provisioned to cope with the full bandwidth of the backends, plus we need enough spare machines at that layer to provide failover. If we instead achieve the same thing using the front-end servers running varnish, we save ourselves all of the hardware that would be required for the load balancers. Meanwhile adding load balancing to varnish should have little or no measurable performance impact, and does not require any additional hardware either. Moreover, load balancing performance automatically scales as the number of varnish caches is increased. So anyway, that's a slightly more in-depth explanation for why I I think it is good practice to avoid introducing an additional load-balancing layer. From des at linpro.no Thu Sep 27 09:08:43 2007 From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 27 Sep 2007 11:08:43 +0200 Subject: Error In-Reply-To: (surendar p.'s message of "Wed, 26 Sep 2007 18:18:42 +0530") References: Message-ID: "surendar p" writes: > When i compile the code,i got this error > "Expected positive indentation". That's a Flexelint warning, you shouldn't get it while compiling. A little more information (such as copy&paste from your terminal) wouldn't hurt. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no