Return-Path: X-Original-To: apmail-jmeter-user-archive@www.apache.org Delivered-To: apmail-jmeter-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BD3F695A0 for ; Fri, 15 Jun 2012 08:07:03 +0000 (UTC) Received: (qmail 82768 invoked by uid 500); 15 Jun 2012 08:07:03 -0000 Delivered-To: apmail-jmeter-user-archive@jmeter.apache.org Received: (qmail 82381 invoked by uid 500); 15 Jun 2012 08:07:02 -0000 Mailing-List: contact user-help@jmeter.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "JMeter Users List" Delivered-To: mailing list user@jmeter.apache.org Received: (qmail 82350 invoked by uid 99); 15 Jun 2012 08:07:01 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Jun 2012 08:07:01 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FSL_RCVD_USER,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dmwmailinglist@gmail.com designates 209.85.212.173 as permitted sender) Received: from [209.85.212.173] (HELO mail-wi0-f173.google.com) (209.85.212.173) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Jun 2012 08:06:55 +0000 Received: by wibhj6 with SMTP id hj6so237607wib.8 for ; Fri, 15 Jun 2012 01:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=jtMUCpOuUJ5gYwWy9lC0pCjPbOVpSxrYCLUHlhmYg0o=; b=oqe7YhHSEg+KIrsmc8TimCGQ/z7oKvFRB2+ujcWbaKMkqDGklUGFC4JSKeLGgGW/Zl vInq01/ASKLAwgJHb8q8kJCxkw5h5Qy1HgWognG8xjVOF34bBx3kkNP2DLX4veJEMyU+ gEQbqVSkHm8e2zuhtZs4wEIN+ZoJI1gM1v77Oi+F49hx/Oodvo57v7/eTKSZ/ykJfge+ don4RwRC2M3x9DWUShaVgb5SdGDit2HWV8lzsSFCbQ1lWrgXCzRrNUceMeNKd0+VY5L6 GwwH34DvzXIpsTBA3hIjFWelPVEfazw/vYraKbUmz2ZbqhKIe49TdyO54u7pF6pTJsZG WnnA== MIME-Version: 1.0 Received: by 10.180.83.197 with SMTP id s5mr2238572wiy.9.1339747593639; Fri, 15 Jun 2012 01:06:33 -0700 (PDT) Received: by 10.180.84.1 with HTTP; Fri, 15 Jun 2012 01:06:33 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Jun 2012 10:06:33 +0200 Message-ID: Subject: Re: JMeter threading model From: D G To: JMeter Users List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Details are very welcome as I'm still not sure whether I fully understand the problem :) Thread pooling does sound nice and it might enable a feature I'd like: On-demand creation of threads. Say you're looping 10 threads, system is under no load. Currently: if you want 10 more users you need to stop the test, add 10 users and start it again. It would be nice if it where possible to simply say '+10', followed by some monitoring and then another '+10' (30 threads running total) etc. (10 is an example number, +/- n users would be the goal) Mostly for the 'getting a feel for the system' part of the test, the initial setup of it all. Regards, Daniel On Fri, Jun 15, 2012 at 7:24 AM, Kirk Pepperdine wrote: > Hi, > > I'm very happy to add details if need be. > > Regards, > Kirk > > On 2012-06-15, at 12:13 AM, Philippe Mouawad wrote: > >> Bugzilla created: >> >> =A0 - https://issues.apache.org/bugzilla/show_bug.cgi?id=3D53418 >> >> >> Regards >> >> Philippe M. >> >> On Thu, Jun 14, 2012 at 10:30 PM, Philippe Mouawad < >> philippe.mouawad@gmail.com> wrote: >> >>> Hi M. Pepperdine, >>> >>> On Wed, Jun 13, 2012 at 7:05 AM, Kirk Pepperdine < >>> kirk.pepperdine@gmail.com> wrote: >>> >>>> Hi Sebb, >>>> >>>> We've had this conversation before and I did some preliminary work to >>>> setup a different type of thread group but the couplings between the >>>> existing thread group and the model meant that an extensive refactorin= g >>>> would be involved. Since that involves a *lot* more than just a simple >>>> plugin... >>>> >>>> So, the current implementation supports a closed system model meaning, >>>> rate of entry into the system equals rate of exit from the system.This= is >>>> exactly what you want if you're load testing a call centre where the n= umber >>>> of servers (operators) is fixed and gate entry into the system. Howeve= r, >>>> I'm often simulating open systems which means I do not want rate of en= try >>>> into the system to be controlled by the performance of the system (rat= e of >>>> exit). >>> >>> What makes you think JMeter does this ? >>> >>> >>>> More over, those that attend my performance tuning seminars come to >>>> understand why this is an important aspect of getting your test enviro= nment >>>> right and test harness correctly setup as it can adversely affect the >>>> quality of your test which can and often does, change the results of t= he >>>> test. >>>> >>> >>>> As an example, today I will show a group how to tune an application by= a >>>> partner company. That application has a number of "performance problem= s" >>>> backed into it. If I use the traditional means of using JMeter I will = find >>>> a different set of performance issues than if I load with a pattern th= at is >>>> similar that found in production. >>> >>> Can you clarify this point ? a figure might be better than a long text >>> >>> >>>> In other words, with this particular application, JMeter exposes >>>> "problems" that are artifacts of how it wants to inject load on a syst= em. >>> >>> Not clear for me. >>> >>> I can fix all of these problems >>> >>> What are these problems ? and how do you fix these ? >>> >>> >>>> and eventually I'll get to a point where I'll fix everything that need= s >>>> to be fixed. That said, if I can coerce JMeter to load as an open syst= em >>>> I'll get to the problems without having to fix the artifacts (the thin= gs >>>> that really don't need fixing). >>> >>> Still not clear >>> >>>> To coerce JMeter into being an open system requires one to use a large >>>> number of very short lived threads. So I may only have 400-500 active >>>> threads at any point in time but in order to achieve that load over a = 1 or >>>> two hour test I may have to specify 10s of thousands of threads. Since= all >>>> of the threads are created up front, this simply doesn't work. >>>> >>>> You might ask why not just specify 400-500 threads and loop over them?= in >>>> theory you'd think it would work but as you tune the system and the >>>> performance characteristics change. Going back to the baked applicatio= n, >>>> before I start tuning, the active user count is several thousand. In o= ther >>>> words, the tuned system is better able to clear users out and that cha= nges >>>> the performance profile in a way that hard to emulate with the current >>>> looping behaviour. Using a setting of looping 400 or so threads isn't >>>> adequate for the initial load tests as the test harness will become th= read >>>> starved and that releases pressure on the server which in turn changes= the >>>> performance profile. >>>> >>> >>> >>>> With all due respect to the wonderful work that everyone on the projec= t >>>> has done, it is my opinion that the one user =3D=3D one thread is a de= sign >>>> mistake that has a huge impact on both the usability of the tool >>>> >>> Examples ? >>> >>>> and the quality of the results >>> >>> I disagree with this assertion . We have been using JMeter for load >>> testing all kind of applications Intranets / Large ECommerce Systems / >>> Backoffice systems / , and quality of results is good provided you >>> configure it properly. >>> Particularly when using Remote =A0Testing. Lot of users in this mailing= list >>> use it and are satisfied (I think). >>> >>> >>>> one can achieve when using it. IMHO, moving to an thread pool/event he= ap >>>> based model would be an enormous improvement over the current >>>> implementation. >>>> >>>> Agree it would be better. We will work on it. >>> >>>> Regards, >>>> Kirk >>>> >>>> On 2012-06-13, at 1:02 AM, sebb wrote: >>>> >>>>> On 12 June 2012 22:57, Kirk Pepperdine >>>> wrote: >>>>>> >>>>>> On 2012-06-13, at 12:54 AM, sebb wrote: >>>>>> >>>>>>> On 12 June 2012 22:06, Kirk Pepperdine >>>> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I figured thread pooling would be revolutionary so I wasn't >>>> suggesting that. I would be very useful just delay the creation of a t= hread >>>> until it was asked for. >>>>>>> >>>>>>> Not sure I understand how it would help to delay the thread creatio= n, >>>>>>> except perhaps for the case where the first threads have finished >>>>>>> processing by the time the last threads start running samples. >>>>>> >>>>>> Bingo!!! ;-) >>>>> >>>>> So what percentage of use cases need to follow this model? >>>>> >>>>> Most of the JMeter testing I have done was long running tests where >>>>> all threads were active for most of the run. >>>>> >>>>>> Kirk >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------= - >>>>>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org >>>>>> For additional commands, e-mail: user-help@jmeter.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org >>>>> For additional commands, e-mail: user-help@jmeter.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org >>>> For additional commands, e-mail: user-help@jmeter.apache.org >>>> >>>> >>> >>> >>> -- >>> Cordialement. >>> Philippe Mouawad. >>> >>> >>> >>> >> >> >> -- >> Cordialement. >> Philippe Mouawad. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org > For additional commands, e-mail: user-help@jmeter.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org For additional commands, e-mail: user-help@jmeter.apache.org