Himanshu Ghai wrote:
:-) i am yet to see an app that worked so well in first go..
I have on a couple of occasions but in those cases performance was taken
seriously from the beginning and integrated into the development process.
i'd
still contend it's not irrelevant..how do you know when it breaks
at 6000, if after 5000 it degraded drastically or after 50?
for when you're testing what is expected to have more noise
5000/500 or 50?
what if it didn't even like 5 users and you bombed it with 5000..
The last benchmark I did I was asked to evaluate the maximum number of
idle sockets we could keep open. The max in RedHat is 1,000,000 (limited
by a the size of bit map compiled into the kernel) and we reached that
number in the first benchmark run. I wouldn't have finished if I had
taken a more conservative route. In cases where the application broke
before we could stabilize at the desired load it more useful to see it
break then it was to see at which level it would function. I don't see
any point in dancing around the question at hand ;-)
I should add that the Apache Mina guys deserve many kudos. That
framework was the basis for the benchmark and it is rock solid!
Regards,
Kirk
Cheers,
Himanshu
On Wed, May 6, 2009 at 11:46 PM, kirk <k...@kodewerk.com> wrote:
Himanshu Ghai wrote:
"Why take the low road. If the requirement is for 6000, test for 6000.
If it works, you're done without all the extra testing."
i differ, if the system isn't deployed yet and breaks at 6000, it is
advisable to see if it scales a lower load..
How do you know that it will break at 6000 unless you test it at that load
level? Why waste time running tests that will give you irrelevant
information? Why not test at 6000 and if anything happens to break, then
investigate? IME this is a much more effective way to test for performance
requirements.
Cheers,
Kirk
it helps to segregate problem as well without adding extra noise of
system resources/network/client
Himanshu
On Tue, May 5, 2009 at 11:20 PM, kirk <kirk.pepperd...@gmail.com> wrote:
it would be recommended to run it for less number of users first to see
if
your servers can handle such load..100/500/1000
Why take the low road. If the requirement is for 6000, test for 6000. If
it
works, you're done without all the extra testing. If it doesn't work then
you have a different problem
Regards,
Kirk
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
