From harry.mason at smoothwall.net  Tue Jan  5 13:45:31 2016
From: harry.mason at smoothwall.net (Harry Mason)
Date: Tue, 05 Jan 2016 13:45:31 +0000
Subject: Update to public release?
Message-ID: <1452001531.2804.8.camel@smoothwall.net>

On Tue, 04 Nov 2014, Alex Rousskov wrote:
> On 11/04/2014 03:56 AM, Philip Boulain wrote:
> > The download page, http://www.web-polygraph.org/downloads/ , says "these
> > [private] releases are made public after a few months of private use".
> > The last public version (4.3.2) is dated 2011, but there have been
> > several new private versions in the years since. Do you have an updated
> > policy on when a new public release will be made?
> 
> There is no change in intent, but we have now adjusted documentation to
> better match reality.
> 
> With some luck, we will publish accumulated changes (up to v4.9.0?) this
> year.

In late 2014, Alex hoped for a new public release by the end of the year.
Since then there have been no new releases, public or private. Is there any
chance there might be a new public release soon? Is it still a question of
release engineer time, or is the policy different now?

Cheers,
Harry Mason


From rousskov at measurement-factory.com  Tue Jan  5 22:49:40 2016
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Tue, 5 Jan 2016 15:49:40 -0700
Subject: Update to public release?
In-Reply-To: <1452001531.2804.8.camel@smoothwall.net>
References: <1452001531.2804.8.camel@smoothwall.net>
Message-ID: <568C4884.1090100@measurement-factory.com>

On 01/05/2016 06:45 AM, Harry Mason wrote:

> In late 2014, Alex hoped for a new public release by the end of the year.
> Since then there have been no new releases, public or private. Is there any
> chance there might be a new public release soon?


Done. Polygraph releases up to v4.9.0 are now publicly available:
http://www.web-polygraph.org/downloads/


> Is it still a question of release engineer time, or is the policy
> different now?

No changes on both fronts.


HTH,

Alex.


From harry.mason at smoothwall.net  Wed Jan  6 10:12:47 2016
From: harry.mason at smoothwall.net (Harry Mason)
Date: Wed, 06 Jan 2016 10:12:47 +0000
Subject: Update to public release?
In-Reply-To: <568C4884.1090100@measurement-factory.com>
References: <1452001531.2804.8.camel@smoothwall.net>
 <568C4884.1090100@measurement-factory.com>
Message-ID: <1452075167.2732.20.camel@smoothwall.net>

On Tue, 2016-01-05 at 15:49 -0700, Alex Rousskov wrote:
> On 01/05/2016 06:45 AM, Harry Mason wrote:
> 
> > Is there any chance there might be a new public release soon?
> 
> Done. Polygraph releases up to v4.9.0 are now publicly available:
> http://www.web-polygraph.org/downloads/

Thanks very much.

For me it failed to compile on Debian Jessie without this patch:

--- polygraph-4.9.0.orig/src/xstd/Ring.h	2016-01-06 10:09:25.990816721 +0000
+++ polygraph-4.9.0/src/xstd/Ring.h	2016-01-06 10:10:08.645849277 +0000
@@ -17,6 +17,7 @@
 	public:
 		Ring(int aCapacity = 0): Array<Item>(aCapacity), theInOff(0), theOutOff(0) {}
 
+		using Array<Item>::Value;
 		using Array<Item>::capacity;
 		using Array<Item>::size;



From rousskov at measurement-factory.com  Thu Jan  7 15:27:25 2016
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Thu, 7 Jan 2016 08:27:25 -0700
Subject: Update to public release?
In-Reply-To: <1452075167.2732.20.camel@smoothwall.net>
References: <1452001531.2804.8.camel@smoothwall.net>
 <568C4884.1090100@measurement-factory.com>
 <1452075167.2732.20.camel@smoothwall.net>
Message-ID: <568E83DD.6070303@measurement-factory.com>

On 01/06/2016 03:12 AM, Harry Mason wrote:
> On Tue, 2016-01-05 at 15:49 -0700, Alex Rousskov wrote:
>> Polygraph releases up to v4.9.0 are now publicly available:
>> http://www.web-polygraph.org/downloads/


> For me it failed to compile on Debian Jessie without this patch:
> 
> --- polygraph-4.9.0.orig/src/xstd/Ring.h	2016-01-06 10:09:25.990816721 +0000
> +++ polygraph-4.9.0/src/xstd/Ring.h	2016-01-06 10:10:08.645849277 +0000
> @@ -17,6 +17,7 @@
>  	public:
>  		Ring(int aCapacity = 0): Array<Item>(aCapacity), theInOff(0), theOutOff(0) {}
>  
> +		using Array<Item>::Value;
>  		using Array<Item>::capacity;
>  		using Array<Item>::size;
> 

A.k.a. https://bugs.launchpad.net/polygraph/+bug/1380660 which now has a
similar fix posted.


Thank you,

Alex.


From harry.mason at smoothwall.net  Mon Jan 11 14:09:55 2016
From: harry.mason at smoothwall.net (Harry Mason)
Date: Mon, 11 Jan 2016 14:09:55 +0000
Subject: [PATCH] reuse_port option for multiple server instances
Message-ID: <1452521395.2685.13.camel@smoothwall.net>

This patch allows multiple polygraph-server instances to bind to the
same address and port. The intended use is to easily spread CPU load
across multiple cores. Enable it by adding "reuse_port = true" to the
Server block.

It is only tested on Linux, where it requires kernel >= 3.9.

Binding a new socket can reset existing connections which are part of
the way through a TCP handshake, so start all server instances before
starting any clients. See https://lwn.net/Articles/542738/

Harry Mason
Smoothwall Ltd.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: polygraph-reuseport.patch
Type: text/x-patch
Size: 3498 bytes
Desc: not available
URL: <http://lists.web-polygraph.org/pipermail/users/attachments/20160111/1b3cca28/attachment-0001.bin>

From rousskov at measurement-factory.com  Mon Jan 11 16:44:06 2016
From: rousskov at measurement-factory.com (Alex Rousskov)
Date: Mon, 11 Jan 2016 09:44:06 -0700
Subject: [PATCH] reuse_port option for multiple server instances
In-Reply-To: <1452521395.2685.13.camel@smoothwall.net>
References: <1452521395.2685.13.camel@smoothwall.net>
Message-ID: <5693DBD6.8060008@measurement-factory.com>

On 01/11/2016 07:09 AM, Harry Mason wrote:
> This patch allows multiple polygraph-server instances to bind to the
> same address and port. The intended use is to easily spread CPU load
> across multiple cores. Enable it by adding "reuse_port = true" to the
> Server block.

Thank you! Please note that according to our tests with Squid on
Linux[1], sharing the listening socket does not automatically balance
the load among the listening processes due to unfortunate TCP stack
listener selection algorithms in the kernel. I believe the last
paragraph in the article you cited[2] may hint at a similar problem.

[1]
http://wiki.squid-cache.org/Features/SmpScale#Will_similar_workers_receive_similar_amount_of_work.3F

[2] https://lwn.net/Articles/542738/


Do you see any harm in enabling server port reuse on all platforms where
it is supported, without adding a PGL option to control this behavior?
The only negative side effect I can see is where the test is
misconfigured to listen on a server port already used by another program
(e.g., httpd). In that case, reusing the port may mask a serious
configuration flaw, right?


> Binding a new socket can reset existing connections which are part of
> the way through a TCP handshake, so start all server instances before
> starting any clients. See https://lwn.net/Articles/542738/

FWIW, starting servers before clients is the best practice regardless of
port reuse.


Thank you,

Alex.


From harry.mason at smoothwall.net  Tue Jan 12 10:23:54 2016
From: harry.mason at smoothwall.net (Harry Mason)
Date: Tue, 12 Jan 2016 10:23:54 +0000
Subject: [PATCH] reuse_port option for multiple server instances
In-Reply-To: <5693DBD6.8060008@measurement-factory.com>
References: <1452521395.2685.13.camel@smoothwall.net>
 <5693DBD6.8060008@measurement-factory.com>
Message-ID: <1452594234.2737.26.camel@smoothwall.net>

On Mon, 2016-01-11 at 09:44 -0700, Alex Rousskov wrote:
> On 01/11/2016 07:09 AM, Harry Mason wrote:
> > This patch allows multiple polygraph-server instances to bind to the
> > same address and port.
>
> Thank you! Please note that according to our tests with Squid on
> Linux[1], sharing the listening socket does not automatically balance
> the load among the listening processes due to unfortunate TCP stack
> listener selection algorithms in the kernel.
> [1] http://wiki.squid-cache.org/Features/SmpScale#Will_similar_workers_receive_similar_amount_of_work.3F

I observed that too, but in my particular case it's not very important.

> I believe the last paragraph in the article you cited[2] may hint at
> a similar problem.
> [2] https://lwn.net/Articles/542738/

That seemed to me to be arguing that a multithreaded solution would be
unbalanced, but SO_REUSEPORT ought to be balanced. From the Squid page
it sounds like SO_REUSEPORT is intended to be balanced, and the reason
why it is not is unclear. Apparently the kernel uses a hash of the
tuple to decide which listener should wake up [3]; this explains why
connections may drop when a new listener is started, as that perturbs
the hash, and also that the kernel does not try to compensate if one
listener happens to be busier.
[3] https://lwn.net/Articles/542629/

> Do you see any harm in enabling server port reuse on all platforms
> where it is supported, without adding a PGL option to control this
> behavior?

I don't know which platforms it would work on. For instance it sounds
like FreeBSD has different semantics for SO_REUSEPORT [4]. To me it
sounds sensible to set the option all the time on supported platforms,
but I'm not very familiar with how Polygraph might be deployed.
[4] http://lists.freebsd.org/pipermail/freebsd-net/2013-July/036131.html

> The only negative side effect I can see is where the test is
> misconfigured to listen on a server port already used by another
> program (e.g., httpd). In that case, reusing the port may mask a
> serious configuration flaw, right?

Only if the original bind also set SO_REUSEPORT and shares the same
effective user ID. Otherwise the second bind will fail anyway.

Cheers,
Harry


From sanjeevirangan at gmail.com  Tue Jan 19 17:54:05 2016
From: sanjeevirangan at gmail.com (Sanjeevi Rangan)
Date: Tue, 19 Jan 2016 23:24:05 +0530
Subject: using same MIME header key for multiple users
Message-ID: <CANZ82UEsdWt-Gm0=3AwWGKM-TseJB3fcVXOHoWXdA8eQu3jYAg@mail.gmail.com>

Hi,
Is it possible to have multiple users using the same MIME header key? I
would like to test multiple users sending custom header key value pair. All
the users will have same key but different value. I tried creating multiple
robots with same header key and different values but looks like the header
key value are overwritten.

R1:
MimeHeader user1 = 'SOME_KEY: user1_value';
http_headers = [user1: 50%];

R2:
MimeHeader user2 = 'SOME_KEY: user2_value';
http_headers = [user2: 25%];

R3:
MimeHeader user3 = 'SOME_KEY: user3_value';
http_headers = [user3: 25%];

Will highly appreciate any suggestions regarding this.

-- 
*Regards,*
*Sanjeevi Rangan*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.web-polygraph.org/pipermail/users/attachments/20160119/b1b90a17/attachment.html>