成功进行数据存取的指南

附件1：外文资料翻译译文





成功进行数据存取的指南

数据存取和执行时间

数据读取对象

SqlDataReader类的内部

命令行为

高速缓存策略

总结

数据存取和执行时间

　　真正的分布式的性能，数据驱动的web应用不能准确的用单一的标准来衡量。一个可靠的性能衡量需要平衡各种各样的规则，诸如执行时间，反应时间，容许能力，如此等等。这些是独立的但是严格地相关参数。极端优化这些参数中的一个不可避免地会导致下一个的破坏，你的性能真正的越危险。为了能写出执行好的应用，在各种规则中最理想的平衡需要被完成。

那就是说使优化成为一种微妙的艺术的是缺乏规则的。他们不是足以来形成可靠，其实，他们仅仅概述前面的。容许能力在性能参数中最重要，这应该被广泛的认可。容许能力被定义为每秒要求被服务的数字每单位时间要求的部件。 如果你购买他是确实有必要的，下一步你要做的是用各种方法去改进那些数字。

容许能力根据作用于服务器的客户的数字变化而变化。 可用的处理器的进程，和服务器应用作用于他们，也会影响最后的容许能力。此外，容许能力被网络等待时间严重地影响。 你能从你的代码中挤榨一些小的性能，但是如果你运行一些缓慢的连接，好，你仍然有一个问题。 解决可能是比较直接了当的，但是然而是一个问题。

　　另一个因素是执行时间，一个一点也不需要解释的参数。执行时间指的是客户端请求和产生进程所需要的字节所执行的时间。因为分布式的，数据驱动的应用(确实做其他类型的应用exist? )，执行时间直接连接到数据存取和高速缓存策略，状态管理，和有效的基础设施的可利用性。

　 尽管有一个广泛的介绍，本文仅仅集中于一个特殊的方面的性能。 这方面不是优化(执行和反应时间)的第一水平参数之一，而是高度影响其中之一。 在本文中，我将回顾一些技术来加速数据检索，考虑不同的类型，比如说分类，页，和高速缓存。 本文将不会给你一个无意义的文章，而是它将让你充满希望去查找解决你的问题。

The Data Reader Object





附件2：外文原文

　

　Tips for Successful Data Access

Data Access and Execution Time

The Data Reader Object

Internals of the SqlDataReader Class

Command Behaviors

Caching Strategies

Summary

Data Access and Execution Time

　　The actual performance of a distributed, data-driven Web application can't be accurately measured using a single metric. A reliable measure of performance needs to balance various metrics, such as execution time, response time, throughput, and so on. These are independent but strictly related parameters. The extreme optimization of one of these parameters inevitably leads to a deterioration of the next, and the more that quantities are imbalanced, the more your real performance is at risk. In order to write applications that perform well, an optimal balance between the various metrics needs to be achieved.

That said, what makes optimization a delicate art is the lack of rules. Though a few commonly accepted guidelines do exist, they aren't sufficient to form a reliable recipe; rather, they merely outline the road ahead.It is widely recognized that throughput is the most important of the performance parameters. Throughput is defined as the number of requests served per unit of time-typically requests per second. If you buy the statement that throughput is what really matters, the next step entails figuring out what weapons you have to improve those numbers.

Throughput varies according to the number of client threads that act on the server. The number of available processors, and the use that the server application makes of them, also influences the final throughput. In addition, the throughput is seriously affected by network latency. You can squeeze every little bit of performance out of your code, but if you operate over a slow connection, well, you still have a problem. It may be a relatively straightforward one to solve, but it's a problem nonetheless.