On 07/06/2008, Michael McDonnell <[EMAIL PROTECTED]> wrote: > I haven't had the opportunity to test each of the nodes in single mode, just > due to the nature of my work place environment (Most of the computers are > locked, I was just given an IP and told that JMeter-server is running.) I > know all the data is in sync because they're all synchronized using > subversion. > > I ran some tests yesterday, comparing server response time (using JAMon) vs > Jmeter's response time, and I found that my results start to diverge at 20 > users (spread out amongst all 7 of the nodes). > > Regardless, I'm almost positive (as I said before) that its because of all > the optimistic locking (because of the situation with subversion, its > impossible right now to adjust the datafiles for everyone) exceptions being > thrown all the time.
If you include the hostname in the filename, then you can have different files for each host. > Since we've aquired a faster machine (dual core, 2 gigs ram...) and set the > heap up on jmeter to like 1024m, that can run it beautifully in single node > mode, I unfortunately have to abandon the distributed test environment. > (Corporate...) > > Thanks much for your time! > > > Michael > > > On Sat, Jun 7, 2008 at 5:35 AM, sebb <[EMAIL PROTECTED]> wrote: > > > You originally wrote that "single user work station ... results come > > back fantastically". > > > > Is that true for all the nodes used individually? > > Or do some nodes struggle? > > > > If all nodes work OK individually, try adding more nodes to the test, > > i.e instead of one node with 300 users, use 2 nodes with 150 users > > each. Try these both completely separately - in non-GUI mode - and in > > client-server mode. > > > > If you can run all the nodes together in non-GUI mode and get the same > > performance as > > a single node with the same total of users, but not when you run in > > client-server mode then there must be a bottleneck in the client. > > > > You also wrote: > > > > "We're load testing a web application, so primarily, the only work we're > > doing is http requests ... > > > > However, when we view the transactions in the database, they are extremely > > low. (frighteningly low)." > > > > This does not make sense. If the http requests directly relate to > > database transactions, then either some requests are not succeeding, > > or there is an error in the test data or the application. You'll need > > to trace the progress of the http request in the server to see why > > some requests are not generating database transactions. > > > > On 06/06/2008, Michael McDonnell <[EMAIL PROTECTED]> wrote: > > > Actually, that's about the exact configuration across all 7 of them. > > > > > > > > > On Fri, Jun 6, 2008 at 9:58 AM, sebb <[EMAIL PROTECTED]> wrote: > > > > > > > On 06/06/2008, Michael McDonnell <[EMAIL PROTECTED]> wrote: > > > > > One would think so, but my response times are terrible, I'm > > wondering if > > > > it > > > > > has anything to do with the fact that its a 1st gen p4. > > > > > (Ubuntu Hardy, 1.5 Gig PC3200 RAM) > > > > > > > > > > > > > What node is that? > > > > > > > > You wrote: > > > > > > > > "Then we run the test from a single user work station (same test, 300 > > users > > > > doing work) and our results come back fantastically!" > > > > > > > > > > > > > > On Fri, Jun 6, 2008 at 9:44 AM, sebb <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > Yes, 300 users should not be a problem as a single JMeter client > > > > > > should be able to handle that. > > > > > > > > > > > > On 06/06/2008, Michael McDonnell <[EMAIL PROTECTED]> wrote: > > > > > > > That makes sense. I'll give it a go. (We're pretty sure there's > > no > > > > bottle > > > > > > > neck passing things, they do it every 100 samples, and this is > > over > > > > a > > > > > > 100 > > > > > > > MB/s net. I'm only trying to run 300 users, so they should be > > able > > > > to > > > > > > > perform well over a 10 MB/s > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 6, 2008 at 9:27 AM, sebb <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > > > > > > > In client-server mode, only the test plan is sent from the > > client > > > > to > > > > > > > > the server(s). > > > > > > > > > > > > > > > > Any additional files - e.g. CSV input files - need to be > > present > > > > on > > > > > > > > the server host in the location specified by the test plan. > > > > > > > > > > > > > > > > Sample data is returned to the client, and processed/stored > > by > > > > the > > > > > > client. > > > > > > > > This can become a bottleneck at the client - both for JMeter > > > > itself, > > > > > > > > and for the network connection - under high loads. > > > > > > > > > > > > > > > > Data files are best randomised before use. > > > > > > > > Likewise, if you want to run with different data on > > different > > > > hosts, > > > > > > > > then create different data files for each host (but you can > > use > > > > the > > > > > > > > same name). > > > > > > > > > > > > > > > > On 06/06/2008, Michael McDonnell <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > How did you randomize the data from the CSVs? (if I may > > ask) > > > > > > > > > > > > > > > > > > Also, I'm dealing with a lot of optimistic locking issues > > > > which > > > > > > would > > > > > > > > only > > > > > > > > > occur if each csv is doing the EXACT same thing at the > > exact > > > > same > > > > > > time > > > > > > > > > (which is completely likely) > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 5, 2008 at 9:54 PM, Ryan Dooley < > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > I had a similar experience the first time. Turns out > > that > > > > the > > > > > > data I > > > > > > > > > > wanted > > > > > > > > > > to test with (HTTP POSTs) has to be put on each remote. > > I > > > > also > > > > > > had a > > > > > > > > > > process to randomize the data when transferred to the > > > > remotes. I > > > > > > > > finally > > > > > > > > > > got the load up high enough across 10 machines like > > yours. > > > > > > > > > > > > > > > > > > > > The test harness I had was pretty simple: post these > > things > > > > to > > > > > > this > > > > > > > > url. > > > > > > > > > > > > > > > > > > > > On Thu, Jun 5, 2008 at 5:19 PM, Michael McDonnell < > > > > > > > > [EMAIL PROTECTED]> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > We're running a distributed test (roughly 7 remote > > > > > > workstations) on > > > > > > > > a > > > > > > > > > > > pretty > > > > > > > > > > > hefty box (8 cores, 32 gigs ram.... etc...) > > > > > > > > > > > > > > > > > > > > > > However, something seems to be going wrong... perhaps > > its > > > > > > because > > > > > > > > I'm > > > > > > > > > > > crossing linux and windows platforms to try to do the > > > > testing? > > > > > > > > > > > > > > > > > > > > > > We're load testing a web application, so primarily, > > the > > > > only > > > > > > work > > > > > > > > we're > > > > > > > > > > > doing is http requests (there are a few "java > > requests" > > > > that > > > > > > > > actually is > > > > > > > > > > an > > > > > > > > > > > app I created to make webservice calls, but we'll get > > to > > > > that > > > > > > later) > > > > > > > > > > > > > > > > > > > > > > However, when we view the transactions in the > > database, > > > > they > > > > > > are > > > > > > > > > > extremely > > > > > > > > > > > low. (frighteningly low). > > > > > > > > > > > > > > > > > > > > > > Then we run the test from a single user work station > > (same > > > > > > test, 300 > > > > > > > > > > users > > > > > > > > > > > doing work) and our results come back fantastically! > > > > > > > > > > > > > > > > > > > > > > Now granted: I guess the big deal is this: when the > > app > > > > uses a > > > > > > csv > > > > > > > > in > > > > > > > > > > > distributed mode, does each slave utilize the the > > same csv > > > > in > > > > > > the > > > > > > > > same > > > > > > > > > > > order > > > > > > > > > > > ? or is there a sort of "break up" so that no two > > slaves > > > > are > > > > > > using > > > > > > > > the > > > > > > > > > > same > > > > > > > > > > > line in the csv? > > > > > > > > > > > > > > > > > > > > > > I'm sorry for what may be dumb questions... but we're > > > > coming > > > > > > down to > > > > > > > > a > > > > > > > > > > > tight > > > > > > > > > > > deadline, and the distributed testing is not giving > > us > > > > good > > > > > > results > > > > > > > > where > > > > > > > > > > > as > > > > > > > > > > > the local testing is. > > > > > > > > > > > > > > > > > > > > > > Thanks for all your help in advance. > > > > > > > > > > > > > > > > > > > > > > Michael > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
