文件描述符限制通常一个容器上文件描述符的数量有一个固定数值的极限。设计必须限制最大的数字在这个极限以下。如果阻塞的描述符从文件描述符池取出，那么具有大量连接数 （ftp, com, 启动程序, 客户端,等等）的设计将导致问题。大规模条件下，描述符的数量可能有一个峰值。随着规模的增长，描述符泄漏会用光可用的描述符池。 Socket缓存限制 每个socket
都有一个分配数量的缓冲空间。大量的socket能减少可获得内存的全部总量。随着规模的增长，丢弃增多，因为用来接受消息的缓存数量不足以跟上负载。这
也与优先级有关，因为任务可能不具有从socket读出数据的足够优先级。在发送方，高优先级的任务可能用消息将低优先级的消息淹没。 引导镜像服务限制 在同一时刻，每个节点能提供的启动条目数量限制为X。ftp服务器基础设施必须限制它所服务的对象数量，否则该节点会使CPU停止工作。 混乱的消息在压力之下，消息系统可能会开始无序分派消息，这会导致需要非指数数量级操作的问题。 协议弱点除非应用协议是仔细创建的，否则增长的规模将带来非常多的问题。连接数限制某种带十个客户端的中央服务器可能有足够的性能，但若带一千个客户端，它可能无法满足响应时间需求。在这个场景，平均响应时间大概随着客户端数量线性变 化，我们称其具有O(N)("规则 N")的复杂度，但也有其它复杂度的问题。例如，如果我们希望一个网络中N个节点能互相通信，我们可以将每个节点连接到一个中心交换设备，需要O(N)连 线，或者我们也可以将每一对直接连接，需要O(N^2)连线（确切的数字或公式通常不是那么重要，相较于涉及的N的最高次方来说）。 分层架构这是 一个很好的总结 ，所以这里只是参考一下吧：基于层叠的架构从来就不是说能够创建低延迟，高吞吐率的应用。分层架构的基础问题是，它是创建来解决昨天的问题的。从客户端-服务器时代过渡到互联网时代，它是解决可伸缩性的完美解决方案。 问题域是怎样伸缩应用支持成百上千的用户。这个问题的解决方案是我们今天知道的n层架构。选择伸缩性规格在于基于过负载均衡的表现层。确实它实际上解决了这个问题。但是，现在问题已经进化了。现在很多行业里，问题不仅仅在于提升用户体验，它也是一个数据容量的问题。 多处理器性能问题当处理器被请求在大量不相关工作负载之间切换的时候，神奇的硬件缓存加速将趋于崩溃。
|
