C++游戏服务器的性能优化(持续更正更新。。。)

大方向

对于服务器性能分析,要从内存分配多线程两个方面入手。

修改内存分配策略不但能降低内存,还能减少碎片,最终势必会提高游戏性能(分配阻塞导致性能低)。

使用多线程,将复杂的逻辑异步到不同的线程去计算,减少了主逻辑的等待,也必然提高了流畅性。

 

针对问题提出的优化策略:

1.内存分配方法

对于已有的内存池策略:

  • 是否可在程序启动时,直接分配固定的内存数(比如3000,可根据在线人数确定)。占用一定内存开销,提高运行时效率。需要数据验证可行性。
  • 每次增长的数(目前32)是否可优化为更大,或者修改为梯形增长方式,或者以每次2倍的速度增长?需要数据验证可行性。

彻底的接管内存分配

  • 使用gperftools的tcmalloc组件彻底接管内存分配。配置很方便,编译时增加一个链接选项即可。(https://my.oschina.net/u/877348/blog/272066)

  初步测试,接入tcmalloc后,内存占用由原来的107448降为67108,提高大约40%,可验证对在线的影响。

2.并行计算

  • 修改完成端口启动的线程数目,提高CPU 使用率,可有效提高网络通信的吞吐量。目前为3,一般设置为CPU数*2。
  • 目前所有玩家的逻辑都在一个线程处理,考虑使用多线程的可行性。

 

以上是在不改变当前单服的状态下,可做出的优化。毕竟单服总有上限,如果以上的优化都不能达到想要的效果,就要拆分服务器了。

  • 增加LoginServer

Gate和Master之间增加LoginServer,或者Gate本身增加LoginServer的功能。

负责:登陆验证、创角、角色列表、删角、 封禁IP过滤等处理,其它逻辑交给Master。

  • 增加LogServer

增加LogServer,监听Master传送的消息,专门负责和logDB的交互。

  • 其它

上述修改完成后,如果在线依然无法满足,可根据统计数据,逐步拆分出GameGate,GMGate,ChatServer,TaskServer,DBServer。

参考 https://blog.csdn.net/cmdos/article/details/63252809

 

 

一些细节

1. 对齐原则。比如64位总线,每次寻址读取8B。编程时注意变量地址,尽量消耗总线最少的寻址次数。堆内存申请时,系统严格按照对齐原则分配,故而使用时候也尽量不要跨寻址边界。

各个硬件平台对存储空间的处理上有很大的不同。一些平台对某些特定类型的数据只能从某些特定地址开始存取。比如有些架构的CPU在访问 一个没有进行对齐的变量的时候会发生错误,那么在这种架构下编程必须保证字节对齐.其他平台可能没有这种情况,但是最常见的是如果不按照适合其平台要求对 数据存放进行对齐,会在存取效率上带来损失。比如有些平台每次读都是从偶地址开始,如果一个int型(假设为32位系统)如果存放在偶地址开始的地方,那 么一个读周期就可以读出这32bit,而如果存放在奇地址开始的地方,就需要2个读周期,并对两次读出的结果的高低字节进行拼凑才能得到该32bit数 据。显然在读取效率上下降很多。

(暂时没有找到更简洁正确的解释 )

 

2. 需要的时候,可为了效率拷贝代码,虽然增加了代码体积,但这是值得的。尤其是for循环,若次数比较少,拆开亦无妨。

3. 位运算中,-1右移,左边补1,故仍为-1;-1左移,右边补0,故不再为-1。

4. 每次申请的堆内存,最好初始化,里面是垃圾数据,而并非为空。

5. 项目开发中,往往一个引擎对外暴露的是一个纯虚类,而其接口就是这个类的**指针变量。

6. 程序逻辑,重在语义。不能为代码的过分简单而减少函数的设计。

7. *&表示对指针的引用。

8. 类的静态方法不可调用其非静态方法,亦不可调用非静态成员变量。

9. 多文件编程时,头文件不可相互包含。

10. 头文件里尽量不要使用using namespace std;

11. static成员定义要放在cpp文件里面,而不是头文件里。

12. 纯虚类尽量不要延续两层以上。

13. include引用尽量都放在cpp文件里。

14. 子类继承父类,不可在构造函数里初始化父类并未在构造函数里初始化的成员,也就是说,子类构造函数里能初始化的成员,只有自己本身的和父类构造函数里的。

15. 项目开发中,对于一些依赖本地环境的参数,要写专门的配置文件,比如服务器地址。

16. 头文件里只声明,不定义。在头文件中,全局变量声明,必须加extern修饰;静态成员变量声明放在头文件,定义放在cpp文件,若是普通静态变量,最好声明和定义放在cpp,因为static作用域限于单文件,放在cpp里只对本文件可见,放在头文件会被所有引用该头文件的cpp拷贝一份完全相同的变量。

17. linux下,进行文件操作时,文件路径要采用绝对路径(相对路径很多时候会出bug),文件指针要对其返回值作判断,防止空指针。

18. debug状态下使用assert是极好的,不过记得发布版本前在#include 前加上#define NDEBUG,assert语句会被NDEBUG所影响。这里多嘴一句,错误与异常是不同的,异常是不可避免,在发布版本里不可或缺的,故而assert不能用于处理异常。注:在加上#define NDEBUG后,不论是调试还是运行,assert语句都会被直接忽略,故而平时开发时把#define NDEBUG注释掉,发布时再启用它。

19. 面向对象编程:可维护,可复用,可扩展,灵活性好。

20. 频繁使用的代码里,尽量少使用容器,因为其创建和回收的开销很大。

21. 字符串拼接效率:经过测试(http://bbs.csdn.net/topics/360000434和我自己项目中的实验),memcpy效率最高,string类的+=效率特别高,足以满足日常所需,而strcat效率很差,append也不快。

22. 基类中的虚函数要么实现,要么是纯虚函数(绝对不允许声明不实现,也不纯虚)。

23. 在C++的类中,普通成员函数不能作为pthread_create的线程函数,如果要作为pthread_create中的线程函数,必须是static。

24. 当多个线程访问同一个类静态方法时,若该方法里只操作栈上数据,则无妨,因为线程的栈是独立的;若该方法操作了非栈上的数据(比如堆、全局变量等),则需要互斥锁。

25. 内联函数,定义体要放在头文件,以保证每一个引用该头文件的cpp里都是完全相同的拷贝;inline关键字置于定义前,不必放在声明前;若定义在类内部,可不需要inline关键字。

26. vector执行clear时,会自动调用元素(如果是类的话)的析构函数。

27. 编程时,对变量(尤其是全局性质的变量或类)命名,要用解释性的,而不能用随意的j1,i1,n,m等名称,容易与库里的变量冲突。

28. 定义宏时,尽量多用整数,少用-1,-2之类,容易受uint和int不统一带来的困扰。

29. 函数形参采用默认值时,要写在声明里,而不写定义里,这样方便调用其头文件的cpp看得到默认值。

31. utf-8 中文编码 三个字节表示一个汉字

32. 项目开发时,使用条件编译:

#define DEBUG
main()
{
#ifdef DEBUG
    printf("Debugging\n");
#else
    printf("Not debugging\n");
#endif
    printf("Running\n");
}

发布版本时,注释掉第一行。这种方式要比开大量注释来得方便。

33. 关于c字符数组,需要注意一个初始化问题:

(1) char str[10]="";
(2) char str[10]={'\0'};
(3) char str[10]; str[0]='\0';

前两者的意义在于str的每个元素都初始化为'\0',第三者仅仅初始化第一个元素。当数组长度很大时,前两者时间开销极大。故而,有些不必要的时候,不要如此初始化。

34. 判断一个字符是否为数字:

头文件:#include
定义函数:int isdigit(int c);
函数说明:检查参数 c 是否为阿拉伯数字0 到9。
返回值:若参数c 为阿拉伯数字,则返回true,否则返回null(0)。
附加说明:此为宏定义,非真正函数。

 

#include 
main(){
    char str[] = "123@#FDsP[e?";
    int i;
    for(i = 0; str[i] != 0; i++)
        if(isdigit(str[i]))
            printf("%c is an digit character\n", str[i]);
}

35. 在类里声明静态常量,尤其是数组定义的时候,如static const *str = "sdfsssf", 要在const前加上constexpr修饰,可以在编译器就将“sdfsssf”赋值给str,达到类似宏的效果。

36. std::string::find_last_of("/\\") 这里的"/\\"指的是'/'或'\',在搜索字符时用得到。

37. 项目里c字符串传递,多采用首地址+长度的方式,避免0x0存在导致的异常; 线程数要合适,大致为cpu总核数两倍以内为佳,线程间切换会一定程度上消耗程序性能。

  有一个陷阱是在c字符串转string类型时,c字符串里如有0,转化时用strlen取长度就会出错。故而,c串表示尽量维护一个len来记录长度,而不是通过结尾0来判别。另外,strlen效率低且不安全,少用。

38. 静态函数的实现写在h文件里;尽量把h文件里的函数实现前都加上inline,不论其复杂度,避免被多文件引用而引起重复定义错误。

39. 静态成员变量必须在类外进行初始化。如果是复杂类型,比如容器,也要在类外定义,如std::vector hj::sm_tr;

40. 编程时,一般结构体里的堆内存由内存池管理申请或释放,或者stl里使用这些结构体作为元素时,使用其指针,而不是实例。因为stl里内存申请或释放,会调用其元素的构造和析构,这里会有陷阱。

41. 使用set、map时,有一个陷阱,就是[]操作符。当使用这个操作符时,如果[x]里的x并不在set或map里,则stl会自动生成一个x元素,这样使得stl容器内容改变,如果开发者忽略了这点,后果可能无法预期。

参考 https://www.cnblogs.com/jiu0821/p/5407389.html

 

1 关于继承:不可否认良好的抽象设计可以让程序更清晰,代码更看起来更好,但是她也是有损失的,在继承体系中子类的创建会调用父类的构造函数,销毁时会调用父类的析构函数,这种消耗会随着继承的深度直线上升,所以不要过度的抽象和继承,更为严重的是当多重继承中并且有虚函数的存在时情况更为复杂,的确,这些问题涉及开销,但是,多重继承减少了编码的负担,同时也让问题的解决方案更加简洁,这当然要付出一些代价.总之,与n个基类的多重继承层次相关的额外虚函数表有n-1个。派生类和最左边的非虚基类共享同一个虚函数表。因此,带有2个基类的多重继承层次,有1个(2-1=1)基类的虚函数表和1个派生类的虚函数表(最左边的基类与派生类共享该虚函数表),总共有2个虚函数表,如果有虚继承的存在,会进一步增长这个过程,它是有额外的开销的。

2 对象的复合:对象的复合和继承很相似,当一个对象包含其他对象构造时也会引起额外的构造。关于这点可能会有很多人不解,认为这是不可避免的,举个例子,比如你的类A中包含了类B非指针和引用对象,那么在你构造对象a的时候会自动调用b的无参构造函数,即使你还没有用到她,用指针代替就没有这种消耗,另外如果你的一个对象中用到数组和字符串,你是选择string和vector还是char* 和c系的数组呢,如果没有用到c++stl库提供的相关的高级用法,建议选择后者。

3 构造函数:尽量用参数列表初始化代替参数,避免值传递初始化。

4 变量延时定义:从c系转过来的仍保留着c的习惯,在函数第一行先把所有用到的变量都定义好,但是c是没有运行时的消耗的,对于c++时不一样的,对于c++对象的构造和销毁时有消耗的,如果有大量的对象只在某个if条件的一个分支中出现,那就会有50%的情况这些消耗是可以避免的。对于这点在一个类中也是一样的,如果成员中有成员只在某个时刻能用,就用指针代替,在构造对象时初始化成空指针,避免构造时调用他的构造函数。

5 虚函数:虚函数的底层实现是通过一个虚函数表来实现的,因此有虚函数的类构造时必须先初始化虚函数表,函数调用时也必须先找到虚函数表,然后通过指针偏移找到相应的函数,通常情况下调用虚函数是没有运行时消耗的,但是根据编译器的实现不同,在调用虚函数时,有些调用可能导致增加虚函数表大小的额外开销,或者只有那些需要调整this指针的调用才会发生额外的运行开销,但不会增加虚函数表的大小,在多重继承和虚基类的时候这种消耗会显著增加,关于继承已经提过,所以避免滥用虚函数和虚继承,有时候可以用模版设计来代替虚继承,把运行时的消耗提前到编译期。关于虚函数的消耗:点击打开链接

6 返回值优化: 虽然c++编译器会选择性的进行RVO优化但是不是强制的,当函数有多个返回语句并且返回不通名称的对象,函数过于复杂,返回对象没有定义拷贝构造函数时,rvo优化是不会执行的,所以当函数返回一个很大的对象时在不确定rvo优化会执行时,尽量避免值传递。

7 变量的定义:在定义变量时尽量避免类型的不匹配造成临时变量的产生。

8 内存管理:c++内存管理的大权由我们自己掌握,对于项目中要频繁申请和释放的对象建议用简单的内存池来管理,可以大大的降低频繁申请和释放内存带来的消耗。

9 善用内联:内联函数不仅仅是简单的函数调用似的优化,他还有一个最大的优点就是,可以让编译期进行进行边界代码的运行环境优化,内联把代码拷贝到执行环境处避免了函数调用带来的消耗,并且编译期可以进行正常的编译优化,而函数调用是不能实现的。

10 stl :记住一点stl不是唯一的选择,有时候也不是最好的选择,合理选择stl善用stl算法。

11 缓存:对于多次使用的计算结果及时缓存,避免重复计算。

12 延时计算:对于不关心计算结果的计算过程尽量延时执行或者异步去执行。

13 多线程:尽可能的使用无锁式多线程开发,锁是一个非常消耗性能的东西,保证数据同步的手段有很多,voalite,原子操作都可已实现,尽量通过一些技巧使用这些手段避免所得使用,如果迫不得已要使用锁,尽量减少锁的消耗,比如降低锁的粒度,使用性能更高的锁等等。

14 std::move操作: 当不得不进行深拷贝时,如果深拷贝数据源在拷贝后就不在使用,尽可能的用move操作代替,或者在参数传递时用move操作代替临时的实参变量。

15 cpu缓存:合理的利用cpu cache可以极大的提高代码的运行效率(例如:数组中以每列遍历和每行遍历的效率的不同),当然多线程环境下也要考虑cpu cache带来的影响。

16 内存对齐:在进行网络编程时,最好对网络中传送的数据快进行内存补齐,通常是8字节对其,提高cpu访问内存效率,从而提高数据读写速度。

17 函数参数:用const引用代替值传递,如果函数参数过多,可以用对象来打包参数,减少参数过多带来的性能消耗。

18 算法: 尽可能的优化你的算法。

19 关于智能指针:对于智能指针我的选择是必须用,它可以大大降低程序的crash频率,但是智能指针的和普通指针相比是有额外的消耗的,她的底层是一个原子操作来来统计引用数和一个普通指针,虽然原子操作和锁相比性能高了不少但是和普通的加减操作还是慢了不少,智能指针的大小为16个字节,而普通指针的大小只有4个字节,拷贝的成本也不一样,所以在使用正确的情况下可以使用智能指针的引用来减少拷贝的消耗(注意这里的前提是正确的使用引用,不要引用以一个即将被销毁的变量)。

20 内存池:对于需要频繁申请和释放的内存对象,如果可以重复利用对象的内存,强烈建议通过内存池或者重载对象的new操作符或者重载对象的placement new操作符来减少频繁的申请和释放内存,从而减少申请和释放内存的消耗和内存碎片的产生。

21 其他优化方案:位运算代替乘除法,前缀运算符代替后缀运算等等。
原文:https://blog.csdn.net/d_guco/article/details/75729259 
 

你可能感兴趣的:(C++)