探讨游戏服务器压力的三座大山——数据库、网络以及系统资源(4)

贴上原文地址:http://blog.csdn.net/gz80/article/details/7411564

最后探讨一下服务器优化的工作方法。

程序优化可以说是一个全新的工作方式，它即不像写新模块似的，一切从零开始；也不像修复bug那样有明确的错误现象。

它就像一个人对医生说，我觉得不舒服，但不知道到底哪里不舒服。对于程序也是一样，我就感觉玩起来很卡，但不知道到底卡在哪里，该从哪下手。

以前在其他公司也做过性能优化的工作，但性能优化往往是安排在项目后期才进行的。一些人迫于项目日程与版本计划的压力往往来不及细想，只是靠猜测去幻想系统的瓶颈在哪，然后就在哪动手。

但这样仓促上马的结果多数是事倍功半，一顿功夫忙活下来，系统性能只得到一点的提升。可以说是花了200%的努力，只获得1%的成果，而同时人力物力、时间精力也已经花掉了。

我认为这种情况是由于动手前没有做好调查而导致的。记得在以前在三星优化CDMA手机TCP/IP协议栈时，前先做了一个packet trace的报告，就是跟踪一个数据包从物理层解调结束后开始，到传输给应用层为止，记录其在每一层逗留的时长，以及每个处理所耗费的时间。再根据这个报告来定位优化点，及其可行性。
最后还要定一个目标值，比如参考目标是硬件配置类似的另一款型号，其传输速率达到300kbps，那我的优化目标是在两星期内使目标机型的传输速率不低于参考机型的90%，优化工作不能没完没了的无休止干下去。
所以我们在优化游戏服务器时也做过大量的分析记录，如sql语句的执行时间，每个数据包的处理时间，每种数据包出现的频率，socket发送环形队列的等待情况，socket接收队列的等待情况，socket发送情况，TCP滑动窗口状况等。
所有动手的依据都是基于大量的测试与实验的基础上，以避免像盲头苍蝇似的到处乱碰。

当然，有时项目日程较紧，把优化工作推后，而且开服后的一段磨合期中必定会面临这里宕机、那里卡死等突发性问题，优先解决紧急状况，延后优化工作这都是合理的安排。
算法设计大师唐纳德·克努特(Donald Ervin Knuth)曾经说过“过早优化是万恶之源”（premature optimization is the root of all evil）。这句话虽说有些夸张，但非常有道理。
在基于现有的程序上进行优化，即使优化失败了，也至少有个能运行的但效率不高的程序可跑。但是如果连功能都没实现好，就去考虑细枝末节的问题，就会导致项目进度没完没了地一再拖延。

最后两句话来总结优化工作：
1.一切行动都依靠于事前调查与测试

2.避免过早优化

（完）