關於壓測

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。