생방송 산업이 급속도로 발전함에 따라 생방송 공간의 안정성과 사용자 경험이 생방송 플랫폼 경쟁에서 중요한 요소가 되었습니다. 그러나 생방송실에는 영상 전송, 네트워크 통신, 데이터 처리 등 복잡한 기술 링크가 많이 포함되어 있으므로 생방송실의 성능 스트레스 테스트가 특히 중요합니다. 클라이언트 라이브 방송실의 스트레스 테스트 실행에서 APM 스트레스 테스트 기술은 일반적으로 사용되는 성능 테스트 방법입니다. 애플리케이션 성능의 실시간 모니터링 및 진단을 통해 성능 병목 현상을 신속하게 찾아 해결하고 라이브의 안정성을 확보할 수 있습니다. 방송실 및 사용자 경험이 향상될 수 있습니다.
라이브 방송실의 안정성을 보장하고 사용자 경험을 개선하며 시스템 병목 현상을 발견하고 시스템 성능을 최적화하려면 APM 스트레스 테스트가 매우 중요하다는 것을 알 수 있습니다.
요약하자면 부하 테스트, 대역폭 테스트, 성능 테스트, 보안 테스트, 신뢰성 테스트 등의 스트레스 테스트 방법을 통해 생방송실의 성능, 안정성, 보안 및 신뢰성을 종합적으로 평가하여 라이브 방송실은 사용자의 요구와 기대를 충족시킬 수 있습니다.
듀 라이브 방송실에서 사용하는 주요 스트레스 테스트 방법은 부하 테스트와 성능 테스트입니다.
우선 저희의 스트레스 테스트 목표는 [생방송 방 기반 IM 성능 스트레스 테스트]입니다. 클라이언트가 오랫동안 많은 수의 IM 메시지를 수신합니다. 지연, 충돌 또는 OOM과 같은 성능 문제가 발생합니까? 성능 문제가 온라인으로 발생하는 것을 방지하기 위해 각 릴리스 전에 스트레스 테스트를 실행하여 라이브 방송실의 성능 문제를 오프라인으로 미리 노출시킵니다.
구체적인 스트레스 테스트 방법과 관련하여 우리는 다음 조건을 충족하기를 희망합니다.
위의 요구 사항을 기반으로 스트레스 테스트 방법을 탐색하는 동안 우리 생방송 비즈니스 그룹은 아마도 다음 세 단계를 거쳤을 것입니다.
생방송 방 스트레스 테스트의 첫 번째 단계는 비교적 간단한 방법을 채택하여 사용자가 방에 댓글, 좋아요 등을 보내는 것을 시뮬레이션합니다. 스트레스 테스트를 받아야합니다. 해당 Python 코드를 직접 작성하고 해당 IM 메시지를 라이브 방송방에 보내야 합니다. 다음은 Python 스크립트의 일부입니다.
class APIUtils:
""" 仅适用于测试环境 """
@staticmethod
def token(user_id: int):
resp = requests.get('https://xxxx.com', params={'user_id': user_id})
return resp.json().get('token')
@staticmethod
def change_rc_im(user_id: int):
try:
im_info = requests.post(
'http://xxxx.com',
headers={'userId': '1'},
data={'kolUserId': user_id}
)
im_id = im_info.json().get('data', {}).get('list', [{}])[0].get('id', 0)
requests.post(
'http://xxxx.com',
headers={'userId': '1'},
data={'kolUserId': user_id, 'id': im_id}
)
except:
pass
time.sleep(3)
data = {
"startTime": int(time.time()) + 1,
"endTime": int(time.time()) + 600 * 6,
"kolUserId": user_id,
"imSwitch": 1,
"id": 0
}
requests.post('xxxx.com',
headers={'userId': '1'}, data=data)
@staticmethod
def get_topic(user_id: int, room_id: int):
""" 获取房间号 """
headers = {
'POIZON-USERID': str(user_id),
'POIZON-ISGUEST': 'false',
'platform': 'iPhone',
'v': '4.78.0'
}
try:
resp = requests.get('xxxx.com',
headers=headers, params={'roomId': room_id})
return resp.json().get('data').get('room').get('imInfo').get('chatRoomId')
except Exception as e:
raise e주요 프로세스는 다음과 같습니다.
이런 방식으로 구현된 스트레스 테스트는 상대적으로 간단하고 일부 중요한 IM 메시지도 다룰 수 있지만 몇 가지 명백한 단점도 있습니다. 방 ID나 IM 주제의 경우 이 정보를 얻으려면 패킷을 캡처하거나 방송 기록을 확인해야 하는데, 이는 상당히 번거로운 작업입니다.
이를 바탕으로 조정 인터페이스는 백엔드에 스트레스 테스트가 필요한 방을 알려주고 백엔드는 해당 방의 스트레스 테스트를 위해 첫 번째 단계 스크립트를 호출하도록 요청받습니다. 
이 방법은 방 ID를 수동으로 얻는 수고를 덜어줍니다. 이 시각적 모의 플랫폼을 만들 때 모의 IM 기능이 추가되며 스트레스 테스트와 거의 관련이 없습니다. 스크립트에서 구현한 스트레스 테스트 방법에는 차이가 없습니다. 
이 단계에서는 위에서 언급한 메시지 유형 적용 문제를 기능 반복으로 해결하는 동시에 수동 개입을 더욱 자유롭게 하기 위해 Teslalab 자동화 플랫폼을 기반으로 UI 스크립트를 사용합니다. 정기적으로 작동하려면 압력 측정 기능이 진정한 자동 압력 측정 기능을 구현합니다. 각 단계의 구체적인 작업은 아래에 각각 설명되어 있습니다
4.3.1 메시지 유형 적용 범위클라이언트의 모든 IM 메시지 유형에는 해당 IM 메시지 Java 클래스가 있으며 각 추가 IM 메시지 유형에는 엔터티 클래스가 있습니다. 이러한 클래스는 모두 기본 클래스 BaseLiveChatMessage에서 상속되므로 BaseLiveChatMessage에 인터페이스 추상 메서드를 추가하여 이 메시지 유형의 모의 데이터를 생성합니다.
那么我们在新加IM数据的时候，继承BaseLiveChatMessage，就需要强制覆盖这个方法，去生成自己的mock消息，非常好的解决了维护性的问题，因为不覆盖这个mock方法是无法通过编译的。
下面是警告消息和抽奖消息的Mock代码：
有了上面的基础，在测试工程里面加一个IMTest测试类，主要逻辑是扫描所有继承BaseLiveChatMessage类的子类，然后反射构造函数，调用mock接口即可获取到相应IM类的mock消息实体，伪代码如下：
//获取BaseLiveChatMessage子类
if (allSubClass == null) {
allSubClass = ClassUtils.getAllSubClass(BaseApplication.getInstance(), BaseLiveChatMessage::class.java)
val iterator = allSubClass?.iterator()
while (iterator?.hasNext() == true) {
val next = iterator.next()
try {
next.getDeclaredMethod("mock", Int::class.java)
} catch (e: NoSuchMethodException) {
}
}
}
// ....
allSubClass?.forEach {
val o = constructorMap[it]?.newInstance() as BaseLiveChatMessage
var message: BaseLiveChatMessage? = null
message = o.mock(0)
justPostIM(message) //发送IM
}之后的压测就是控制发送频率、压测时间即可实现本地的压测，无需依赖服务端实现。
到此为止，基本已经解决了文章最开始的几个问题，IM消息的覆盖率和可维护性也得到了保证。
在现有的基础上，为了使得压测更加自动化，我们接入了Teslab自动化测试平台，可以定时启动自动化UI脚本，提升压测效率，自动化脚本是基于UiAutomator，语法非常简易，维护成本很低。
综上，第三阶段的压测策略通过客户端发起的方式，实现了IM压测使用方式方便、支持多设备压测和压测指标有记录的目标。同时，我们还需要在实际实施过程中不断优化和改进，以进一步提高压测效率和结果的可靠性。
压测流程图：
压测只是一个手段，最重要的是发现问题，解决问题，通过三个阶段的压测也发现了不少问题。
3단계의 스트레스 테스트를 통해 팀은 일부 iOS 문제를 성공적으로 발견하고 해결했습니다. 그 중 가장 중요한 점은 스트레스 테스트가 20분 이상 지속되자 CPU가 비정상적으로 높아져 인터페이스가 멈췄다는 점이다. 조사 결과, 메시지가 비즈니스 계층에 하나씩 배포되어 과도한 CPU 소비와 너무 빈번한 UI 새로 고침(초당 최대 수십 회)으로 인해 문제가 발생한 것으로 나타났습니다. 이 문제를 해결하기 위해 팀은 두 가지 솔루션을 채택했습니다. 하나는 메시지를 하나씩 배포하는 대신 타이머를 통해 메시지 그룹을 비즈니스 계층에 배포하는 것이고, 다른 하나는 타이머 내에서 스레드 전환을 수행하여 스레드 전환이 하나만 있도록 하는 것입니다. 일정 기간 내에.
또한 스트레스 테스트 중 지속적인 메모리 증가로 인한 OOM 상황도 발견했는데, 그 이유는 일부 IM에서 일정 시간에 한 번만 실행되는 애니메이션 실행 시간이 있기 때문입니다. 동시성이 높은 상황에서는 계속해서 누적되어 메모리 오버플로가 발생합니다. 이 문제를 해결하기 위해 팀에서는 메모리 오버플로를 방지하는 애니메이션 실행 최적화 솔루션을 채택했습니다.
또한 팀은 kylin 구성 요소를 통해 여러 가지 메모리 누수 문제를 발견하고 적시에 해결하여 생방송 애플리케이션의 안정성과 신뢰성을 보장했습니다. 즉, 3단계의 스트레스 테스트를 통해 팀은 여러 문제를 성공적으로 발견하고 해결했으며, 이는 애플리케이션의 성능과 안정성을 향상했을 뿐만 아니라 팀의 기술 축적과 개발에 유용한 경험과 영감을 제공했습니다.
성능 스트레스 테스트는 실로 생방송실의 안정적이고 효율적인 운영을 보장하는 중요한 수단이지만, 이를 코드 개발의 끝이라고 볼 수는 없습니다. 좋은 코드는 팀 전체가 유지 관리할 수 있어야 합니다. 코드의 가독성, 유지 관리 가능성 및 확장성도 똑같이 중요합니다. 개발 및 유지 관리 과정에서 코드 품질과 팀 협업에 지속적으로 집중해야만 생방송실이 사용자에게 계속해서 고품질 서비스를 제공할 수 있습니다.
생방송실에서 성능 스트레스 테스트를 진행하면서 코드의 가독성과 유지관리성에도 주의를 기울여야 합니다. 코드의 신뢰성과 확장성을 보장하기 위해 코드 품질을 모니터링하고 제어하는 엄격한 코드 검토 메커니즘을 확립해야 합니다. 동시에 팀 협업에 중점을 두고 팀 내 소통 및 협력 메커니즘을 구축하여 팀원들이 공동으로 라이브 방송실을 유지하고 더 나은 사용자 경험을 제공할 수 있도록 합니다.
위 내용은 Dewu 클라이언트 라이브 방송실 APM 스트레스 테스트 실습의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
