Amalan ujian tekanan APM bilik siaran langsung pelanggan Dewu

1. Latar Belakang

Dengan perkembangan pesat industri siaran langsung, semakin banyak syarikat terlibat dalam bidang ini Kestabilan dan pengalaman pengguna bilik siaran langsung telah menjadi faktor penting persaingan platform siaran langsung. Walau bagaimanapun, memandangkan bilik siaran langsung melibatkan banyak pautan teknikal yang kompleks, seperti penghantaran video, komunikasi rangkaian, pemprosesan data, dll., ujian tekanan prestasi bilik siaran langsung adalah amat penting. Dalam amalan ujian tekanan di bilik siaran langsung pelanggan, teknologi ujian tekanan APM ialah kaedah ujian prestasi yang biasa digunakan Melalui pemantauan masa nyata dan diagnosis prestasi aplikasi, kesesakan prestasi boleh dikesan dan diselesaikan dengan cepat, dan kestabilan siaran langsung. bilik penyiaran boleh dipertingkatkan dan pengalaman pengguna.

Kepentingan ujian tekanan APM

1. Mengesan kestabilan sistem: Ujian tekanan APM boleh membantu penguji menilai prestasi bilik siaran langsung di bawah paras tinggi keadaan selaras dan kestabilan untuk memastikan sistem beroperasi dengan betul dan tidak ranap atau tidak berfungsi.
2. Tingkatkan pengalaman pengguna: Nilai APM yang tinggi biasanya bermakna bilik siaran langsung boleh mengendalikan lebih banyak operasi dengan lancar, sekali gus meningkatkan pengalaman pengguna. Jika nilai APM rendah, ia mungkin menyebabkan pengguna mengalami pegun dan kelewatan dalam bilik siaran langsung, yang menjejaskan pengalaman pengguna.
3. Temui kesesakan sistem: Ujian tekanan APM boleh membantu penguji dan pembangun menemui kesesakan dan masalah sistem, supaya pengoptimuman dan penambahbaikan yang disasarkan boleh dibuat. Contohnya, jika masalah dengan prestasi baca dan tulis pangkalan data ditemui semasa ujian tekanan APM, prestasi sistem boleh dipertingkatkan dengan menaik taraf pangkalan data atau mengambil langkah pengoptimuman lain.
4. Optimumkan prestasi sistem: Melalui ujian tekanan APM, pembangun boleh mengenal pasti isu prestasi sistem dan melakukan pengoptimuman yang disasarkan. Contohnya, teknologi pengimbangan beban boleh digunakan untuk menyuraikan trafik, teknologi caching boleh digunakan untuk mengurangkan beban pangkalan data, atau pemprosesan tak segerak boleh digunakan untuk meningkatkan keupayaan serentak sistem.

Adalah dapat dilihat bahawa ujian tekanan APM adalah sangat penting untuk memastikan kestabilan bilik siaran langsung, meningkatkan pengalaman pengguna, menemui kesesakan sistem dan mengoptimumkan prestasi sistem.

2. Kaedah ujian tekanan biasa dalam bilik siaran langsung

1. Ujian beban: dengan mensimulasikan sejumlah besar pengguna yang mengakses bilik siaran langsung, uji prestasi daripada bilik siaran langsung di bawah keadaan konkurensi tinggi Prestasi dan kestabilan. Anda boleh menggunakan alatan seperti JMeter atau LoadRunner untuk mensimulasikan permintaan pengguna untuk menilai prestasi bilik siaran langsung di bawah beban yang berbeza.
2. Ujian lebar jalur: Bilik siaran langsung perlu memastikan lebar jalur yang mencukupi untuk menyokong penghantaran masa nyata video definisi tinggi, jadi ujian lebar jalur diperlukan untuk memastikan bilik siaran langsung mempunyai lebar jalur yang mencukupi. Anda boleh menggunakan alat ujian kelajuan rangkaian untuk menilai lebar jalur sebenar dan kestabilan lebar jalur anda.
3. Ujian prestasi: Dengan mensimulasikan akses pengguna dalam senario yang berbeza, uji prestasi bilik siaran langsung dalam senario yang berbeza, seperti menonton siaran langsung pada masa yang sama, menghantar rentetan pada masa yang sama masa, dsb. Anda boleh menggunakan alat ujian prestasi seperti WebLOAD untuk mensimulasikan permintaan serentak untuk menilai prestasi bilik siaran langsung dalam senario yang berbeza.
4. Ujian keselamatan: Bilik siaran langsung perlu memastikan keselamatan maklumat dan privasi pengguna, jadi ujian keselamatan diperlukan untuk memastikan tiada kelemahan keselamatan dalam bilik siaran langsung. Anda boleh menggunakan alatan seperti Burp Suite untuk menjalankan ujian penembusan untuk menilai keselamatan bilik siaran langsung.
5. Ujian kebolehpercayaan: Dengan mensimulasikan kesalahan dan situasi luar biasa yang berbeza, prestasi dan keupayaan pemulihan bilik siaran langsung dalam keadaan tidak normal diuji. Alat seperti Chaos Monkey boleh digunakan untuk mensimulasikan situasi tidak normal untuk menilai kebolehpercayaan dan keupayaan pemulihan bilik siaran langsung.

Ringkasnya, melalui kaedah ujian tekanan seperti ujian beban, ujian lebar jalur, ujian prestasi, ujian keselamatan dan ujian kebolehpercayaan, prestasi dan kestabilan bilik siaran langsung boleh keselamatan, keselamatan dan kebolehpercayaan dinilai secara menyeluruh untuk memastikan bilik siaran langsung dapat memenuhi keperluan dan jangkaan pengguna.

Kaedah ujian tekanan utama yang digunakan dalam Bilik Siaran Langsung Dewu ialah ujian beban dan ujian prestasi.

3. Kaedah pelaksanaan

Pertama sekali, matlamat ujian tekanan kami ialah [ujian tekanan prestasi IM berdasarkan bilik siaran langsung]. tujuan utama ujian tekanan adalah untuk memantau Apabila bilik siaran langsung pada pelanggan menerima sejumlah besar mesej IM untuk masa yang lama, adakah masalah prestasi seperti ketinggalan, ranap atau OOM akan berlaku? Jalankan pusingan ujian tekanan sebelum setiap keluaran untuk mendedahkan isu prestasi dalam bilik siaran langsung di luar talian terlebih dahulu untuk mengelakkan isu prestasi dibawa dalam talian.

Dari segi kaedah ujian tekanan khusus, kami berharap dapat memenuhi syarat berikut:

1. Cuba tutup sebanyak mungkin jenis mesej IM
2. Ujian tekanan sangat automatik, menghapuskan lebih banyak masalah operasi manual
3. Kos penyelenggaraan yang rendah
4. Ujian tekanan tidak bergantung pada pelayan sebanyak mungkin, dan secara langsung boleh melaksanakan ujian tekanan mesej di bahagian tempatan

Berdasarkan keperluan di atas, semasa meneroka kaedah ujian tekanan, kumpulan perniagaan siaran langsung kami mungkin telah melalui tiga peringkat berikut:

Empat ujian tekanan peringkat

4.1 Bab Peringkat pertama

Peringkat pertama ujian tekanan bilik siaran langsung agak mudah Skrip digunakan untuk mensimulasikan pengguna menghantar komen, suka, dsb. IM ke bilik yang perlu diuji tekanan. Anda perlu menulis sendiri kod python yang sepadan dan menghantar mesej IM yang sepadan ke bilik siaran langsung Berikut adalah sebahagian daripada skrip 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

Proses utama adalah seperti berikut:

Ujian tekanan dilaksanakan dengan cara ini adalah agak mudah. ​​, juga boleh merangkumi beberapa mesej IM penting, tetapi ia juga mempunyai beberapa kelemahan yang jelas:

1. Untuk menguji tekanan bilik siaran langsung, anda perlu mengetahui bilik Topik ID atau IM, untuk mendapatkan maklumat ini, anda perlu menangkap paket atau menyemak rekod siaran, yang agak menyusahkan.
2. Setiap kali kod pelanggan menambah mesej IM, ia perlu menyelenggara skrip python secara manual untuk menambah nombor IM yang sepadan Terdapat keperluan tertentu untuk penyelenggaraan kemudian boleh menulis Python, dan pada masa hadapan, penyelenggara dikehendaki mengambil inisiatif untuk memahami mesej IM baharu yang ditambahkan dalam setiap lelaran versi, dan secara aktif mengemas kini jenis mesej IM skrip Ini sudah pasti meningkatkan kos penyelenggaraan.

4.2 Fasa kedua

Dalam fasa ini, kami fokus untuk menyelesaikan masalah yang tinggal dari fasa sebelumnya Untuk masalah mendapatkan ID bilik , ini hanya perlu dilakukan selepas Hanya sediakan antara muka senarai siaran yang sepadan pada klien Persoalannya ialah bagaimana untuk membuat proses ujian tekanan lebih mudah untuk beroperasi? Di sini kita memikirkan visualisasi Bukankah sangat mudah untuk dapat melakukan ujian tekanan dengan hanya satu klik tetikus? Jadi berdasarkan teknologi bahagian hadapan, kami menggunakan Vue3 untuk membina halaman operasi mesej IM yang mudah Anda boleh memilih bilik dan nombor IM yang anda mahu hantar pada antara muka visual ini Semasa membuat alat ini, kami memperkayakan beberapa logik untuk menghantar mesej IM . Ia boleh diperibadikan untuk keutamaan mesej, mesej bilik atau mesej seluruh tapak, dan dengan cara itu, ia telah melakukan beberapa kerja untuk penyahpepijatan olok-olok IM.

Kemudian atas dasar ini, antara muka penyahpepijatan memberitahu bahagian belakang bilik yang perlu diuji tekanan, dan kemudian biarkan bahagian belakang memanggilnya Skrip peringkat pertama pergi ke ujian tekanan bilik yang sepadan.

Kaedah ini menjimatkan masalah mendapatkan ID bilik secara manual sendiri dan menjadikan platform Mock visual ini sebagai Fungsi olok-olok IM ditambah pada masa itu mempunyai sedikit kaitan dengan ujian tekanan Ia pada asasnya sama dengan kaedah ujian tekanan yang dilaksanakan oleh skrip.

4.3 Fasa ketiga

Fasa ini menyelesaikan baki masalah liputan jenis mesej di atas dengan lelaran fungsi, dan pada masa yang sama, untuk membebaskan lagi campur tangan manual , automasi berdasarkan Teslalab Platform menggunakan skrip UI untuk menjalankan fungsi ujian tekanan kami secara kerap, merealisasikan fungsi ujian tekanan yang benar-benar automatik. Operasi khusus setiap langkah diterangkan di bawah

4.3.1 Liputan jenis mesej

Setiap jenis mesej IM pada klien mempunyai mesej IM yang sepadan Kelas Java, setiap kali jenis mesej IM ditambah, akan ada kelas entiti yang sepadan dengannya kelas ini semuanya diwarisi daripada kelas asas BaseLiveChatMessage, jadi kami menambah kaedah abstrak antara muka dalam BaseLiveChatMessage untuk menjana data palsu jenis mesej ini.

那么我们在新加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消息的覆盖率和可维护性也得到了保证。

4.3.2  自动化

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

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

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

压测流程图：

五、压测效果

六、收益

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

Melalui tiga peringkat ujian tekanan, pasukan itu berjaya menemui dan menyelesaikan beberapa isu iOS. Antaranya, perkara yang paling penting ialah apabila ujian tekanan berlangsung selama lebih daripada 20 minit, CPU adalah luar biasa tinggi dan antara muka tersekat. Selepas penyiasatan, didapati masalah itu berpunca daripada pengedaran mesej ke lapisan perniagaan satu demi satu, mengakibatkan penggunaan CPU yang berlebihan dan penyegaran semula UI yang terlalu kerap (sehingga berpuluh-puluh kali sesaat). Untuk menangani masalah ini, pasukan menggunakan dua penyelesaian: satu adalah untuk mengedarkan kumpulan mesej ke lapisan perniagaan melalui pemasa dan bukannya mengedarkan mesej satu demi satu ialah melakukan penukaran benang dalam pemasa untuk memastikan bahawa terdapat hanya satu penukaran benang dalam tempoh masa.

Selain itu, pasukan juga menemui situasi OOM yang disebabkan oleh peningkatan memori yang berterusan semasa ujian tekanan Sebabnya ialah sesetengah IM mempunyai masa pelaksanaan animasi dan hanya akan dilaksanakan sekali dalam satu tempoh masa. Dalam kes konkurensi, ia akan terus terkumpul dan menyebabkan limpahan memori. Untuk menyelesaikan masalah ini, pasukan menggunakan penyelesaian pengoptimuman untuk pelaksanaan animasi untuk mengelakkan limpahan memori.

Selain itu, melalui komponen kylin, pasukan juga menemui beberapa masalah kebocoran memori dan menyelesaikannya dalam masa untuk memastikan kestabilan dan kebolehpercayaan aplikasi siaran langsung. Ringkasnya, melalui tiga peringkat ujian tekanan, pasukan berjaya menemui dan menyelesaikan pelbagai masalah, yang bukan sahaja meningkatkan prestasi dan kestabilan aplikasi, tetapi juga memberikan pengalaman dan inspirasi berguna untuk pengumpulan dan pembangunan teknologi pasukan.

7 Kesimpulan

Ujian tekanan prestasi sememangnya merupakan cara penting untuk memastikan operasi bilik siaran langsung yang stabil dan cekap, tetapi kami tidak boleh menganggapnya sebagai penamat titik pembangunan kod. Kod yang baik harus boleh diselenggara oleh seluruh pasukan Kebolehbacaan, kebolehselenggaraan dan kebolehskalaan kod adalah sama penting. Hanya dengan memfokuskan secara berterusan pada kualiti kod dan kerjasama pasukan semasa proses pembangunan dan penyelenggaraan, bilik siaran langsung boleh terus menyediakan perkhidmatan berkualiti tinggi kepada pengguna.

Semasa menjalankan ujian tekanan prestasi dalam bilik siaran langsung, anda juga perlu memberi perhatian kepada kebolehbacaan dan kebolehselenggaraan kod. Kita harus mewujudkan mekanisme semakan kod yang ketat untuk memantau dan mengawal kualiti kod bagi memastikan kebolehpercayaan dan kebolehskalaan kod. Pada masa yang sama, kami menumpukan pada kerjasama pasukan dan mewujudkan mekanisme komunikasi dan kerjasama dalam pasukan supaya ahli pasukan dapat bersama-sama mengekalkan bilik siaran langsung dan memberikan pengalaman pengguna yang lebih baik.

Atas ialah kandungan terperinci Amalan ujian tekanan APM bilik siaran langsung pelanggan Dewu. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!