On Tue, May 13, 2014 at 5:15 PM, RP Schell <[email protected]>wrote:
> Hi Philippe, > > Thanks for the reply. Unfortunately, using the CSV method still > suffers from the certificate switching problem (i.e. a single thread > changes certs as it executes). The CSV method just changes the order > in which certificates get used (that of the CSV file). > Did you try something like this: |-CSV DataSet |-Thread Group (forever) |--- Loop Controller (forever) |------Samples here won't switch > > If we change Apache's MaxKeepAliveRequests to 0 (unlimited) so that > connections from Jmeter to Apache never get closed, the certificate > switching doesn't happen. It seems clear that JMeter wants to change > certs when its connection to Apache gets closed. > Yes this is regular. > > -Bill > > > On Wed, May 7, 2014 at 6:30 PM, Philippe Mouawad > <[email protected]> wrote: > > Hello, > > that sounds reasonable, thanks for investigation. > > Indeed as keepalive close leads to socket close, a new init of ssl > context > > occurs leading to an increase in counter and thus leading to the switch. > > > > Switching to the method using CSV (as proposed by Ubik Load Pack) and > > variable name should not suffer from this I think. > > But a confirmation is welcome. > > > > Regards > > > > > > > > On Wednesday, May 7, 2014, RP Schell <[email protected]> wrote: > > > >> > >> We simplified the JMeter plan exhibiting the certificate switching > >> problem down to one thread doing single request in a loop. > >> The unwanted certificate switch seems to be related to connection > >> keep-alive behavior. > >> We see the certificate change when server closes the connection after > >> the keep-alive 'max' value decrements down to zero. > >> > >> For example, here are (part of) the response headers leading up to > >> the certificate switch: > >> > >> HTTP/1.1 304 Not Modified > >> Connection: Keep-Alive > >> Keep-Alive: timeout=10, max=2 > >> > >> HTTP/1.1 304 Not Modified > >> Connection: Keep-Alive > >> Keep-Alive: timeout=10, max=1 > >> > >> HTTP/1.1 304 Not Modified > >> Connection: close > >> > >> ============ NEXT REQUEST IS ISSUED WITH A DIFFERENT CERT =========== > >> > >> HTTP/1.1 200 OK > >> Keep-Alive: timeout=10, max=500 > >> Connection: Keep-Alive > >> > >> On Tue, May 6, 2014 at 6:21 AM, UBIK LOAD PACK Support > >> <[email protected]> wrote: > >> > Hello, > >> > Can you show the structure of your Test ? > >> > Maybe open a bug with the Test Plan simplified . > >> > > >> > Clearly regarding "https.use.cached.ssl.context to true seems to be do > >> > better", this does not work as it leads to sharing the certificate > >> between > >> > users. > >> > > >> > Regards > >> > > >> > > >> > On Tue, May 6, 2014 at 12:34 AM, RP Schell <[email protected] > >> >wrote: > >> > > >> >> > >> >> Thanks for the feedback! > >> >> > >> >> Yup, as stated I have tried https.use.cached.ssl.context=false, > >> >> HttpClient4, and https.sessioncontext.shared=false without success. > >> >> Setting https.use.cached.ssl.context to true seems to be do better > >> >> because the user switching does not happen as frequently, but it > still > >> >> happens setting that option to true or false. > >> >> > >> >> In answer to your question, we typically put the keystore > >> >> configuration under the test plan itself at the same level as the > >> >> thread group that is being defined. The plan itself only defines a > >> >> single thread group. We have tried putting the keystore > configuration > >> >> under the thread group itself. THIS MAKES NO DIFFERENCE. Putting it > >> >> at the top level or under the thread group when there is only one > >> >> thread group defined has the same behavior. > >> >> > >> >> I had not tried using the keystore configuration with a CSV data set > >> >> configuration. Thanks for that suggestion. I tried an experiment > >> >> with that. The CSV allows the control of the what certificate is > used > >> >> and in what order. However, it does not solve the ultimate problem > of > >> >> JMeter switching users. The CSV data set configuration simply causes > >> >> JMeter to switch users as defined in the order of the CSV instead. > >> >> > >> >> I am seeing a pattern emerge from using the CSV though. Our test > >> >> users are numbered chronologically (e.g., user0, user1, user2, user3, > >> >> etc). Every 5 loops through the JMeter test, the user identified is > 5 > >> >> numbers higher than before. For example, the test starts at coming > in > >> >> as user 0. On the 5th looping of the test in that thread group, the > >> >> user is now identified as user 4, and we start getting errors because > >> >> the server expected us to still be user 0. > >> >> > >> >> Again, it looks like JMeter is switching users on me when it restarts > >> >> the looping of the test plan. How do we control this. It seems none > >> >> of the options I have mentioned trying allow for it. Thanks! > >> >> > >> >> -Bill > >> >> > >> >> On Tue, Apr 29, 2014 at 4:12 PM, UBIK LOAD PACK Support > >> >> <[email protected]> wrote: > >> >> > Hello, > >> >> > As per: > >> >> > > >> >> > >> > http://jmeter.apache.org/usermanual/component_reference.html#Keystore_Configuration > >> >> > > >> >> > > >> >> > https.use.cached.ssl.context must be set to false and httpclient4 > >> must be > >> >> > used > >> >> > Don't use: > >> >> > https.sessioncontext.shared=false > >> >> > > >> >> > Also it is much better since 2.11 to use : > >> >> > Variable name holding certificate aliasVariable name that will > contain > >> >> the > >> >> > alias to use for authentication by client certificate. Variable > value > >> >> will > >> >> > be filled from CSV Data Set for example. In the screenshot, > >> >> > "certificat_ssl" will also be a variable in CSV Data Set.False > >> >> > Read doc on start and end index to be sure you configure them > >> correctly > >> >> > > >> >> > You speak about different thread groups, where do you put keystore > >> >> config ? > >> >> > > >> >> > Regards > >> >> > @ubikloadpack > >> >> > On Tuesday, April 29, 2014, RP Schell <[email protected]> > >> wrote: > >> >> > > >> >> >> Hey everyone, > >> >> >> > >> >> >> We are attempting to simulate a large user > > > > > > > > -- > > Cordialement. > > Philippe Mouawad. > > Ubik-Ingénierie > > > > UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/> > > > > UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cordialement. Philippe Mouawad.
