参考回答：
一.首先明确需要测试压力的内容:

    1.游戏服务器硬件

        a.硬盘I/o
        b.内存
        c.CPU

    2.网络压力

        a.长连接
        a1.最大连接数
        a2.流量(内网、外网、进、出)
        b.长连接短周期(类似Http的TCP应用，这个比较特殊的一个需求，专门针对LoginAgent)
        b1.每秒建立的连接数
        b2.实际处理能力

    3.数据库

        a.每秒事务数
        b.每秒锁等待数
        c.平均延时(ms)
        d.CPU暂用

    4.多线程的最优线程数

        a.数据库执行的多线程
        b.多连接处理

二.Windows Server环境测试方式

    1.服务器性能监测

      使用Server自带的性能监测器设置各个进程的监测参数。Window的这个自动工具做的相当强大。大家自己摸一摸基本就会用了。每个参数都由详细的说明。

    2.案例设计注意

        a.对于数据库的性能测试上，现在由于所有的游戏服务器构架在DB前面都有一个实现DB缓冲功能的进程，以减少数据库频繁的读写操作。

           所以其实数据库的读是一个轻量级的数量；而数据库的写操作是一个周期性能过程。案例设计一定要能够驱动这种周期性能过程。

           比如我们游戏的战斗，导致游戏玩家数据的改变，或驱动所有在线玩家数据的周期性存储。

        b.选择具有代表性，并且最频繁的游戏操作。用于进行最高用户在线的各种性能指标采集。如，开枪、道具拾取、道具使用、移动、聊天

        c.聊天性能测试

          广播聊天是最为考验游戏信息发送能力的功能。通过进行全局广播的压力测试。我们可以获取服务器进程发送信息到客户端的最高承载量。

          进而可以对我们的各种广播功能进行一个预估和频率限制。

        d.同屏玩家的移动测试

           移动+广播。这两种信息，基本是网络游戏流量的70-80%左右。同屏玩家数量，将会增加各种数据的广播需求，非常影响游戏性能。

           所以同屏的移动测试也是广播测试的一个必要环节。需要根据实际结果进行适当的优化。

        e.大量玩家同时登录测试

           玩家登录时，有大量的信息需要进行分配和初始化；同时也有大量的数据需要下传客户端。服务器需要进行大量的TCP连接建立。

           所以是一个比较关键的过程。这个测试案例是一个比较特殊，但是运营是肯定会碰到的案例。

        f.由于线程池处理事务，随着事务的时耗，存在一个最优线程数的问题。过多的线程反而会降低服务器效率

    3.细节问题

        a.进行测试需要仔细思考客户端性能影响服务器最后表现的可能性。比如
        a1.模拟客户端的性能无法有效处理服务器返回信息,可能就导致服务器发送的信息缓存在服务器系统缓存，从而表现出服务器内存不断增加。表现为服务器发送能力不足，其实可能根本就是客户端的性能问题
        a2.客户端性能问题，导致发起的请求数过少，从而导致单位时间内服务器处理的请求过少。表现为服务器性能不足，其实根本就是客户端的请求能力不足。

        b.网络带宽导致最后表现不足
        b1.确认服务器的各个网卡，以及相互的带宽。不然可能因为相互带宽，导致服务器对于客户端请求的处理延时。表现为服务器卡机
        b2.客户端模拟多个玩家，比如1000个玩家。而客户端的网卡或者客户端与服务器之间的中转服务器带宽过小，导致服务器数据发送不出，内存不断增加。表现为服务器发送能力不足，其实是中间带宽问题。

        c.debug i/o导致服务器性能下降
        c1.进行性能测试，一定要取消debug用的同步的i/o.比如我们服务器的debuginternalLog.同步i/o是非常影响性能的，特别在压力测试下可能导致每秒上千上万甚至几十万次的执行。一处的文件写入操作就可以导致几十万次的处理能力变成几千次的处理能力。
        c2.客户端避免进行阻塞操作导致模拟多用户性能下降，导致服务器表现性能下降

        d.流量需要区分内网网内、外网流量在游戏正式运行时是完全分开的。价格也是完全不同的。一个千M的外网是一个无法想象的运营成本，而kmbps/s现在已经是一个可以接受的代价。游戏进程需要进行不同网卡的配置和绑定。确定内外网流量。