Quality is delighting customers
In that kind of case you should never use the graphical user interface for large amount of connections. When I'm doing that kind of testing, I usually have following kind of setup:
1) "Control machine" (or process) which is running about 20 threads and GUI with some view which shows unique response times. E.g. table view is quite nice.
2) Then the main plan is executed from the command line. It depends a bit how much you expect the server to stand what kind of ramp up time I'm using. If you are expecting it to work with around 100 concurrent threads, then put the ramp up to at least half hour. If you are expecting it so stand a lot more, then I'd use JMeter-plugins.
Log everything you can to CSV-file. It helps you to do more detailed analyze with Excel.
From the "control machine" I'd check from the user interface how system is behaving. When there starts to be huge delays or plenty of error cases, I'd stop the testing. Then import logs to the Excel and start investigating what was the breaking point.
Can you be more specific ? espesially the point 2 .
please tell me with an example .
actually my target is ,identify the cocurrent user level/max load that can afford while running request under a server
JMeter provides a number of Assertions to ensure that response matches your expectations. For instance you can use Duration Assertion to mark tests as failed if response time exceeds reasonable threshold or Response Assertion to check status code or whether response contains expected line or doesn't contain words like "error" or "exception".
See How to Use JMeter Assertions in 3 Easy Steps guide for more details on using Assertions in your JMeter test.