DIOCP开源项目测试数据库性能

今天群里有个朋友说他们医院项目采用直连数据库，高峰时期sqlserver的连接数达到7000多,于是我准备做个用diocp做个demo，服务端用连接池。白天的时候我在想，并发如果7000个。如果用diocp做三层服务器，连接池应该在100个左右。今天晚上奋斗了一晚上，准备把测试过程中碰到的问题总结一下。

所有的代码测试代码写完后，准备开始测试，配置后服务端的连接池(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线程