. NET site architecture time (eight) test
In general, the overall test strategy is: the performance and stress test for some systems, the peak processing performance of each part, and then simulate the overall process testing, at this time not to follow the peak run, focus on testing the overall business process and business expected load.
After defining the test strategy for each part, the specific tool use selection is not the main problem.
1, different provinces, different operators CDN node performance
This section can be used for typical stress testing scenarios.
2, the core room BGP network bandwidth
This part focuses on testing the BGP network reliability, the actual rate, etc., generally using smokeping, Ixchariot and other tools.
3, all kinds of hardware equipment performance
This section generally uses a professional network equipment testing tools.
4, various types of server (Web server, application server, cache server, etc.) concurrency performance, distributed processing power
This section can be used for stress test scenarios and tools.
6, Business system performance
This section can be used for business system stress testing scenarios.
7. Database Processing Performance
Most Internet companies have customized the database to meet business needs, and this part of the test needs to be tested in conjunction with the business system to get the TPS/QPS of the database under the core business scenario, especially where the custom transformation is being tested.
8. Payment channel interface and shunt test
This is probably the biggest bottleneck, and it is a place where Internet companies are unable to take full control, only to coordinate Bank headquarters transformation support.
It also involves testing backup scenarios, disaster-tolerant scenarios, and business downgrade scenarios.
The business downgrade scenario is based on the policy of "lossy service, flexible availability", and the quality degradation of some services to ensure the availability of core services.
Yanagawa
Links: http://www.zhihu.com/question/22216942/answer/78753248
Source: Know
Copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please specify the source. ' When writing a Web service, it is more concerned about how much of this service can be connected, and what kind of interactivity can be achieved on the basis of this connection. Writing services has been a very powerful thing, But also to write a test tool that can reflect the results of more consumption of working time. The following is a test tool that can be easily set up to perform high concurrency and high-swallowing performance tests on the TCP/UDP service, and graphically reflect test results.
Tools are used. NET, it requires the. NET Framework to run. While. NET does not give a good performance in this regard, the performance of this work is sufficient to meet the stress tests of most service-side.
Tool Main Interface
?
The tool is very easy to use and requires only a few items to be tested for a service end. Here's the test mode. Here, the tool mainly provides two test modes, namely
Response Mode : The next request message is sent as soon as the connection receives a service-side response
interval mode : The connection sends a request message according to the interval of time set
Message editing
You also need to add test messages to your work before you start the test, and clear the tools to send those message content to the server
According to their own needs to edit the messages sent, each connection will be the wheel to send these messages to the server, message encoding can also be set according to their own needs. The tools are available in 4 different types: Ascii,utf8,hex and base64.
When the above work is ready, you can click on the test button to test, a few curve chart below the tool will reflect the results of the test process data collection. With these results you will be able to understand the response of the server and the overall throughput of the browsing trend.
What is the pressure of the tool, the following two test cases reflect the testing capabilities of the tool.
Test Case 1
Build a simple TCP service and then build 5,000 connection request tests (test PC is a notebook) in another organization, request message size is 1K; test results are as follows:
From the results of the 5,000 connection request test results reflect that the overall interaction is 6W per second and 6W receive, and the resulting bandwidth up and down line is 60MB, which basically has the test environment 1Gb bandwidth ran out. This is true from the system's resource manager.
Test Case 2
This test mainly set the message sent to 4K, because of the network environment, you can only put the test tools and services on the same PC. and the number of connections tested dropped to 2000
The test results reflect that the socket reads and writes are about 4W, and the bandwidth of the downlink is about 170MB respectively, and the bandwidth is approximately 3-4GB.
HTTP test
The component can also test HTTP, since the test tool is based on a long-connection test, the request description must be in HTTP 1.1 and set keep-alive, and the specific message is set as follows:
Summarize
From the results of the above two test cases, the tool has a very good pressure test efficiency. I believe that most of the TCP/UDP service stress testing work can be done. Due to the random port assignment employed by the work, there is a certain limit on the number of connections created. The following will adjust the manual binding according to the local IP situation, so believe that you can meet some of the need for a large number of connection service testing.
http://blog.liuts.com/post/234/
. NET Web site architecture Design (eight) testing