关于压测

本博客详细记录了游戏服务器在测试期间遇到的内存泄漏问题,包括客户端崩溃、服务器崩溃、内存异常增长等问题。通过引入glowcode工具检测内存泄露,并分析了导致问题的原因。最终,通过改进内存管理策略,如正确使用STL数据结构和避免频繁的push_back操作,成功解决了内存泄露问题。测试结果显示服务器稳定性得到提升,但仍存在少量内存泄露需要进一步解决。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

2011-10-31	第一天测试,客户端蹦了1000多次。因为之前没有任何的异常处理,最近在游戏主程序入口添加了异常捕获,检测到异常即弹出BUG提交报告,结束客户端进程。此方法导致客户端崩溃次数过多,需要做处理,以后在做开发的时候,每个函数需要做异常捕获,可以参考天龙的代码。服务器第一天还算稳定,基本没有出现崩溃的现象。
 
2011-11-01	第二次测试,客户端根据收集的信息,更改了崩溃导致的BUG,而服务器蹦的稀里哗啦的,首次由于组队拾取分配的时候导致崩溃,具体原因是溢出,仅接着又出现了物品复制的问题,再次导致了服务器的崩溃。另外服务器内存一直异常增长。半小时后再重新开的。实际测试不到一小时。
 
2011-11-03	今天查出了服务器内存增长的部分原因,一是自实现的一个HASH数据结构,内存使用calloc进行分配,却使用了DELETE释放,此文件使用了2年多,居然没发现,汗一个;另外一个重要的原因是在AI中,怪物进行追击的时候,不断的在重设追击目标,每帧发送的数据包量太大,导致网络层处理不过来,导致内存猛涨,起起落落,当没有足够内存分配时,服务器便挂了。主要就这些了,期待今天晚上的测试吧。
 

2011-11-08

03号没有再进行测试,因为内存一直增长,扛不了多久,周末找了外援,推荐了glowcode工具来检测泄露。有经验还是不错滴。省很多事,不需要再次摸索。

今天号称是第二轮测试,希望会比之前的2次要好!

 

在查询内存的时候,采用了glowcode工具来检测,初次使用,仅仅关注需要的功能。
STL本身并没有什么问题,但是如果使用不当,很容易导致内存泄露。
区域服务器使用了类似空闲列表的技术,使用后回收,下次使用从空闲列表中取数据。如果在回收的结构中使用了STL的
数据结构,并大量的push_back操作,回收或者复用的时候仅仅是调用clear 方法,很容易会发现,内存涨的很厉害。
于是,把代码样本抽出来,如下:

 

 
#include "TObjectPool.h"
#include <vector>
class CObject
{
	std::vector<int>	v1;
public:
	void test()
	{
		for (int i = 0; i < 1000; ++i)
		{
			v1.push_back(i);
		}
		v1.clear();
#if 0
		//	if not do this, memory leaks.
		std::vector<int>(v1).swap(v1);
#endif
	}
};

void TObjectPoolTest()
{ 

#if 1
	CObjectPool<CObject*>* pObjPool = new CObjectPool<CObject*>(sizeof(CObject));
	for (;;)
	{
		CObject* pNewObject = pObjPool->AllocaObject();
		memset(pNewObject,0,sizeof(CObject));
		pNewObject->test();
		pObjPool->ReleaseObjdect(pNewObject);
		::Sleep(10);
	}
#else
	for (;;)
	{
		CObject* pNewObject = new CObject;
		if (pNewObject)
		{
			pNewObject->test();
			::Sleep(10);
			delete pNewObject;
		}
	}

#endif

}


第一列数据是访问次数,图一为执行std::vector<int>(v1).swap(v1);操作的结果,图二为没有执行的结果。可见没有执行的调用malloc的次数要多的多,实际上是一直在调用,而图一为刚开始调用,后面就不再调用了。当然,这个只是在使用了TObjectPool的情况下,正常情况下没有出现。

测试结果:

整个测试过程中上线保持在300~400的区间,服务器还算稳定,没有再出现崩溃的现象,不过内存还有小额度的增长,还有未解决的内存泄露问题。一直持续到9点,往上累加机器人,直到1500左右,此时占用内存1.4G,带宽发送约2.8M*8,接收带宽约0.7M*8.平均每个玩家15.2K。





                
<think>好的,我现在需要帮助用户了解JMeter测试的技术要点、使用方法和最佳实践。首先,我应该先整理用户的问题,明确他们想知道的具体内容。用户提到了技术知识点,可能包括JMeter的基本概念、核心组件以及工作原理。然后,使用方法和步骤,比如如何创建测试计划、配置线程组、添加取样器、监听器等。最后是最佳实践,比如如何优化测试脚本、分析结果和常见问题的处理。 接下来,我需要回顾自己掌握的JMeter知识,确保信息准确。JMeter是一个开源的性能测试工具,支持多种协议,如HTTP、FTP、JDBC等。测试主要关注系统在高负载下的表现,所以需要模拟多用户并发。技术要点可能包括线程组配置、参数化、断言、定时器、分布式测试等。使用方法方面,用户可能需要步骤指导,从安装到运行测试。最佳实践可能涉及避免GUI模式运行测试、使用CSV数据文件、合理设置线程数、监控资源等。 然后,我需要参考用户提供的引用内容,看是否有相关点可以结合。引用[1]提到场景法测试,适用于业务流程的组合测试,这可能与JMeter中的场景设计有关,比如模拟用户登录、浏览、下单等流程。引用[2]涉及测试用例的编写规范,比如步骤清晰、覆盖需求、优先级标注等,这些在JMeter测试计划设计时同样重要,确保测试用例的有效性和可执行性。 在组织回答时,需要结构清晰,分点说明。技术要点部分要涵盖JMeter的核心组件和配置,比如线程组、取样器、监听器等。使用方法需要步骤化,从安装到结果分析。最佳实践部分要给出实用的建议,比如分布式测试、参数化、资源监控等。同时,生成相关问题,帮助用户进一步学习,比如性能分析、优化方法和应用场景。 另外,需要注意用户提到的格式要求,行内公式用$...$,独立公式用$$...$$,但JMeter测试可能较少涉及数学公式,可能需要提到性能指标的计算,比如TPS(每秒事务数)、响应时间等,如果有的话需要用正确格式。例如,计算TPS可以使用$TPS = \frac{事务总数}{测试时间}$。 还需要检查LaTeX语法是否正确,确保没有错误。同时使用中文回答,避免术语翻译错误。例如,“线程组”而不是“Thread Group”,但专业术语可能需要保留英文,如“Sampler”、“Listener”。 最后,确保回答真实可靠,引用相关的资料,比如引用[1]和[2]中提到的测试用例设计原则,可以结合到JMeter测试计划的设计中,比如覆盖业务流程、正反面用例等。同时,在回答末尾添加引用标识,如[^1][^2]。 可能遇到的问题:用户对JMeter的具体操作不熟悉,需要详细步骤;如何解释分布式测试;如何分析监听器生成的结果图表。需要确保步骤清晰,术语解释到位,示例代码或配置片段正确无误。 总结,回答结构大致分为三个部分:技术要点、使用方法、最佳实践,每个部分下分点说明,结合引用内容,最后生成相关问题。</think>### JMeter测试技术要点 1. **核心组件** - **线程组(Thread Group)**: 定义虚拟用户数量(线程数)、启动时间(Ramp-Up Period)及循环次数,例如设置$线程数=100$表示模拟100用户并发。 - **取样器(Sampler)**: 支持HTTP请求、JDBC、FTP等协议,用于模拟用户操作。 - **监听器(Listener)**: 如聚合报告、响应时间图,用于分析性能指标如$TPS$(每秒事务数)、$平均响应时间$。 - **配置元件(Config Element)**: 如HTTP请求默认值、CSV数据文件,实现参数化输入。 2. **关键配置** - **参数化**: 使用CSV文件或函数助手动态替换变量,避免重复请求。 - **断言(Assertion)**: 验证响应内容,确保测试逻辑正确性。 - **定时器(Timer)**: 如固定定时器,控制请求间隔以模拟真实用户行为。 --- ### 使用方法与步骤 1. **创建测试计划** - 添加线程组 → 配置并发参数 → 添加取样器(如HTTP请求) → 设置监听器。 2. **脚本增强** - 使用正则表达式提取器处理动态数据(如Token)。 - 添加逻辑控制器(如循环控制器)模拟复杂场景。 3. **执行与监控** - 命令行运行(避免GUI模式资源消耗): ```bash jmeter -n -t testplan.jmx -l result.jtl ``` - 使用`PerfMon`插件监控服务器CPU、内存等资源。 --- ### 最佳实践 1. **分布式测试** - 通过多台负载机执行测试,需配置主控机(Master)与代理机(Slave),避免单机瓶颈[^2]。 2. **结果分析优化** - 关注$错误率$(应<1%)和$响应时间$(需符合SLA)。 - 使用`Filter Results Tool`过滤异常样本。 3. **资源节约技巧** - 禁用不必要的监听器(仅保留聚合报告)。 - 设置合理的超时时间,避免长连接占用资源。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值