datasnap 的线程池(转)
datasnap的线程池
新的datasnap使用INDY10的线程池。不管你知不知道,DATASNAP都是使用线程池了,这和MIDAS不同,MIDAS默认是没有线程池的。
跟踪INDY10线程池类TIdSchedulerOfThreadPool的代码:
procedure TIdSchedulerOfThreadPool.Init;
begin
inherited Init;
Assert(FThreadPool<>nil);
if not IsDesignTime then begin
if PoolSize > 0 then begin
with FThreadPool.LockList do try
while Count < PoolSize do begin
Add(NewThread);
end;
finally FThreadPool.UnlockList; end;
end;
end;
end;
由此可知TDSTCPServerTransport.poolsize属性,默认值是10,表示线程池初始化的时候在池内创建10个线程,这个默 认值太小,应该设大点。TDSTCPServerTransport.maxThreads属性,默认值是0,表示线程池内创建线程的个数不设上限。池应 该设一个可创建线程数量的上限值,不能允许无限制地创建线程。
线程池的POOLSIZE属性的值应该设大些,这样线程池初始化的时候就在池内创建了许多的线程,以后需要使用线程的时候,就直接从池内取,不需要 再去创建新的线程,这节约了大量的CPU时间,但大量的线程需要占用较多的内存空间。服务器端的内存空间一般都比较大,用空间换时间的策略是值得的。服务 器端其它的对象池也应该用此策略。对象池创建的时候设置POOLSIZE=0的方法是不可取的,应该尽量设大一点,占用点内存空间其实根本不算什么。
TDSServerClass.LIFECycle属性的值对线程池的利用效率至关重要。当LIFECYCLE=SESSION,一个客户端连接从 线程池中获取一个线程为其服务,当这个客户端断开连接的时候把这个占用的线程归还线程池中,这个线程占用的时间是有些长啊;当 LIFECYCLE=SERVER,所有的客户连接都共用一个从线程池中获取的线程为它们服务,这个时候线程池好像真是多此一举不是,官方资料说是如果你 的服务器硬件穷的慌就用它,估计没几个人会穷到如此份上吧;当LIFECYCLE=INVOCATION,一个客户端发起一个事件动作就从线程池中获取一 个线程为它服务,这个有点费事,什么鸡毛点儿的事就要获取一个线程为它服务,一眨眼的时间这事它完了,线程立马归还线程池中,如此频繁,咱真有点儿担心线 程池吃的消不。所以本人满打满算还是从了官方的建议:使用默认的SESSION值。