请问一下大家怎么对服务器进行压力测试的？

[BBP]

模拟很多个客户端操作么？
或者有没有什么专门的压力测试工具？

[sunway]

有专门的测试工具，不过要做更进一步详细的测试还是自己开发专用测试工具比较好。

On 8月27日, 上午1时15分, BBP <zzffb...@gmail.com> wrote:
> 模拟很多个客户端操作么？
> 或者有没有什么专门的压力测试工具？

[Allen]

LoadRunner 或许可以帮你

> > 或者有没有什么专门的压力测试工具？- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[柳溟]

自己写测试程序，模拟多个客户端。

2008/8/27 Allen <jianggui...@gmail.com>:

[杨光]

不同的程序不同的测试程序。自己做。开多线程，往服务端发数据。

2008/8/27 柳溟 <gsz...@gmail.com>

[qianv]

loadruner可以跑一些通用的协议，譬如http，ftp等 如果是自己的私有协议部分 肯定需要自己做程序 模拟了

BBP 写道：
> ģ��ܶ��ͻ��˲���ô��
> ������û��ʲôר�ŵ�ѹf���Թ��ߣ�

[张立冰]

loadruner基本上可以做所有的协议的压力测试，只是这个软件的限制比较大，尤其是私有协议的时候更加，很贵……

2008/8/30 qianv <liuqi...@gmail.com>

--
The time you enjoy weasting is not weasted time!

[junfeng]

主要看你的系统，才能确定如何做压力测试。你的系统不描述清楚，大家提供的帮助会模糊的。
首先，你必须知道你的每笔业务的关键点在什么位置，如果是数据库，那么，需要找这个方面的问题。
关键压力点有很多指标，看你注重那个了。
有所侧重才容易挑选合适的测试工具。
工具只是辅助。自己对系统的理解和把握才是做好测试的关键。呵呵。个人意见。供参考。

[BBP]

谢谢大家的帮助。
简单说一下我的系统。我是做网游的，目前的架构是一个区有一个数据库，若干个GameServer连接在两个DBServer上，DBServer再和
DB相连接。使用的DB是mysql，但是DB所在的服务器本身并没有性能问题，CPU、磁盘、网络等方面的占用都挺低。DBServer本身的CPU
占用也不高。
目前的状况是整个一个区的DB性能比较低，每次有数据库操作都会响应缓慢。DBServer是把每次的请求做为一个event处理的，请求按照顺序排队
处理。初始的event池是1024，之后更多的event是动态分配的内存。数据库操作响应慢据目前的状况分析可能是DBS的吞吐量不大造成的，但是
实际上DB的资源占用并不高。

不知道我说明白没有，希望大家帮我分析分析，谢谢！

[BB.Case]

就是数据库IO反应慢的问题,应该多线程

[flywav]

多线程的话，大家有没有考虑执行顺序不一致造成业务错误？



On 9月5日, 下午10时14分, zephyr <zephyr....@gmail.com> wrote:
> 你的DBServer是不是只有一个工作线程从event 队列中取event提交到mysql, 如果是这样的话， 建议把DBServer的工作
> 线程改为多线程或者线程池试下

> > > 工具只是辅助。自己对系统的理解和把握才是做好测试的关键。呵呵。个人意见。供参考。- 隐藏被引用文字 -
>
> > - 显示引用的文字 -

[BBP]

谢谢大家，经过我们小组的讨论，结论基本上和大家一样，就是使用多线程连接DB，然后通过PlayerID来做Hash保证每个玩家的顺序性。但是还没
有发布，具体情况还要经过压力测试以及正式发布之后才能确定。
再次感谢大家！

On 9月10日, 上午10时07分, zephyr <zephyr....@gmail.com> wrote:
> 你可以在派发DB请求的时候有个分配规则， 比如说和某个user相关的请求不分配到不同的thread等规则

> > > > - 显示引用的文字 -- 隐藏被引用文字 -
>
> > - 显示引用的文字 -
>
>

[Ben Leung]

或者從整個系統的架構去想會不會好點呢，因為我更喜歡說如果硬件能實現的東西，一般我都不會追究軟件的。

線程，內存，是程序最難控制的兩個地方之一，與其在這上面掙扎，建議考慮一下系統架構部署，  把複雜度及風險減低。

之前做的DB cash,用的是二級緩存，再集群DB SERVER，或者你試試。

2008/10/22 BBP <zzff...@gmail.com>

--
Best Regards,
Ben Leung

Tel:  13697779921

[BBP]

因为现在压力并没有到db上，所以暂时不用考虑做集群，一旦压力大到db承受不起的时候再做。谢谢！

On 10月22日, 上午10时30分, "Ben Leung" <lgm...@gmail.com> wrote:
> 或者從整個系統的架構去想會不會好點呢，因為我更喜歡說如果硬件能實現的東西，一般我都不會追究軟件的。
> 線程，內存，是程序最難控制的兩個地方之一，與其在這上面掙扎，建議考慮一下系統架構部署， 把複雜度及風險減低。
> 之前做的DB cash,用的是二級緩存，再集群DB SERVER，或者你試試。
>

> 2008/10/22 BBP <zzffb...@gmail.com>

[0open0]

用多线程，或者线程池，如果对User读取数据的先后顺序很讲究的话！！！其实也相当于一种阻塞的操作！！此种的操作，对于利用多线程与线程池也不能提
到很高的性能！！

还请问下楼主，playID做Hash保证顺序性的详细做法？ 谢

[BBP]

只是对同一个User有顺序要求，实际上有个连接管理器，通过PlayerID % ConnectionAmount来分配至某一个连接，比较简
单。

[sunway]

可以在dbserver上加cache定时写入有变化的数据到数据库，不是有变化就写库。

On 10月22日, 下午11时29分, 0open0 <hotice...@gmail.com> wrote:

> > > Tel: 13697779921- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[sunway]

如果playid是字符串，可以hash(playid)，这样可以保证对用户进行DB操作的线程是同一个线程。
保证了一致性。

On 10月22日, 下午11时29分, 0open0 <hotice...@gmail.com> wrote:

> > > Tel: 13697779921- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[BBP]

基本上来说，我对自己的DBServer的稳定性不报信心（虽然跑了很久还是比较稳定），所以还是即时写库比较放心，毕竟涉及到玩家的数据，也就是
money。

[BBP]

PlayerID是long long。字符串的hash函数都不是很快，不过也够用了。

[sunway]

取余数也是一种hash算法,嘿嘿

[yy x]

DB业务顺序的问题需要逻辑和程序双方便保证。
如假如一个DB请求调用的存储过程中同时操作两个Player数据，那即使以单个PlayerId进行hash也可能出现不一致问题。

2008/10/22 BBP <zzff...@gmail.com>

[sunway]

把这个操作变成2个操作，不同线程来执行。

On 10月29日, 下午4时42分, "yy x" <fling...@gmail.com> wrote:
> DB业务顺序的问题需要逻辑和程序双方便保证。
> 如假如一个DB请求调用的存储过程中同时操作两个Player数据，那即使以单个PlayerId进行hash也可能出现不一致问题。
>

> 2008/10/22 BBP <zzffb...@gmail.com>

[BBP]

> 如假如一个DB请求调用的存储过程中同时操作两个Player数据，那即使以单个PlayerId进行hash也可能出现不一致问题。
一般都是根据发送着的Player来hash的。这样的操作可能是作为一个操作来实现。

On 10月29日, 下午4时42分, "yy x" <fling...@gmail.com> wrote:
> DB业务顺序的问题需要逻辑和程序双方便保证。
>

> 2008/10/22 BBP <zzffb...@gmail.com>

[fly]

如果我需要类似下面的操作：将A玩家的1000金币，转给B玩家。这个用一个存储过程可以保证不出问题。分成两个操作怕出问题。

2008/10/29 sunway <sunh...@gmail.com>

[sunway]

这个操作一般是逻辑服务器处理，逻辑服务器在内存里修改playerA,playerB的数据结构，定时保存playerA,playerB的数据到数
据库。

On 10月30日, 上午9时35分, fly <fling...@gmail.com> wrote:
> 如果我需要类似下面的操作：将A玩家的1000金币，转给B玩家。这个用一个存储过程可以保证不出问题。分成两个操作怕出问题。
>

> 2008/10/29 sunway <sunhui...@gmail.com>