实际上，平均水平的系统在单个进程创建了超过 1000 个线程之后开始会出现问题，这是由 于内存问题。可以减少线程的栈的大小以增加线程的数量，但是这种时候可以研究一下另外 一种选择。
大部分服务器最多只需要几百个线程。但是非常大容量的服务器，或者那些流量很低但是连 接的服务器数量及其巨大的服务器，比如聊天服务器会需要以一个不同的方式来实现。这些 服务器使用 Indy 会创建上千条线程。
一定要明白的是客户端的数量并不是一定要和同时存在的线程数量一样。尽管每个客户端都 被分配在个单独的线程中，但线程只在客户端被连接的时候分配。许多服务器比如 HTTP 服 务器服务生命周期很短的连接。HTTP 连接只需要不到一秒来请求网页，特别是用了代理或 者缓存的时候。假设有 500 个线程，每个连接要 1 秒钟，这就能够每小时服务三万个客户端 了。
Indy 10 除了服务器线程外，通过允许其他模型来满足这些需求。Indy 10 只受到用于分配 socket 的可用内存量的限制。
在一个忙碌的服务器里，经常需要成百上千的线程。有个常见的误解是成百上千的线程会让 系统崩溃。这是个错误观念。
在大部分服务器中，线程花费了大部分时间来等待数据。当等待阻塞调用的时候，线程是非 激活的。因此在一个 500 线程的服务器中，同时可能只有 25 个是激活的。
许多开发者创建了那些当并发线程数很少时工作的很好但是当线程数增加后很快地停顿的 多线程应用程序。这通常是由于瓶颈效应(bottleneck effect)。瓶颈效应就是当一个特定部分 的代码块阻塞了其他的线程的执行并且其他线程必须等待那块代码完成。不管其他代码允许 的多快，最慢点就是瓶颈。换句话说就是，代码只可以执行的和最慢的那部分一样快。
许多开发者把时间花费在提速他们觉得"不够快"但实际上和存在的瓶颈比起来微不足道的 部分，而不是去寻找瓶颈。
通常，排除一个瓶颈对于速度的净提升比做成千上万的其他优化提升的还多。因此，首先关 注瓶颈。之后，只有在这之后，才应该找其他代码来进行有可能的优化。