ASP编程：ADO数据库会见的最优办法

asp对于服务器的要求较高，一般的服务器如果访问量一大就垮了，不得不重启。ado|会见|数据|数据库   　　几近一切关于ADO数据库会见功能剖析的文章，都以为二进制组件的功能老是超越注释履行的ASP代码。现实上，这是毛病的。从本文的测试了局可以看出，有些时分ASP代码的功能远远超越了组件。
　　 　　
1、引言

　　“地球是平展的...”；
　　“太阳绕着地球转...”；
　　“老是经由过程组件会见数据库...”，


　　下面三个命题有两个配合的特色：起首，它们都已经被以为是准确的；其次，这三个命题实践上都是毛病的。

　　咱们都已读到过有数的文章建议在Internet使用顶用组件封装营业逻辑和停止数据库会见，但有关这类手艺的实践功能数据却很少看到。跟着Windows 2000的刊行，IIS平台出格是ASP的功能体现也有了明显的进步。因为先行绑定（Early-binding）外部对象、模板缓冲等诸多改善，在经由过程ADO会见数据库、格局化并输入纪录集等各个方面，ASP都有一流的功能体现。

　　从本文测试了局可以看出，ASP在ADO数据库会见、纪录集格局化方面胜过组件，并且在某些情况下二者的差别到达了难以相信的水平。关于大多半Internet使用来讲，功能老是重要要素，所以在依据传说风闻或书本常识肯定最优计划之前，利用测试东西对计划停止完全的测试是很主要的。

　　在停止测试之前，本文的一切三组代码（ASP，VB和C++）都经由了优化。为了确保介入测试的代码其编码办法和测试了局都是各自范畴中最优的，它们都经由了屡次测试。某些优化任务还没有停止，这是为了让代码更真实地反应出实践使用情况中能够呈现的典范情形。

2、测试情况

　　本次测试只在Windows 2000平台长进行，在Windows NT平台上测试了局能够会有很大的分歧，所以测试所失掉的了局不合用于Windows NT平台。上面是本次测试所用体系的表示图及其申明：




　　因为测试客户机和Web办事器、数据库办事器所处的物理地位分歧，客户机经由过程三个Cisco 2924互换机毗连到Web办事器。一切这些机械都在统一大楼内，但办事器位于数据中间，而测试客户机位于另外一个房间，客户机经由过程一个400Mb Fast EtherChannel毗连到数据中间的互换机。

　　在这个设置装备摆设下，测试案例的收集延迟所引发的开支长短常小的。在平常运转中互换机之间的流量老是小于其才能的5%。

3、测试代码

　　因为这是一个从ASP、VB组件、C++组件经由过程ADO停止数据库会见的测试，因而测试代码的功效限于从了局纪录集创立一个表格。一切测试法式都可以从本文前面下载。这些法式的履行流程都相似，详细以下：


　　利用ODBC DSN创立/翻开一个数据库毗连
　　创立一个Command对象（设置其类型为adCmdStoreProc）
　　指定前往纪录数目的参数
　　履行号令，前往纪录集
　　封闭纪录集和毗连，释放这些对象占用的内存。
　可以证明上述办法具有最快的数据库会见速度，这是由于：


　　存储进程会见速度要比静态SQL快，即便启用了SQLServer 7.0的SQL企图缓存功效也一样。
　　利用Command对象并显式地指定参数要比传入一个查询字符串快很多，这是由于此时OLEDB供应者无需剖析查询类型和一切传递给存储进程的参数的类型。
　　ODBC毗连池防止了为每个翻开号令创立物理毗连。每次封闭毗连将把已翻开的毗连释放回毗连池。
布局，这是为了可以让测试法式加倍准确地摹拟出实践的纪录集处置进程。 　　前往给客户真个HTML代码是从一个两列的纪录集创立的<table>布局。一切测试法式都用while轮回遍历纪录集，而不是用速度更快的GetString办法直接从纪录集数据失掉<table>布局，这是为了可以让测试法式加倍准确地摹拟出实践的纪录集处置进程。

　　测试所用的存储进程从表中提取纪录，前往纪录的数目以参数模式传递给存储进程。

　　测试以多种分歧的纪录数目和线程数目（并发恳求数目）运转。纪录数目的局限从0行到100行，但没有测试超越100行的前往纪录数目，这是由于思索到大多半设计优秀的Web使用不会呈现如斯大范围的纪录集数据提取和格局化操作。

　　线程数目的变更局限从25到2000。在一切测试中，IIS/COM+办事器的处置器使用率大于99%，但在线程数目较少时（25，50），ASP队列长度十分小（或为0）。固然这些测试也在线程数目设置为1、5、10时运转过，但除处置器使用率以外，这些线程数目的测试没有体现出任何实质上的分歧。

　　测试所用的东西是Microsoft的Web Application Stress Tool，测试剧本的根基设置以下：


　　一切测试剧本均在收集使用率最低的时分运转。另外，测试时代IIS/COM+办事器和SQL Server上都没有停止其他操作。

　　IIS的“使用法式回护”设置成“低”，这使得使用运转具有最好的功能，出格是对COM+库使用的测试来讲特别如斯。这个设置同时也答应了一切义务在inetinfo历程内运转。

　　介入测试的五种法式为：ASP，VB组件（COM+的库使用），C++组件（COM+的库使用），VB组件（COM+的办事器使用），C++组件（COM+的办事器使用）。

　　在一切测试法式中，测试客户机的负载一向没有超越35%的处置器使用率，并且内存占用也很少。

　　有局部优化任务没有做，这是为了让测试代码更好地反应出以后的主流使用。例如，本文测试使用ODBC体系DSN创立数据库毗连，把毗连改用OLEDB的SQL Server供应者将使全体功能进步大约5-10%。

4、测试了局

　　或许你已从本文的标题猜出本次测试的获胜者应当是ASP了。上面咱们来看看详细的测试了局，切磋从这些测试数据失掉的结论。

　　本次测试的次要统计项目以下所示：




　　第一组测试中纪录集的纪录数目设置为10，线程数目在25到2000之间变更。功能的次要器度尺度，即Requests per Seconds了局以下所示：



　　从上图可以看出，ASP在功能上比和它最接近的敌手VB （In Proc ― 历程内，即COM+库使用）均匀快30%，比其他办法要快2倍以上。值得指出的是，VB（In-Proc）的功能跟着线程数目的增添而略有增添。但是，当线程数目超越大约250以后，TTFP和ASP Requests Queued已高得不再对单个办事器的正常操作具有任何意义。实践上，很多人会以为即便是250也太高了。因而，在纪录数目更多的测试中线程数目最大值不超越250。

　　测试东西的剧本运转不发生任何延迟。因而，只需对某个线程的应对一抵达，新的恳求老是当即收回。

　　在剖析纪录数目更多的测试了局之前，咱们先来看看其它两个测试目标TTFB和Hits的测试了局。



　　正如咱们可以意料的那样，ASP在一切线程数目设置装备摆设下都具有较快的TTFB。下表对照负载的增添对ASP Requests Queued和响应的TTFB的影响，一切数据都以Requests Queued -TTFP模式给出，TTFB仍然以毫秒计。




　　可以看出，当负载高达必定水平（~50-100线程局限）时就有需要到场更多的办事器来分管流量。不外本文测试仍然包括这些高负载的情况，这是为了察看是不是有能够呈现分歧的变更。

　　最初一特性能器度尺度hits的测试了局也显示出和其他测试不异的偏向，ASP的体现仍然是最优异的。

　　下一个测试步调是察看当纪录集的纪录数目增添时各个测试法式的功能体现。这里所测试的纪录数目包含：20，30，50，和100。假如你读过大批这方面的文章，能够会料想因为纪录数目的增添处置负载也随之增添，组件将体现出更好的功能。但是，现实并不是如斯。纪录数目慢慢增添时ASP仍然坚持着对其他各类办法的抢先优势。上面是分歧线程数目均匀后的测试了局。




　　即便增添了纪录集的纪录数目，ASP与其他几种办法之间的功能差别也没有甚么改动。完全的测试了局可在本文附录A找到。假如你有空的话，无妨对其他感乐趣的成绩也停止一样的测试。本文测试用的一切代码均在附录B内供应。你可以使用这些代码本人停止测试，或如需要的话停止一些修正。

5、了局剖析

　　总地看来，在Windows 2000平台上没有一种采取组件的办法可以在纯ADO操作的功能上超越ASP。固然以COM+库使用模式运转的组件比拟之下更接近ASP（并且也应当如斯），但它们与ASP体现出的功能比拟仍略有缺乏。现实上，即便是历程内运转的VB组件的功能也比ASP的差30%。但是，为了在使用所运转的组件发生毛病时回护inetinfo历程，很多使用仍然在一个公用的办事历程（dllhost.exe）内运转它们的COM+使用，在这类罕见的情形下，ASP可以供应2比1的功能优势！

　　咱们但愿本文已胜利地申明了如许一个成绩：在一个Internet使用中使用组件停止数据库会见并不是必定是最好的计划。务必在深切实行某个计划之行进行完全的测试，这一点极为主要，由于该计划的终究了局能够会和你所假想的（或你所看到、听到的）完整分歧。

　　假如Internet使用的范围属于中等或对照大，功能将成为重要的思索要素，比代码的可重用性更加主要。但实际傍边次要的使用法式很少（假如有的话）同时也是功能方面的最优计划。

　　固然，利用组件也有它的优点。组件常常是封装某些类型的营业逻辑的最好选择，出格是在跨体系集成的使用中。但是在有些情况下这仿佛走入了一个极端，前往来更深切地懂得一下现有的手艺平台、依据使用的营业情形真正地舆解数据的处置、聚集和传输进程，这才是明智的。很多时分咱们会发明奥铿剃刀道理把握了真谛：在触及到庞杂的体系时，最复杂的处理办法常常就是最好的处理办法（并且极可能是最轻易丈量的办法！）。

</p>  我想详细了解ASP整站代码与PSP整站代码有什么优缺点，那个更好，更安全，更用容易维护，和管理。。。