On 09/11/2007, kingt <[EMAIL PROTECTED]> wrote: > > > > sebb-2 wrote: > > > > On 09/11/2007, kingt <[EMAIL PROTECTED]> wrote: > >> > >> Dear all, > >> > >> As I need to stress a cluster of Tomcat servers, using a single JMeter > >> seems > >> insufficient. > > > > Have you tried using a single JMeter instance? > > > > Yes, in the previous platform which I use a 2-way SMP P3 machine to drive > > the workload. It seems okay to drive enough load to the cluster of 8 > > machines for some applications. But I will switch to a new platform of P4 > > machines, and the load driver is of same configuration as the web app > > servers, except more RAM. Some applications are based on SOAP and so > > running JMeter on single machine may not be enough to stress the cluster > > of 8 Tomcat servers. Do you have that experience? How many clients are > > required in such a case? Thanks. > > > >> I decide to try the JMeter remote testing. > >> > >> Since I have to test the web application LRU cache behavior, the input > >> sequence of the requests (each would access a cached web object) is > >> important to me. > >> > >> My input parameters carried on the requests are stored in a CSV file - > >> like > >> a proxy trace log. So I used the CSV data config component to drive the > >> workload. I wish to ask - under distributed mode, will each client > >> machine > >> feed alternate requests in coordinated manner or just feed redundant > >> request > >> samples at about the same instant as if each client has the same replica > >> of > >> the CSV file to the cluster? > > > > The CSV file needs to be present on each server host; each server will > > read its own copy. > > > > I suggest you partition the requests so each server exercises its own > > set of URLs. > > > > OIC. Then I feel this "distributed testing" feature is really of no big > > difference with manually having a shell script to start separate jmeter > > instances on different machines. But it has an advantage - merge of > > separate results. But will it give me the total/aggregated throughput and > > average latency, and how (e.g. what listeners and controls I should add > > but not affecting scalability)? Thanks. > >
For minimum overhead, don't configure any Listeners in the test, and use non-GUI client with the -l flag to start a simple listener; use CSV output. Perhaps add a Summariser (see jmeter.properties). The CSV file can be read back in after the test has completed. If this still overloads the client, the run separate non-GUI tests and merge the output files - see: http://wiki.apache.org/jakarta-jmeter/JtlFiles > >> Below example is to make it clear, suppose 3 remote clients are used and > >> the > >> CSV list is > >> A > >> B > >> C > >> D > >> E > >> F > >> .... > >> > >> Which of the following patterns will the request injection be: > >> Client0 Client1 Client2 Client3 > >> ------ ------- ------ ------- > >> A B C D > >> E F G H > >> ... > > > > No > > > >> > >> or > >> > >> Client0 Client1 Client2 Client3 > >> ------ ------- ------ ------- > >> A A A A > >> B B B B > >> C C C C > >> ... > > > > Yes > > > >> > >> I am also interested the answer to the same question for other components > >> like cookie manager. > > > > Each server runs independently. > > > > The client JMeter collects and merges sample results from each server, > > but there is no other co-operation between JMeter instances. > > > > It would not make sense for the cookie manager to be shared between > > JMeter instances - indeed cookies are not even shared between threads > > in the same instance, because threads represent separate users. > > > > > > > >> Thanks a lot for your help! > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/JMeter-Distributed-%28Remote%29-Testing-vs.-CSV-Data-Config-tf4778362.html#a13669189 > >> Sent from the JMeter - User mailing list archive at Nabble.com. > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > View this message in context: > http://www.nabble.com/JMeter-Distributed-%28Remote%29-Testing-vs.-CSV-Data-Config-tf4778362.html#a13671138 > Sent from the JMeter - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
