From anders at fupp.net Thu Apr 3 15:25:35 2008 From: anders at fupp.net (Anders Nordby) Date: Thu, 3 Apr 2008 17:25:35 +0200 Subject: Debian autoconf breakage in trunk Message-ID: <20080403152535.GA65842@fupp.net> Hi, # ./autogen.sh + aclocal + libtoolize --copy --force + autoheader + automake --add-missing --copy --foreign configure.ac: installing `./install-sh' configure.ac: installing `./missing' bin/varnishadm/Makefile.am: installing `./depcomp' bin/varnishd/Makefile.am: installing `./compile' configure.ac:308: required file `debian/Makefile.in' not found Makefile.am:3: required directory ./debian does not exist Can't open configure: No such file or directory. ../bvarnish.sh: ./configure: not found make: no target to make. root at aicache6:~/varnish-trunk-2625# uname -a FreeBSD aicache6.aftenposten.no 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Wed Mar 19 10:08:41 CET 2008 root at aicache6.aftenposten.no:/usr/obj/usr/src/sys/AICACHE6 amd64 Plz fix, k thx! Bye, -- Anders. From pnasrat at googlemail.com Sat Apr 12 15:44:21 2008 From: pnasrat at googlemail.com (Paul Nasrat) Date: Sat, 12 Apr 2008 16:44:21 +0100 Subject: Move re test method into libvcl In-Reply-To: References: Message-ID: On 12 Apr 2008, at 16:31, Paul Nasrat wrote: > I was wanting to start looking at the vcl parser, and noticed that > you can't link against just libvcl to call VCC_CompileFile due to > VRT_re_test being called in vcc_string.c. > > Although varnishd supports -C to parse only > > The attached patch against trunk moves and renames the re_test > method into vcc_string.c so libvcl could be used outside of varnishd. Oops - that patch didn't remove the old method definition. Here is an updated version. -------------- next part -------------- A non-text attachment was scrubbed... Name: varnish-move-re-test.patch Type: application/octet-stream Size: 2751 bytes Desc: not available URL: -------------- next part -------------- From phk at phk.freebsd.dk Sat Apr 12 18:19:09 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 12 Apr 2008 18:19:09 +0000 Subject: Move re test method into libvcl In-Reply-To: Your message of "Sat, 12 Apr 2008 16:44:21 +0100." Message-ID: <15593.1208024349@critter.freebsd.dk> In message , Paul Nasrat w rites: >> The attached patch against trunk moves and renames the re_test >> method into vcc_string.c so libvcl could be used outside of varnishd. >-int >-VRT_re_test(struct vsb *sb, const char *re, int sub) >-{ Your patch breaks the convention that compiled code only calls VRT_* functions, you need to keep a VRT_re_test() wrapper around for that reason. -- 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 pnasrat at googlemail.com Sat Apr 12 15:31:39 2008 From: pnasrat at googlemail.com (Paul Nasrat) Date: Sat, 12 Apr 2008 16:31:39 +0100 Subject: Move re test method into libvcl Message-ID: I was wanting to start looking at the vcl parser, and noticed that you can't link against just libvcl to call VCC_CompileFile due to VRT_re_test being called in vcc_string.c. Although varnishd supports -C to parse only The attached patch against trunk moves and renames the re_test method into vcc_string.c so libvcl could be used outside of varnishd. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: varnish-move-re-test.patch Type: application/octet-stream Size: 2272 bytes Desc: not available URL: -------------- next part -------------- From anders at fupp.net Sat Apr 12 23:04:03 2008 From: anders at fupp.net (Anders Nordby) Date: Sun, 13 Apr 2008 01:04:03 +0200 Subject: r2614 - trunk/varnish-cache/bin/varnishd In-Reply-To: <20080331114921.12EA01EC0D9@projects.linpro.no> References: <20080331114921.12EA01EC0D9@projects.linpro.no> Message-ID: <20080412230403.GA2412@fupp.net> Hi, I mentioned to des previously that by going from trunk 2605 to 2614, my load and level of context switches per second grew a lot (during peaks), and sent a couple of graphs showing that. I've now tracked the problem down to this particular patch. I can run with the latest trunk (2629), and by removing this changeset, my load and context switches graphs are like before. Could you and/or Arjan please take look at this change again please. Running with or without -s malloc (which I've also been playing with lately) does not seem to make a difference, only applying/removing this changeset does. PS2: I recently heard des' talk on "Light My Fire". Is there any chance it could catch things like this, changes that give a distinct and negative impact on performance? Bye, Anders. On Mon, Mar 31, 2008 at 01:49:21PM +0200, phk at projects.linpro.no wrote: > Author: phk > Date: 2008-03-31 13:49:20 +0200 (Mon, 31 Mar 2008) > New Revision: 2614 > > Modified: > trunk/varnish-cache/bin/varnishd/cache_hash.c > Log: > Fix a memoryleak relating to hash strings, found by: Arjan (noosius). > > > > Modified: trunk/varnish-cache/bin/varnishd/cache_hash.c > =================================================================== > --- trunk/varnish-cache/bin/varnishd/cache_hash.c 2008-03-31 11:47:15 UTC (rev 2613) > +++ trunk/varnish-cache/bin/varnishd/cache_hash.c 2008-03-31 11:49:20 UTC (rev 2614) > @@ -383,6 +383,7 @@ > assert(VTAILQ_EMPTY(&oh->objects)); > MTX_DESTROY(&oh->mtx); > VSL_stats->n_objecthead--; > + free(oh->hash); > FREE_OBJ(oh); > } > > > _______________________________________________ > varnish-commit mailing list > varnish-commit at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-commit -- Anders. From pnasrat at googlemail.com Sat Apr 12 23:06:21 2008 From: pnasrat at googlemail.com (Paul Nasrat) Date: Sun, 13 Apr 2008 00:06:21 +0100 Subject: Move re test method into libvcl In-Reply-To: <15593.1208024349@critter.freebsd.dk> References: <15593.1208024349@critter.freebsd.dk> Message-ID: On 12 Apr 2008, at 19:19, Poul-Henning Kamp wrote: > Your patch breaks the convention that compiled code only calls VRT_* > functions, you need to keep a VRT_re_test() wrapper around for that > reason. I'm not sure that's breaking that convention - the call chain is in vcc_regexp and it's a test before generating the C for the compiled vcl binary. Maybe I'm misunderstanding what you mean by "compiled code" in this case - I think that you mean that any generated C from vcl should only call VRT_* functions, which this patch doesn't change, as it's a validity check before code generation occurs. I looked on http://varnish.projects.linpro.no/wiki/DeveloperResources but didn't see a mention of this convention - is there another place I should be looking so that I can understand the coding conventions of the project? Paul From phk at phk.freebsd.dk Sun Apr 13 07:03:17 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 13 Apr 2008 07:03:17 +0000 Subject: Move re test method into libvcl In-Reply-To: Your message of "Sun, 13 Apr 2008 00:06:21 +0100." Message-ID: <18304.1208070197@critter.freebsd.dk> In message , Paul Nasrat w rites: > >On 12 Apr 2008, at 19:19, Poul-Henning Kamp wrote: > >> Your patch breaks the convention that compiled code only calls VRT_* >> functions, you need to keep a VRT_re_test() wrapper around for that >> reason. > >I'm not sure that's breaking that convention - the call chain is in >vcc_regexp and it's a test before generating the C for the compiled >vcl binary. Maybe I'm misunderstanding what you mean by "compiled >code" in this case - I think that you mean that any generated C from >vcl should only call VRT_* functions, which this patch doesn't change, >as it's a validity check before code generation occurs. Correct, but your patch removes a VRT_ function which the generated code needs in order to run... >I looked on http://varnish.projects.linpro.no/wiki/DeveloperResources >but didn't see a mention of this convention - is there another place I >should be looking so that I can understand the coding conventions of >the project? They're not well documented, sorry. -- 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 pnasrat at googlemail.com Sun Apr 13 10:34:37 2008 From: pnasrat at googlemail.com (Paul Nasrat) Date: Sun, 13 Apr 2008 11:34:37 +0100 Subject: Move re test method into libvcl In-Reply-To: <18304.1208070197@critter.freebsd.dk> References: <18304.1208070197@critter.freebsd.dk> Message-ID: <936907E0-0282-4A49-8151-6BFB8A7988CE@googlemail.com> On 13 Apr 2008, at 08:03, Poul-Henning Kamp wrote: > In message , > Paul Nasrat w > rites: >> >> On 12 Apr 2008, at 19:19, Poul-Henning Kamp wrote: >> >>> Your patch breaks the convention that compiled code only calls VRT_* >>> functions, you need to keep a VRT_re_test() wrapper around for that >>> reason. >> >> I'm not sure that's breaking that convention - the call chain is in >> vcc_regexp and it's a test before generating the C for the compiled >> vcl binary. Maybe I'm misunderstanding what you mean by "compiled >> code" in this case - I think that you mean that any generated C from >> vcl should only call VRT_* functions, which this patch doesn't >> change, >> as it's a validity check before code generation occurs. > > Correct, but your patch removes a VRT_ function which the generated > code needs in order to run... I had a look and if we just rerun vcc_gen_fixed_token.tcl after the patch it does the right thing and, there is nothing in the vcl code that generates that function - it was purely used at compile time not run time. After doing this if I look for any references to the VRT_re_test call there are none. I don't think this method was generated, just grouped in with the other regex code but only used in vcc_string.c I'm happy to come up with a patch that keeps a wrapper, but from my reading of the code I'm not sure in this instance it is required. >> I looked on http://varnish.projects.linpro.no/wiki/DeveloperResources >> but didn't see a mention of this convention - is there another >> place I >> should be looking so that I can understand the coding conventions of >> the project? > > They're not well documented, sorry. I'll try to put a wiki page together with what I've learned about vcl internals (adding/removing stuff, etc). Paul From anders at fupp.net Sun Apr 13 20:15:05 2008 From: anders at fupp.net (Anders Nordby) Date: Sun, 13 Apr 2008 22:15:05 +0200 Subject: r2614 - trunk/varnish-cache/bin/varnishd In-Reply-To: <20080412230403.GA2412@fupp.net> References: <20080331114921.12EA01EC0D9@projects.linpro.no> <20080412230403.GA2412@fupp.net> Message-ID: <20080413201505.GA44129@fupp.net> Hi, This evening I got a high peaks for load and context switches in my graphs again, while running with 2629 (and changeset 2614 removed). :-( So I'm not sure how much impact 2614 has, but I'd still like for it to be checked. Checking mutex contests while these peaks are going on I didn't see much, but there sure is a lot of mutex operations going on (catched this in just a few seconds): 27837.73 Debug MTX_LOCK(hcl_lookup,hash_classic.c,150,&hp->mtx) 27651.87 Debug MTX_UNLOCK(SES_Charge,cache_session.c,253,&stat_mtx) 27649.91 Debug MTX_UNLOCK(SES_Charge,cache_session.c,238,&sp->srcaddr->sah- 27643.01 Debug MTX_LOCK(SES_Charge,cache_session.c,235,&sp->srcaddr->sah->m 27561.59 Debug MTX_UNLOCK(HSH_Deref,cache_hash.c,360,&oh->mtx) 27558.65 Debug MTX_LOCK(HSH_Deref,cache_hash.c,351,&oh->mtx) 27555.72 Debug MTX_LOCK(HSH_Lookup,cache_hash.c,196,&oh->mtx) 27499.97 Debug MTX_UNLOCK(WRK_QueueSession,cache_pool.c,294,&qp->mtx) 27499.97 Debug MTX_UNLOCK(wrk_thread,cache_pool.c,243,&qp->mtx) 27423.36 Debug MTX_LOCK(WRK_QueueSession,cache_pool.c,288,&qp->mtx) 27325.80 Debug MTX_LOCK(wrk_thread,cache_pool.c,240,&qp->mtx) 27276.70 Debug MTX_UNLOCK(HSH_Lookup,cache_hash.c,240,&oh->mtx) 27276.70 Debug MTX_UNLOCK(hcl_deref,hash_classic.c,238,&hp->mtx) 27276.70 Debug MTX_UNLOCK(hcl_lookup,hash_classic.c,168,&hp->mtx) 27274.73 Debug MTX_LOCK(hcl_deref,hash_classic.c,233,&hp->mtx) 27144.03 Debug MTX_LOCK(SES_Charge,cache_session.c,245,&stat_mtx) 4813.93 Debug MTX_UNLOCK(EXP_Touch,cache_expire.c,215,&exp_mtx) 4813.93 Debug MTX_TRYLOCK(EXP_Touch,cache_expire.c,206,&exp_mtx) = 0 4588.45 Debug MTX_LOCK(SES_Delete,cache_session.c,353,&ses_mem_mtx) 4588.45 Debug MTX_UNLOCK(SES_Delete,cache_session.c,355,&ses_mem_mtx) 4587.48 Debug MTX_LOCK(ses_relsrcaddr,cache_session.c,201,&ch->mtx) 4587.48 Debug MTX_UNLOCK(ses_relsrcaddr,cache_session.c,207,&ch->mtx) 4304.97 Debug MTX_LOCK(SES_RefSrcAddr,cache_session.c,143,&ch->mtx) 3531.52 Debug MTX_UNLOCK(SES_RefSrcAddr,cache_session.c,158,&ch->mtx) Anything to do about this? A 1-second ktrace from the same time can be downloaded from: http://anders.fupp.net/varnish/varnishd-ktrace-2008-04-13_22-05-27.out.gz I am running FreeBSD 7.0-RELEASE/amd64. The number of hits per second is only around 1200, but I have 3 million objects in the cache now. Bye, Anders. On Sun, Apr 13, 2008 at 01:04:03AM +0200, Anders Nordby wrote: > I mentioned to des previously that by going from trunk 2605 to 2614, my > load and level of context switches per second grew a lot (during peaks), > and sent a couple of graphs showing that. > > I've now tracked the problem down to this particular patch. I can run > with the latest trunk (2629), and by removing this changeset, my load > and context switches graphs are like before. > > Could you and/or Arjan please take look at this change again please. > Running with or without -s malloc (which I've also been playing with > lately) does not seem to make a difference, only applying/removing this > changeset does. > > PS2: I recently heard des' talk on "Light My Fire". Is there any chance > it could catch things like this, changes that give a distinct and > negative impact on performance? > > Bye, > Anders. > > On Mon, Mar 31, 2008 at 01:49:21PM +0200, phk at projects.linpro.no wrote: > > Author: phk > > Date: 2008-03-31 13:49:20 +0200 (Mon, 31 Mar 2008) > > New Revision: 2614 > > > > Modified: > > trunk/varnish-cache/bin/varnishd/cache_hash.c > > Log: > > Fix a memoryleak relating to hash strings, found by: Arjan (noosius). > > > > > > > > Modified: trunk/varnish-cache/bin/varnishd/cache_hash.c > > =================================================================== > > --- trunk/varnish-cache/bin/varnishd/cache_hash.c 2008-03-31 11:47:15 UTC (rev 2613) > > +++ trunk/varnish-cache/bin/varnishd/cache_hash.c 2008-03-31 11:49:20 UTC (rev 2614) > > @@ -383,6 +383,7 @@ > > assert(VTAILQ_EMPTY(&oh->objects)); > > MTX_DESTROY(&oh->mtx); > > VSL_stats->n_objecthead--; > > + free(oh->hash); > > FREE_OBJ(oh); > > } > > > > > > _______________________________________________ > > varnish-commit mailing list > > varnish-commit at projects.linpro.no > > http://projects.linpro.no/mailman/listinfo/varnish-commit > > > -- > Anders. > _______________________________________________ > varnish-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev -- Anders. From anders at fupp.net Fri Apr 18 09:40:05 2008 From: anders at fupp.net (Anders Nordby) Date: Fri, 18 Apr 2008 11:40:05 +0200 Subject: r2561 - trunk/varnish-cache/bin/varnishd In-Reply-To: <20080307114338.6563C1EC1D1@projects.linpro.no> References: <20080307114338.6563C1EC1D1@projects.linpro.no> Message-ID: <20080418094005.GA66259@fupp.net> Hi, Would it be possible to log free session workspace also? If I set diag_bitmap to 0x42, I get: 0 Debug - "WS(0x3a77bbe070 = (sess, 0x3a77bbe790 18 0 8192)" 0 Debug - "WS(0x3a0dbe8070 = (sess, 0x3a0dbe8790 20 4096 8192)" 0 Debug - "WS(0x3a0dbe8070 = (sess, 0x3a0dbe8790 685 0 8192)" 0 Debug - "WS(0x3a0dbe8070 = (sess, 0x3a0dbe8790 685 0 8192)" What are those three fields at the end? The first is space needed, the third is space allocated? Bye, Anders. On Fri, Mar 07, 2008 at 12:43:38PM +0100, phk at projects.linpro.no wrote: > Author: phk > Date: 2008-03-07 12:43:38 +0100 (Fri, 07 Mar 2008) > New Revision: 2561 > > Modified: > trunk/varnish-cache/bin/varnishd/cache.h > trunk/varnish-cache/bin/varnishd/cache_hash.c > trunk/varnish-cache/bin/varnishd/cache_ws.c > Log: > Log free object workspace instead of used to get the size of the object > structure into the picture. > > > Modified: trunk/varnish-cache/bin/varnishd/cache.h > =================================================================== > --- trunk/varnish-cache/bin/varnishd/cache.h 2008-03-07 11:36:52 UTC (rev 2560) > +++ trunk/varnish-cache/bin/varnishd/cache.h 2008-03-07 11:43:38 UTC (rev 2561) > @@ -581,7 +581,7 @@ > char *WS_Alloc(struct ws *ws, unsigned bytes); > char *WS_Dup(struct ws *ws, const char *); > char *WS_Snapshot(struct ws *ws); > -unsigned WS_Used(struct ws *ws); > +unsigned WS_Free(struct ws *ws); > > /* rfc2616.c */ > int RFC2616_cache_policy(const struct sess *sp, const struct http *hp); > > Modified: trunk/varnish-cache/bin/varnishd/cache_hash.c > =================================================================== > --- trunk/varnish-cache/bin/varnishd/cache_hash.c 2008-03-07 11:36:52 UTC (rev 2560) > +++ trunk/varnish-cache/bin/varnishd/cache_hash.c 2008-03-07 11:43:38 UTC (rev 2561) > @@ -300,7 +300,7 @@ > VSL_stats->n_objoverflow++; > if (params->diag_bitmap & 0x40) > WSP(sp, SLT_Debug, > - "Object workspace used %u", WS_Used(o->ws_o)); > + "Object %u workspace free %u", o->xid, WS_Free(o->ws_o)); > > oh = o->objhead; > if (oh != NULL) { > @@ -366,8 +366,8 @@ > return; > > if (params->diag_bitmap & 0x40) > - VSL(SLT_Debug, 0, > - "Object workspace max used %u", WS_Used(o->ws_o)); > + VSL(SLT_Debug, 0, "Object %u workspace min free %u", > + o->xid, WS_Free(o->ws_o)); > > if (o->vary != NULL) > free(o->vary); > > Modified: trunk/varnish-cache/bin/varnishd/cache_ws.c > =================================================================== > --- trunk/varnish-cache/bin/varnishd/cache_ws.c 2008-03-07 11:36:52 UTC (rev 2560) > +++ trunk/varnish-cache/bin/varnishd/cache_ws.c 2008-03-07 11:43:38 UTC (rev 2561) > @@ -136,11 +136,11 @@ > } > > unsigned > -WS_Used(struct ws *ws) > +WS_Free(struct ws *ws) > { > > WS_Assert(ws); > - return(ws->f - ws->s); > + return(ws->e - ws->f); > } > > char * > > _______________________________________________ > varnish-commit mailing list > varnish-commit at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-commit -- Anders. From anders at fupp.net Fri Apr 18 09:41:29 2008 From: anders at fupp.net (Anders Nordby) Date: Fri, 18 Apr 2008 11:41:29 +0200 Subject: r2561 - trunk/varnish-cache/bin/varnishd In-Reply-To: <20080418094005.GA66259@fupp.net> References: <20080307114338.6563C1EC1D1@projects.linpro.no> <20080418094005.GA66259@fupp.net> Message-ID: <20080418094129.GB66259@fupp.net> Hi, I also miss something like this, from varnishstat: n_objoverflow 0 0.00 Objects overflowing workspace But for sess_workspace. On Fri, Apr 18, 2008 at 11:40:05AM +0200, Anders Nordby wrote: > Would it be possible to log free session workspace also? > > If I set diag_bitmap to 0x42, I get: > > 0 Debug - "WS(0x3a77bbe070 = (sess, 0x3a77bbe790 18 0 8192)" > 0 Debug - "WS(0x3a0dbe8070 = (sess, 0x3a0dbe8790 20 4096 > 8192)" > 0 Debug - "WS(0x3a0dbe8070 = (sess, 0x3a0dbe8790 685 0 8192)" > 0 Debug - "WS(0x3a0dbe8070 = (sess, 0x3a0dbe8790 685 0 8192)" > > What are those three fields at the end? The first is space needed, the > third is space allocated? > > Bye, > Anders. > > On Fri, Mar 07, 2008 at 12:43:38PM +0100, phk at projects.linpro.no wrote: > > Author: phk > > Date: 2008-03-07 12:43:38 +0100 (Fri, 07 Mar 2008) > > New Revision: 2561 > > > > Modified: > > trunk/varnish-cache/bin/varnishd/cache.h > > trunk/varnish-cache/bin/varnishd/cache_hash.c > > trunk/varnish-cache/bin/varnishd/cache_ws.c > > Log: > > Log free object workspace instead of used to get the size of the object > > structure into the picture. > > > > > > Modified: trunk/varnish-cache/bin/varnishd/cache.h > > =================================================================== > > --- trunk/varnish-cache/bin/varnishd/cache.h 2008-03-07 11:36:52 UTC (rev 2560) > > +++ trunk/varnish-cache/bin/varnishd/cache.h 2008-03-07 11:43:38 UTC (rev 2561) > > @@ -581,7 +581,7 @@ > > char *WS_Alloc(struct ws *ws, unsigned bytes); > > char *WS_Dup(struct ws *ws, const char *); > > char *WS_Snapshot(struct ws *ws); > > -unsigned WS_Used(struct ws *ws); > > +unsigned WS_Free(struct ws *ws); > > > > /* rfc2616.c */ > > int RFC2616_cache_policy(const struct sess *sp, const struct http *hp); > > > > Modified: trunk/varnish-cache/bin/varnishd/cache_hash.c > > =================================================================== > > --- trunk/varnish-cache/bin/varnishd/cache_hash.c 2008-03-07 11:36:52 UTC (rev 2560) > > +++ trunk/varnish-cache/bin/varnishd/cache_hash.c 2008-03-07 11:43:38 UTC (rev 2561) > > @@ -300,7 +300,7 @@ > > VSL_stats->n_objoverflow++; > > if (params->diag_bitmap & 0x40) > > WSP(sp, SLT_Debug, > > - "Object workspace used %u", WS_Used(o->ws_o)); > > + "Object %u workspace free %u", o->xid, WS_Free(o->ws_o)); > > > > oh = o->objhead; > > if (oh != NULL) { > > @@ -366,8 +366,8 @@ > > return; > > > > if (params->diag_bitmap & 0x40) > > - VSL(SLT_Debug, 0, > > - "Object workspace max used %u", WS_Used(o->ws_o)); > > + VSL(SLT_Debug, 0, "Object %u workspace min free %u", > > + o->xid, WS_Free(o->ws_o)); > > > > if (o->vary != NULL) > > free(o->vary); > > > > Modified: trunk/varnish-cache/bin/varnishd/cache_ws.c > > =================================================================== > > --- trunk/varnish-cache/bin/varnishd/cache_ws.c 2008-03-07 11:36:52 UTC (rev 2560) > > +++ trunk/varnish-cache/bin/varnishd/cache_ws.c 2008-03-07 11:43:38 UTC (rev 2561) > > @@ -136,11 +136,11 @@ > > } > > > > unsigned > > -WS_Used(struct ws *ws) > > +WS_Free(struct ws *ws) > > { > > > > WS_Assert(ws); > > - return(ws->f - ws->s); > > + return(ws->e - ws->f); > > } > > > > char * > > > > _______________________________________________ > > varnish-commit mailing list > > varnish-commit at projects.linpro.no > > http://projects.linpro.no/mailman/listinfo/varnish-commit > > > -- > Anders. -- Anders. From trey at propeller.com Fri Apr 18 14:34:36 2008 From: trey at propeller.com (Trey Long) Date: Fri, 18 Apr 2008 10:34:36 -0400 Subject: Upload Buffering and x-sendfile Message-ID: <708382D6-63D8-4AE2-83B2-4872CAA2B536@propeller.com> Sorry if this is the wrong spot, the misc list wasn't helpful. This may be a question only the devs know anyway. Does varnish support upload (and download) buffering? Since varnish handles all of the traffic going to and from my host I was wondering if it buffered the client when they were uploading a large post body or downloading a large portion of HTML. The benefit here is that my host is not waiting for them to upload on their slow connection and the same for download. Does varnish support x-sendfile type responses? It seems I might be able to program this using VCL but I was unsure so I thought I would add it to this question. Can Varnish intercept a header on the way to the client and redirect to a static file? Thanks, Trey From phk at phk.freebsd.dk Mon Apr 21 05:42:48 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 21 Apr 2008 05:42:48 +0000 Subject: Upload Buffering and x-sendfile In-Reply-To: Your message of "Fri, 18 Apr 2008 10:34:36 -0400." <708382D6-63D8-4AE2-83B2-4872CAA2B536@propeller.com> Message-ID: <77448.1208756568@critter.freebsd.dk> In message <708382D6-63D8-4AE2-83B2-4872CAA2B536 at propeller.com>, Trey Long writ es: >Does varnish support upload (and download) buffering? > >Since varnish handles all of the traffic going to and from my host I >was wondering if it buffered the client when they were uploading a >large post body or downloading a large portion of HTML. Downloading: yes, we buffer. Uploading: no, we don't. >Does varnish support x-sendfile type responses? Not at present, but it sounds like it could be useful, I'll add it to the "post-2.0 ideas list". -- 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 Apr 21 07:06:22 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 21 Apr 2008 07:06:22 +0000 Subject: r2561 - trunk/varnish-cache/bin/varnishd In-Reply-To: Your message of "Fri, 18 Apr 2008 11:40:05 +0200." <20080418094005.GA66259@fupp.net> Message-ID: <81599.1208761582@critter.freebsd.dk> In message <20080418094005.GA66259 at fupp.net>, Anders Nordby writes: >Hi, > >Would it be possible to log free session workspace also? Everything is possible :-) I think we need to reexamine the workspace (full) handling after 2.0 is out, so please add your observations to the "post-2.0 ideas" wiki page and we can hash it out. -- 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 anders at fupp.net Mon Apr 21 09:08:06 2008 From: anders at fupp.net (Anders Nordby) Date: Mon, 21 Apr 2008 11:08:06 +0200 Subject: r2561 - trunk/varnish-cache/bin/varnishd In-Reply-To: <81599.1208761582@critter.freebsd.dk> References: <20080418094005.GA66259@fupp.net> <81599.1208761582@critter.freebsd.dk> Message-ID: <20080421090805.GA13875@fupp.net> Hi, On Mon, Apr 21, 2008 at 07:06:22AM +0000, Poul-Henning Kamp wrote: >>Would it be possible to log free session workspace also? > Everything is possible :-) > > I think we need to reexamine the workspace (full) handling after > 2.0 is out, so please add your observations to the "post-2.0 ideas" > wiki page and we can hash it out. Ok, I updated the page. Bye, -- Anders. From trey at propeller.com Mon Apr 21 14:20:22 2008 From: trey at propeller.com (Trey Long) Date: Mon, 21 Apr 2008 10:20:22 -0400 Subject: Upload Buffering and x-sendfile In-Reply-To: <77448.1208756568@critter.freebsd.dk> References: <77448.1208756568@critter.freebsd.dk> Message-ID: On Apr 21, 2008, at 1:42 AM, Poul-Henning Kamp wrote: > In message <708382D6-63D8-4AE2-83B2-4872CAA2B536 at propeller.com>, > Trey Long writ > es: > >> Does varnish support upload (and download) buffering? >> >> Since varnish handles all of the traffic going to and from my host I >> was wondering if it buffered the client when they were uploading a >> large post body or downloading a large portion of HTML. > > Downloading: yes, we buffer. > > Uploading: no, we don't. Are there plans to offer uploading as well? Since that is the normally the slower part of the experience. > > >> Does varnish support x-sendfile type responses? > > Not at present, but it sounds like it could be useful, I'll add it > to the "post-2.0 ideas list". > > -- > 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 Apr 21 14:42:40 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 21 Apr 2008 14:42:40 +0000 Subject: Upload Buffering and x-sendfile In-Reply-To: Your message of "Mon, 21 Apr 2008 10:20:22 -0400." Message-ID: <90513.1208788960@critter.freebsd.dk> In message , Trey Long writ es: >> Downloading: yes, we buffer. >> >> Uploading: no, we don't. > >Are there plans to offer uploading as well? Since that is the normally >the slower part of the experience. I will put it on the "post-2.0 ideas" page and see if it sticks. 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 lluo_2wire at yahoo.com Mon Apr 28 18:59:17 2008 From: lluo_2wire at yahoo.com (Louis Luo) Date: Mon, 28 Apr 2008 11:59:17 -0700 (PDT) Subject: Does Varnish support Pre-loading? Message-ID: <55977.39071.qm@web63903.mail.re1.yahoo.com> Hi, I have a question regarding pre-loading. When Varnish gets a response from the backend server, does it do any parsing of the page? If it does, and if it sees some embedded objects that might be requested by user browser, will it do the pre-loading? Thanks, L. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From phk at phk.freebsd.dk Mon Apr 28 19:32:16 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 28 Apr 2008 19:32:16 +0000 Subject: Does Varnish support Pre-loading? In-Reply-To: Your message of "Mon, 28 Apr 2008 11:59:17 MST." <55977.39071.qm@web63903.mail.re1.yahoo.com> Message-ID: <9083.1209411136@critter.freebsd.dk> In message <55977.39071.qm at web63903.mail.re1.yahoo.com>, Louis Luo writes: >Hi, > >I have a question regarding pre-loading. When Varnish gets a >response from the backend server, does it do any parsing of the >page? If it does, and if it sees some embedded objects that might >be requested by user browser, will it do the pre-loading? No. The only circumstances where Varnish examines the content for anything, is if you ask for ESI processing to be performed. That's not to say that we could not do it in the future, but there are no plans for it right now. -- 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 zegayews at ifi.uio.no Wed Apr 30 21:46:20 2008 From: zegayews at ifi.uio.no (zegayews at ifi.uio.no) Date: Wed, 30 Apr 2008 23:46:20 +0200 (CEST) Subject: few questions about varnish Message-ID: <1541.193.157.192.150.1209591980.squirrel@webmail.uio.no> Dear Sir/Madam, My name is Zegaye Seifu. I am a phd student at the university of Oslo. Currently I am doing a case study research on Varnish. I just would like to ask you the following 4 questions as you are a participant in the mailing list. Your prompt response to these questions is invaluable to what I am researching. Please take few minutes of your precious time and send your responses as soon as you can. 1)How do you come to use or work on Varnish? 2)What motivates you to contribute and interact in the mailing list? 3)What have you contributed to Varnish so far (like participiating in questioning, answering, bug fixing or giving patches)? Or if you have suggested any new ideas to the developers? 4)Anything that you would like to say about the software, the developers and the project organization in general? Any problems that you faced? Thank you for taking part in this study. If you would like to ask any questions or want to know about the study, you are most welcome. best regards, zegaye s.