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值