下面三个性能错误直接与windows DNA应用软件的中层级有关。在一个n层应用软件中的中间层是必不可少的综合体，因为它在整个应用软件中扮演着角色。它执行的特殊任务能被分为三个通常的对windows DNA应用软件很重要的类别。
第一个任务是接受表示层的输入。这种输入可能程序性地或者可能直接来源于一个用户。它包括关于几乎任何事情的信息（或者一个请求）。第二，中间层还负责以实现商业操作为目的的数据服务间的交互作用，这种应用软件被设计成自动操作。例如这可能包括分类和组合信息，这些信息从不同邮件列表而到达目标——一个特殊的以前从来没有考虑成为一个复合的整体的观众。最后，一个中间层返回处理的信息到表示层，因而它能够被利用，无论如何这种程序和用户看起来比较舒服。在这三个领域中，性能能够很明显得降低，那时开发者可用作设计性的实践，这些是完全难以理解的或者包含错误的而当作“正确的”去执行的实践。这些危及性能安全的错误在下一节做更充分的解释。
开发组有时采用一系列综合的类作为寻求面相对象纯度的一部分。另一方面，大量的简单对象通过授权被例示去模拟综合的交互作用。例示大量的对象和引起每一个数据存储相互作用的实践（自组装和自维护）产生低伸缩性的应用软件。很简单，针对中间层的设计和针对一个传统的面相对象的、胖客户端的应用软件是不同。与创建对象相联系的内存占用可能是很昂贵的，而且由于试图接合临近的空闲模块成为更大的块的实践甚至导致空闲内存可能更多。
开发者有时陷入与一个中部级的商业服务操作相联系的数据中心型的任务中，而不是他们应该属于的数据服务层。标准常常太严格而不能说明所有的情况，但是找到一个阻断它的理由将是非常不寻常的。如果数据中心型任务被包括在中间层，你的windows DNA应用软件与其他方式相比可能执行的更加不顺畅。
例如，从不同的表中找回多重数据设置然后在中间层的对象中连接、分类、查找数据是一个错误。数据库是被设计管理这种行为的，并且移动它到一个中间层几乎的确是一种坏的实践。确实，因为数据存储的本质可能在有些情况下，这样做是被提倡的，但是在数据集被转回到中间层之前，在数据库中这是尽可能多的发生的。
大部分开发者已经听说在MTS/COM+组件中维持状态是一件很难做的事情，但是许多的工程仍然在尝试它。有时这种情况由于希望性能不会下降到一个重要的程度而发生。另一方面，据说有时在MTS中你不能利用状态组件，而且那当然不可能是真的。可是为了达到可扩展性和性能的目的，你不能使用状态的组件。
特殊的问题又随着使用Session 和 Application 对象去存储各种状态而存在。为了定制这样的横跨多个服务器的对象大小，这些为数不少的问题当今是无能为力的。当有人试图缓存对象实例时，比如说在Session 和 Application 对象中数据库的连接，这就变成了特殊的问题（甚至在单服务器调度中）。
我们比方说你正在用微软的ActiveX Data Objects (ADO)。如果你在Session变量中存储你的ADO对象，你将会提出可扩展性的局限性和threading considerations。通过这种方法存储一个连接对象，你会失去连接合并的好处。根据性能，这会确保联接对象将仅仅服务于被建立了一个假定的session的用户，而且直到session最后，连接将会被释放到池中。如果超出时限，你也必须考虑分配给一个session变量的默认超时。对于每一个用户在Session资源释放前有20分钟的空闲时间被消费。你能通过手动和程序性地减少这段时间，但是你冒险建立了额外的困难。
为代替在一个Session变量的存储，事实上你须要在每一个可应用的ASP页上，建立它和破坏它。感谢MTS和COM+，这不包括通常与对象建立和破坏相联系的费用。通过运用一个叫做拦截术，在MTS运行环境中，MTS运行时间在一个基用户和一个对象之间插入一个被叫做context wrapper的透明层，MTS运行时间能够监测连接和操纵一个call-by-call basis。MTS需要SafeRef方法的应用，但是在COM+(windows 2000和以后的产品)中，这是不必要的，因为Contexts已经代替了context wrappers的MTS概念。
| 上一页 | 下一页 |
| 对性能和可扩展性之间关系的误解 | 对服务器资源管理的疏忽 |
