以下是最近某个项目的一次经历，最终并没有按照这样的方案来优化，但对思路确实是一个提高，所以记录在此。
-------------------------------------------------------------------------------------------------------------------
项目D为单机服务器，据说在线达到1500后，会很卡，于是想仔细分析了其中的原因。
整体来说：C++服务器+mysql数据库，多线程。但是是单服。
请教了前同事，在他的一步步询问下，理清了服务器的当前架构。
同事指导，对于服务器性能分析，要从内存分配和多线程两个方面入手。
修改内存分配策略不但能降低内存，还能减少碎片，最终势必会提高游戏性能（分配阻塞导致性能低）。
使用多线程，将复杂的逻辑异步到不同的线程去计算，减少了主逻辑的等待，也必然提高了流畅性。
线程方面：
1 一个socket负责监听所有客户端的session。使用了完成端口的概念，起了3个线程，负责收消息，收到后，将消息放入一个全局的队列revQueue中，这个队列包含所有玩家的所有消息。
2 全局的session管理类，管理所有客户端的session。每个玩家发送消息时，写入自己的发消息队列ownSendQueue中。
3 一个单独的数据库操作队列dbQueue，负责所有对数据库的读取。
4 启动游戏时，开了一个线程，专门负责内部逻辑的刷新。包括各种timer，数据库队列dbQueue的分发，全局收消息队列revQueue的分发(每次轮询到时，会将队列中的所有消息都分发出去)，每个session的发消息队列ownSendQueue，其它游戏内的各种update(血量体力等各种恢复)。
内存分配：
1 会频繁使用到标准库的map，vector，string对象。
2 对自定义的类，有内存池的管理策略。当前策略：
- 每种自定义对象，第一次请求内存时，由内存池多分配32个可保存此类型的地址。
- 以后每次请求，从预先分配的地址中直接获取。
- 直到预分配的地址使用完，再重新分配32个，依次循环。
- 对象销毁时，不真正将对象交还操作系统，而是插入到可用的预分配表中。
再来看下服务器当前的配置，在线人比较多的一个区服务器，包括三组服务器：
32G内存+10个CPU，每组在线约300人。cpu使用7%左右，内存使用17%左右。
这一系列的分析出来，问题相对而言就明显了。
内存没有达到有效的使用。
逻辑全在一个线程，应该就是整个瓶颈所在了。
针对问题提出的优化策略：
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。
-------------------------------------------------------------------------------------------------------------------
再次重复下，以上只是某个项目的一次经历，最终并没有按照这样的方案来优化，但对思路确实是一个提高，所以记录在此。