{"id":396196,"date":"2024-06-29T12:41:43","date_gmt":"2024-06-29T12:41:43","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=396196"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=396196","title":{"rendered":"Using a headless browser for WebRTC load tests<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n
<\/figcaption><\/figure>\n

In the previous article we went over a load test whose data could be used to choose a load-appropriate server. In the course of the testing, we would publish a stream on one WCS<\/a>, and we would pick up that stream several times using a second WCS. The acquired results could be used as a basis for decisions on server operability. <\/p>\n

Some would (justly) have concerns regarding the possible biases in such a test \u2014 after all, one of our servers was used to test another one of our servers. Could it be that we were using a specially optimized code that skewed the results in our favor? <\/p>\n

It is true that the end user will not use a second server to watch streams. The end user will watch them in browser. This is why, seemingly the simplest and most logical way would involve manual testing: open a browser, open a tab with the player<\/a>, specify the stream name and click «Play;» and then repeat 1000 times. All that’s left is to find a guinea pig<\/s> a volunteer tester and a PC that could handle 1000 tabs with video. Alternatively, and more realistically, the same test could involve a group of people and multiple PCs. Or we could just use scripts.<\/p>\n

In this article we are going to discuss another testing method, one that uses a headless browser. We will compare the test results with the results from the stream capture-based testing<\/a>. <\/p>\n

You can’t leave your head on<\/h3>\n

\u041deadless-browser is something without a head. In the context of the frontend, it is an indispensable developer tool with which you can test code, check the quality and consistency of the layout, programmatically create scenarios of user interaction with the site, followed by fixing the results of these scenarios for use in tests. <\/p>\n

Headless Chrome) is a full-featured browser without a graphical interface, which means it draws everything in memory. Headless Chrome is faster and uses less memory than a regular browser. <\/p>\n

The last statement seems like a contradiction. But the reduction in memory usage is achieved by the absence of a graphical component. The headless browser has no real content rendering, which means that it does not need to render illustrations weighing several gigabytes, with which modern websites are often flooded. At the same time, the headless browser will download all the content from the web page, just like a regular browser.<\/p>\n

Headless Chrome is software-driven using an API and can be installed on «pure» Linux. You just need to install the package, and the browser will work out of the box, just like its brother with a head \u2013 Google Chrome.<\/p>\n

Load testing using Headless Chrome will be closest to reality because it simulates real users connecting to WCS using a browser.<\/p>\n

So here we go.<\/p>\n

WebRTC load test in a headless browser<\/h3>\n

Server under test<\/h4>\n

We will install on the server with the following characteristics<\/p>\n