30 Q& a Three How to Build a Network Architecture for Testing

30 Q&A Three- How to Build a Network Architecture for Testing #

Hello, I am Wen Ming.

Up to now, in the OpenResty third edition section on testing, we have completed our study. Congratulations on not falling behind and still actively learning and practicing, as well as leaving your thoughts enthusiastically.

Many of the questions raised in the comments are very valuable. I have already replied to most of them in the app. I have collected some questions that are not convenient to reply to on mobile or are more typical and interesting, and am addressing them as today’s Q&A content, to reply to them collectively. On the other hand, this is also to ensure that no one misses any key points.

Now let’s take a look at today’s five questions.

Question 1: How to set up a test network structure? #

Q: Should the wrk client be placed on a machine in the public network or on a machine in the same local network as the server? Which option has more significance for performance testing?

A: Actually, choosing the right testing tool is just the beginning for testing web-related services. Building a test network structure is also an important step.

Generally speaking, we want to eliminate all network interference and test the performance limit of the service separately. For this purpose, there are two methods to set up a network for load testing.

The first method is to deploy both the wrk client and the server program on the same high-performance machine. For example, we can enable 8 workers in Nginx and allocate the remaining CPU resources to wrk. In this way, there is only local network communication, minimizing the impact of the network.
The second method is to set up a local area network using a dedicated router, connecting the machine with the wrk client and the machine with the server.

The reason why it is not recommended to test directly in the existing network is that most networks have switches and firewalls that may restrict high-volume load testing, leading to inaccurate test results.

Furthermore, when it comes to performance testing tools, I would like to mention a few more things. Performance testing tools may have Coordinated Omission issues, so you need to pay special attention when analyzing the latency data.

In simple terms, Coordinated Omission refers to the fact that when conducting stress tests, it is not enough to only measure the time between sending a request and receiving a response. This only represents the service time, and there can be many potential issues overlooked by such measurement. Therefore, we also need to take into account the waiting time for test requests as a whole, which is the overall response time that users care about. Of course, if your server program is prone to blocking, you must consider this issue; otherwise, it can be ignored.

Question 2: Can `test::nginx` test SSL-related functionality? #

Q: Can test::nginx test SSL-related functionality?

A: The fact is, test::nginx can indeed test SSL-related functionality. You can refer to this test case file in the apisix repository, which tests the entire process of SSL certificate. In this test case, you can see the use of Lua code to read the public and private keys of the local certificate, then set up the certificate through the http API, and finally use cosocket to perform SSL handshake and access, in order to verify the effectiveness of the certificate.

In fact, not only SSL, but any functionality included in OpenResty can be covered using test::nginx.

When you are unsure whether a certain functionality can be implemented using test::nginx, you can first search in the test case collections of lua-nginx-module and other OpenResty open-source projects. Usually, you can find corresponding examples there. I also use this method to solve such problems, because the playfulness and versatility of test::nginx are quite high, and there are always some unexpected combinations and clever tricks waiting for you to explore.

Question 3: What exactly is DSL? #

Q: Does DSL translate to “Domain Specific Language”? The article mentions that it is a “small language,” but when I searched for it, I only found “Domain Specific Language” as the translation for DSL.

A: DSL does indeed stand for Domain Specific Language, and “small language” is a colloquial term for DSL. The reason for adding the word “small” is because the purpose of DSL is different from that of commonly used programming languages. It is not designed to address general domain requirements but rather to address specific needs within a domain. The most famous DSL is SQL, which is used in the database domain.

As for test::nginx, it is actually a DSL created to fulfill the testing requirements of Nginx and OpenResty. In fact, the author of OpenResty has invented many small languages, and this approach of using DSLs will bring about new attempts and solutions within the OpenResty community. However, as mentioned earlier in the article, DSLs are a double-edged sword, and the main criterion for assessing the value of a DSL is whether it can improve productivity for end users.

Question 4: Installation Issue of `test::nginx` #

Q: After executing git clone, do I need to execute the following commands to install test::nginx?

cd test-nginx
perl Makefile.PL
make
sudo make install

A: In fact, it is not necessary. Here you can refer to the practice of Travis in some open source projects.

First, install through package manager: https://github.com/iresty/apisix/blob/master/.travis/linux_runner.sh#L20

sudo cpanm --notest Test::Nginx >build.log 2>&1 || (cat build.log && exit 1)

Second, clone the latest test::nginx: https://github.com/iresty/apisix/blob/master/.travis/linux_runner.sh#L35

git clone https://github.com/openresty/test-nginx.git test-nginx

Third, when using the prove command, include the test nginx directory:

prove -Itest-nginx/lib -r t

As mentioned earlier, the best installation guide for OpenResty and its peripheral projects can be found in their Travis CI, rather than in the documentation. This may differ from the practices of other projects because OpenResty maintains forks or specific versions of some peripheral projects. At the same time, OpenResty strongly relies on Travis CI. Therefore, you should use and test OpenResty according to the methods outlined in Travis CI to ensure consistency with the official version.

Question 5: Is the ab testing tool really good to use? #

Q: How come I remember that Chun Ge (uncle Chun) mentioned several times in the Google Groups that ab is currently the best testing tool?

A: As mentioned in the article, in terms of tool features alone, ab is not a good performance testing tool. This is because it cannot generate sufficient request pressure, while server-side program performance is already very powerful. We do use ab in test::nginx instead of wrk because in TEST_NGINX_BENCHMARK mode, test::nginx will select ab or weighttp as the stress testing tool based on the HTTP protocol version.

Additionally, I hope you notice that the Internet technology is evolving rapidly, and each of us needs to update our knowledge and skills in a timely manner. For example, in my opinion, the choice of test::nginx needs to be updated now, while Chun Ge might not have known about the existence of wrk at that time. Of course, there may be better performance testing tools than wrk that will appear in the future, and we should naturally approach them with an open and positive mindset to learn and choose.

Today, I mainly answered these questions. Finally, feel free to continue writing your questions in the comments section, and I will continue to answer them. I hope through communication and Q&A, I can help you translate what you have learned into practical results. You are also welcome to share this article so that we can communicate and progress together.