Dewu 클라이언트 라이브 방송실 APM 스트레스 테스트 실습-파이썬 튜토리얼-php.cn

1. 배경

생방송 산업이 급속도로 발전함에 따라 생방송 공간의 안정성과 사용자 경험이 생방송 플랫폼 경쟁에서 중요한 요소가 되었습니다. 그러나 생방송실에는 영상 전송, 네트워크 통신, 데이터 처리 등 복잡한 기술 링크가 많이 포함되어 있으므로 생방송실의 성능 스트레스 테스트가 특히 중요합니다. 클라이언트 라이브 방송실의 스트레스 테스트 실행에서 APM 스트레스 테스트 기술은 일반적으로 사용되는 성능 테스트 방법입니다. 애플리케이션 성능의 실시간 모니터링 및 진단을 통해 성능 병목 현상을 신속하게 찾아 해결하고 라이브의 안정성을 확보할 수 있습니다. 방송실 및 사용자 경험이 향상될 수 있습니다.

APM 스트레스 테스트의 중요성

시스템 안정성 감지: APM 스트레스 테스트는 테스터가 높은 동시성 조건에서 라이브 방송실의 성능과 안정성을 평가하여 시스템이 정상적으로 작동하고 충돌이나 충돌이 발생하지 않는지 확인하는 데 도움이 됩니다. 부조.
사용자 경험 향상: APM 값이 높다는 것은 일반적으로 라이브 방송실에서 더 많은 작업을 원활하게 처리하여 사용자 경험을 향상시킬 수 있음을 의미합니다. APM 값이 낮으면 라이브 방송실에서 정지 및 지연이 발생하여 사용자 경험에 영향을 줄 수 있습니다.
시스템 병목 현상 발견: APM 스트레스 테스트는 테스터와 개발자가 시스템 병목 현상과 문제를 발견하여 목표 최적화 및 개선이 이루어질 수 있도록 도와줍니다. 예를 들어, APM 스트레스 테스트 중에 데이터베이스 읽기 및 쓰기 성능 문제가 발견되면 데이터베이스를 업그레이드하거나 기타 최적화 조치를 취하여 시스템 성능을 향상시킬 수 있습니다.
시스템 성능 최적화: 개발자는 APM 스트레스 테스트를 통해 시스템 성능 문제를 식별하고 목표 최적화를 수행할 수 있습니다. 예를 들어, 로드 밸런싱 기술을 사용하여 트래픽을 분산시킬 수 있고, 캐싱 기술을 사용하여 데이터베이스 로드를 줄이거나, 비동기 처리를 사용하여 시스템의 동시성 기능을 향상시킬 수 있습니다.

라이브 방송실의 안정성을 보장하고 사용자 경험을 개선하며 시스템 병목 현상을 발견하고 시스템 성능을 최적화하려면 APM 스트레스 테스트가 매우 중요하다는 것을 알 수 있습니다.

2. 생방송 방의 일반적인 스트레스 테스트 방법

부하 테스트: 생방송 방에 액세스하는 많은 수의 사용자를 시뮬레이션하여 높은 동시성 조건에서 생방송 방의 성능과 안정성을 테스트합니다. JMeter 또는 LoadRunner와 같은 도구를 사용하여 다양한 부하에서 라이브 방송실의 성능을 평가하라는 사용자 요청을 시뮬레이션할 수 있습니다.
대역폭 테스트: 라이브 방송실은 고화질 비디오의 실시간 전송을 지원하기 위해 충분한 대역폭을 보장해야 하므로, 라이브 방송실에 충분한 대역폭이 있는지 확인하기 위해 대역폭 테스트가 필요합니다. 네트워크 속도 테스트 도구를 사용하여 실제 대역폭과 대역폭의 안정성을 평가할 수 있습니다.
성능 테스트: 다양한 시나리오에서 사용자 액세스를 시뮬레이션하여 동시에 생방송 시청, 동시에 포격 보내기 등 다양한 시나리오에서 생방송 룸의 성능을 테스트합니다. WebLOAD와 같은 성능 테스트 도구를 사용하여 동시 요청을 시뮬레이션하여 다양한 시나리오에서 라이브 방송실의 성능을 평가할 수 있습니다.
보안 테스트: 생방송실에서는 사용자 정보 및 개인정보의 보안이 보장되어야 하므로, 생방송실에 보안 허점이 없는지 확인하기 위한 보안 테스트가 필요합니다. Burp Suite와 같은 도구를 사용하여 침투 테스트를 수행하여 생방송실의 보안을 평가할 수 있습니다.
신뢰성 테스트: 다양한 결함과 비정상적인 상황을 시뮬레이션하여 비정상적인 상황에서 생방송실의 성능과 복구 능력을 테스트합니다. Chaos Monkey와 같은 도구를 사용하면 비정상적인 상황을 시뮬레이션하여 라이브 방송실의 안정성과 복구 기능을 평가할 수 있습니다.

요약하자면 부하 테스트, 대역폭 테스트, 성능 테스트, 보안 테스트, 신뢰성 테스트 등의 스트레스 테스트 방법을 통해 생방송실의 성능, 안정성, 보안 및 신뢰성을 종합적으로 평가하여 라이브 방송실은 사용자의 요구와 기대를 충족시킬 수 있습니다.

듀 라이브 방송실에서 사용하는 주요 스트레스 테스트 방법은 부하 테스트와 성능 테스트입니다.

3. 구현 방법

우선 저희의 스트레스 테스트 목표는 [생방송 방 기반 IM 성능 스트레스 테스트]입니다. 클라이언트가 오랫동안 많은 수의 IM 메시지를 수신합니다. 지연, 충돌 또는 OOM과 같은 성능 문제가 발생합니까? 성능 문제가 온라인으로 발생하는 것을 방지하기 위해 각 릴리스 전에 스트레스 테스트를 실행하여 라이브 방송실의 성능 문제를 오프라인으로 미리 노출시킵니다.

구체적인 스트레스 테스트 방법과 관련하여 우리는 다음 조건을 충족하기를 희망합니다.

가능한 많은 IM 메시지 유형을 다루도록 노력하세요
압력 테스트는 고도로 자동화되어 수동 작업 문제를 더 많이 줄여줍니다.
낮은 유지 관리 비용
압력 테스트는 서버에 의존하지 않습니다. 가능한 한 많이 로컬 측에서 메시지 스트레스 테스트를 직접 구현할 수 있습니다

위의 요구 사항을 기반으로 스트레스 테스트 방법을 탐색하는 동안 우리 생방송 비즈니스 그룹은 아마도 다음 세 단계를 거쳤을 것입니다.

4. 스트레스 테스트 단계

4.1 1단계

생방송 방 스트레스 테스트의 첫 번째 단계는 비교적 간단한 방법을 채택하여 사용자가 방에 댓글, 좋아요 등을 보내는 것을 시뮬레이션합니다. 스트레스 테스트를 받아야합니다. 해당 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

로그인 후 복사

주요 프로세스는 다음과 같습니다.

Dewu 클라이언트 라이브 방송실 APM 스트레스 테스트 실습

이런 방식으로 구현된 스트레스 테스트는 상대적으로 간단하고 일부 중요한 IM 메시지도 다룰 수 있지만 몇 가지 명백한 단점도 있습니다. 방 ID나 IM 주제의 경우 이 정보를 얻으려면 패킷을 캡처하거나 방송 기록을 확인해야 하는데, 이는 상당히 번거로운 작업입니다.

클라이언트 코드가 IM 메시지를 추가할 때마다 해당 IM 번호를 추가하기 위해 Python 스크립트를 수동으로 유지해야 합니다. 나중에 유지 관리가 필요한 학생은 Python을 작성할 수 있습니다. up 유지관리자는 각 버전 반복에 추가된 새로운 IM 메시지를 주도적으로 이해하고 스크립트의 IM 메시지 유형을 사전에 업데이트해야 합니다. 이는 의심할 여지 없이 유지 관리 비용을 증가시킵니다.
4.2 두 번째 단계

이를 바탕으로 조정 인터페이스는 백엔드에 스트레스 테스트가 필요한 방을 알려주고 백엔드는 해당 방의 스트레스 테스트를 위해 첫 번째 단계 스크립트를 호출하도록 요청받습니다. Dewu 클라이언트 라이브 방송실 APM 스트레스 테스트 실습

이 방법은 방 ID를 수동으로 얻는 수고를 덜어줍니다. 이 시각적 모의 플랫폼을 만들 때 모의 IM 기능이 추가되며 스트레스 테스트와 거의 관련이 없습니다. 스크립트에서 구현한 스트레스 테스트 방법에는 차이가 없습니다. Dewu 클라이언트 라이브 방송실 APM 스트레스 테스트 실습

4.3 세 번째 단계

이 단계에서는 위에서 언급한 메시지 유형 적용 문제를 기능 반복으로 해결하는 동시에 수동 개입을 더욱 자유롭게 하기 위해 Teslalab 자동화 플랫폼을 기반으로 UI 스크립트를 사용합니다. 정기적으로 작동하려면 압력 측정 기능이 진정한 자동 압력 측정 기능을 구현합니다. 각 단계의 구체적인 작업은 아래에 각각 설명되어 있습니다

4.3.1 메시지 유형 적용 범위

클라이언트의 모든 IM 메시지 유형에는 해당 IM 메시지 Java 클래스가 있으며 각 추가 IM 메시지 유형에는 엔터티 클래스가 있습니다. 이러한 클래스는 모두 기본 클래스 BaseLiveChatMessage에서 상속되므로 BaseLiveChatMessage에 인터페이스 추상 메서드를 추가하여 이 메시지 유형의 모의 데이터를 생성합니다.

那么我们在新加IM数据的时候，继承BaseLiveChatMessage，就需要强制覆盖这个方法，去生成自己的mock消息，非常好的解决了维护性的问题，因为不覆盖这个mock方法是无法通过编译的。

下面是警告消息和抽奖消息的Mock代码：

Dewu 클라이언트 라이브 방송실 APM 스트레스 테스트 실습

有了上面的基础，在测试工程里面加一个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
}

로그인 후 복사

之后的压测就是控制发送频率、压测时间即可实现本地的压测，无需依赖服务端实现。

Dewu 클라이언트 라이브 방송실 APM 스트레스 테스트 실습

到此为止，基本已经解决了文章最开始的几个问题，IM消息的覆盖率和可维护性也得到了保证。

4.3.2 自动化

在现有的基础上，为了使得压测更加自动化，我们接入了Teslab自动化测试平台，可以定时启动自动化UI脚本，提升压测效率，自动化脚本是基于UiAutomator，语法非常简易，维护成本很低。

Dewu 클라이언트 라이브 방송실 APM 스트레스 테스트 실습

客户端内部备齐所有的IM压测类型。在进行IM压测时，客户端应当支持各种类型的IM消息，例如文本消息、语音消息、Dewu 클라이언트 라이브 방송실 APM 스트레스 테스트 실습消息、礼物消息等等。同时，客户端还应当支持各种不同的IM操作，如点赞、评论、送礼等，以全面测试IM功能的稳定性和性能。
直播debug工具接通了kylin，kylin组件已经打通了amp平台。为了更好地收集和记录压测指标，我们需要将直播debug工具与kylin组件和amp平台进行打通，确保能够快速地收集和分析压测数据。在这个过程中，kylin组件将负责接收客户端发送的压测数据，并将这些数据传递给amp平台进行进一步处理和分析。
apm平台收到了直播IM压测记录飞书通知到固定的群。为了及时发现和解决潜在的性能问题，我们需要将压测记录及时通知到相应的人员，例如开发人员、测试人员等。在这个过程中，我们可以利用飞书等即时通讯工具，将压测记录发送到固定的群，以便相关人员及时查看并进行分析。

综上，第三阶段的压测策略通过客户端发起的方式，实现了IM压测使用方式方便、支持多设备压测和压测指标有记录的目标。同时，我们还需要在实际实施过程中不断优化和改进，以进一步提高压测效率和结果的可靠性。

压测流程图：

Dewu 클라이언트 라이브 방송실 APM 스트레스 테스트 실습

五、压测效果

Dewu 클라이언트 라이브 방송실 APM 스트레스 테스트 실습

六、收益

压测只是一个手段，最重要的是发现问题，解决问题，通过三个阶段的压测也发现了不少问题。

3단계의 스트레스 테스트를 통해 팀은 일부 iOS 문제를 성공적으로 발견하고 해결했습니다. 그 중 가장 중요한 점은 스트레스 테스트가 20분 이상 지속되자 CPU가 비정상적으로 높아져 인터페이스가 멈췄다는 점이다. 조사 결과, 메시지가 비즈니스 계층에 하나씩 배포되어 과도한 CPU 소비와 너무 빈번한 UI 새로 고침(초당 최대 수십 회)으로 인해 문제가 발생한 것으로 나타났습니다. 이 문제를 해결하기 위해 팀은 두 가지 솔루션을 채택했습니다. 하나는 메시지를 하나씩 배포하는 대신 타이머를 통해 메시지 그룹을 비즈니스 계층에 배포하는 것이고, 다른 하나는 타이머 내에서 스레드 전환을 수행하여 스레드 전환이 하나만 있도록 하는 것입니다. 일정 기간 내에.

또한 스트레스 테스트 중 지속적인 메모리 증가로 인한 OOM 상황도 발견했는데, 그 이유는 일부 IM에서 일정 시간에 한 번만 실행되는 애니메이션 실행 시간이 있기 때문입니다. 동시성이 높은 상황에서는 계속해서 누적되어 메모리 오버플로가 발생합니다. 이 문제를 해결하기 위해 팀에서는 메모리 오버플로를 방지하는 애니메이션 실행 최적화 솔루션을 채택했습니다.

또한 팀은 kylin 구성 요소를 통해 여러 가지 메모리 누수 문제를 발견하고 적시에 해결하여 생방송 애플리케이션의 안정성과 신뢰성을 보장했습니다. 즉, 3단계의 스트레스 테스트를 통해 팀은 여러 문제를 성공적으로 발견하고 해결했으며, 이는 애플리케이션의 성능과 안정성을 향상했을 뿐만 아니라 팀의 기술 축적과 개발에 유용한 경험과 영감을 제공했습니다.

7. 결론

성능 스트레스 테스트는 실로 생방송실의 안정적이고 효율적인 운영을 보장하는 중요한 수단이지만, 이를 코드 개발의 끝이라고 볼 수는 없습니다. 좋은 코드는 팀 전체가 유지 관리할 수 있어야 합니다. 코드의 가독성, 유지 관리 가능성 및 확장성도 똑같이 중요합니다. 개발 및 유지 관리 과정에서 코드 품질과 팀 협업에 지속적으로 집중해야만 생방송실이 사용자에게 계속해서 고품질 서비스를 제공할 수 있습니다.

생방송실에서 성능 스트레스 테스트를 진행하면서 코드의 가독성과 유지관리성에도 주의를 기울여야 합니다. 코드의 신뢰성과 확장성을 보장하기 위해 코드 품질을 모니터링하고 제어하는 엄격한 코드 검토 메커니즘을 확립해야 합니다. 동시에 팀 협업에 중점을 두고 팀 내 소통 및 협력 메커니즘을 구축하여 팀원들이 공동으로 라이브 방송실을 유지하고 더 나은 사용자 경험을 제공할 수 있도록 합니다.

위 내용은 Dewu 클라이언트 라이브 방송실 APM 스트레스 테스트 실습의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!