DIOCP开源项目-测试数据库性能
2013-06-09 00:39
357 查看
今天群里有个朋友说他们医院项目采用直连数据库,高峰时期sqlserver的连接数达到7000多,于是我准备做个用diocp做个demo,服务端用连接池。白天的时候我在想,并发如果7000个。如果用diocp做三层服务器,连接池应该在100个左右。今天晚上奋斗了一晚上,准备把测试过程中碰到的问题总结一下。
所有的代码测试代码写完后,准备开始测试,配置后服务端的连接池(config\dbpool.config)
配置中main为连接池中连接的ID<通过id获取连接>
在客户端编写测试线程
开始测试100,个线程,在笔记本上测试
问题来了
几下客户端就连接不上了,怎么连接都连接不上<服务端连接数为0>,关闭了客户端重新开也不行。心中一下就凉了,不会我写的iocp这么脆弱吧。
经过几个小时的折腾和写各种日志,发现服务端中工作线程和监听线程都是好好的,没有退出线程。
后来我查看网络情况发现服务端有在监听9983端口<但是telnet不通>,我发现有好多被关闭的127.0.0.1->127.0.0.1:9983的连接,但是在网络状态中可以看到,
过一段几分钟后,发现又可以连接上,估计客户端不能频繁的建立连接和关闭连接。
后来把客户端代码修改下<删除下面的代码>。发现一切正常,还好不是服务端的问题,diocp还是经的住考验。
//每执行一次进行异常关闭连接
FRDBOperator.Connection.close;
开启1000个客户端,不停获取数据,发现服务端连接池中最多只有7个连接,不过机器比较卡了<毕竟是笔记本>,想想我白天是多想了,diocp根据cpu的数量开启的工作线程工作线程如果是7个,连接数肯定也不会超过7个。就算客户端连接有7000个,数据库的连接数也就是7个而已。
就算有7000个连接估计同时在执行数据库的也不过就几百个而已。处理起来应该是没有问题的。明天给群里的朋友测试下。多弄几台客户端测试下
=============2015-01-28 10:10:24
上面测试环境,逻辑是在io线程中处理,其实把逻辑数据投递到其他线程池进行处理,是可以突破7个连接的限制。
后来的diocp1和现在的diocp3都有这种方案了依靠iocpTask/qworker进行逻辑的处理,这样不占用通信io线程
所有的代码测试代码写完后,准备开始测试,配置后服务端的连接池(config\dbpool.config)
{ "main": { "host": ".", "user": "sa", "password": "efsa", "database": "EF_DATA" }, }
配置中main为连接池中连接的ID<通过id获取连接>
在客户端编写测试线程
procedure TTester.Execute; var lvCds:TClientDataSet; begin InterlockedIncrement(__TesterCount); lvCds := TClientDataSet.Create(nil); try while (not self.Terminated) and (not __stop) do begin try FRDBOperator.clear; FRDBOperator.RScript.S['sql'] := FSQL; FRDBOperator.QueryCDS(lvCds); except on E:Exception do begin TFileLogger.instance.logErrMessage(FTesterCode + E.Message); end; end; //每执行一次进行异常关闭连接 FRDBOperator.Connection.close; end; TFileLogger.instance.logDebugMessage(FTesterCode + '线程已经停止[' + TesterCode + ']'); FConnection.close; finally InterlockedDecrement(__TesterCount); lvCds.Free; end; end;
开始测试100,个线程,在笔记本上测试
问题来了
几下客户端就连接不上了,怎么连接都连接不上<服务端连接数为0>,关闭了客户端重新开也不行。心中一下就凉了,不会我写的iocp这么脆弱吧。
经过几个小时的折腾和写各种日志,发现服务端中工作线程和监听线程都是好好的,没有退出线程。
后来我查看网络情况发现服务端有在监听9983端口<但是telnet不通>,我发现有好多被关闭的127.0.0.1->127.0.0.1:9983的连接,但是在网络状态中可以看到,
过一段几分钟后,发现又可以连接上,估计客户端不能频繁的建立连接和关闭连接。
后来把客户端代码修改下<删除下面的代码>。发现一切正常,还好不是服务端的问题,diocp还是经的住考验。
//每执行一次进行异常关闭连接
FRDBOperator.Connection.close;
开启1000个客户端,不停获取数据,发现服务端连接池中最多只有7个连接,不过机器比较卡了<毕竟是笔记本>,想想我白天是多想了,diocp根据cpu的数量开启的工作线程工作线程如果是7个,连接数肯定也不会超过7个。就算客户端连接有7000个,数据库的连接数也就是7个而已。
就算有7000个连接估计同时在执行数据库的也不过就几百个而已。处理起来应该是没有问题的。明天给群里的朋友测试下。多弄几台客户端测试下
=============2015-01-28 10:10:24
上面测试环境,逻辑是在io线程中处理,其实把逻辑数据投递到其他线程池进行处理,是可以突破7个连接的限制。
后来的diocp1和现在的diocp3都有这种方案了依靠iocpTask/qworker进行逻辑的处理,这样不占用通信io线程
相关文章推荐
- DIOCP开源项目-测试数据库性能
- DIOCP开源项目-DIOCP3的ECHO测试<贴图>
- [DIOCP3/MyBean/QDAC开源项目] DataModule-DB例子基于MyBean的插件实例<三层数据库方案>
- 跨平台开源项目Ngui【基准性能测试报告】
- 跨平台开源项目Ngui【基准性能测试报告】
- DIOCP-开源项目ECHO测试.
- 开源数据库性能测试工具benchmarkSQL初探
- 跨平台开源项目Ngui【基准性能测试报告】
- DIOCP开源项目-DIOCP3的LoadRunner11测试报告
- DIOCP开源项目-数据库连接池的使用<多帐套数据库>
- 开源项目之Android Emmagee(性能测试)
- 开源性能测试工具--Jmeter介绍+安装(附图)
- 性能测试工具Locust,一个开源性能测试工具
- Android 开源项目第四篇——开发及测试工具篇
- Windows下测试算法在FDDB数据库的性能
- python读取数据库准备性能测试账号数据
- 在项目初期,性能测试、调优的小结
- idea2017创建javaweb项目并导入jdbc包,测试链接数据库
- 一种简单的数据库性能测试方法
- 开源性能测试工具 - Apache ab 介绍