Some best bets:

This is a really good checklist by an experience performance tester, J.D. Meier

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnserv/html/server03272000.asp

25 Tips from George Reilly – talks about Use Server.Transfer Instead of Response.Redirect Whenever Possible

http://msdn.microsoft.com/library/default.asp?URL=/library/en-us/dnasp/html/ASPtips.asp

Use ordinals to reference record sets. This looks promising.

http://www.4guysfromrolla.com/webtech/120299-1.shtml

This site summarizes a lot of tips

http://www.sql-server-performance.com/asp_sql_server.asp

The Cache Property of the RecordSet Object

This is a interesting article on cache size when getting back a record set “The performance measuring in Professional ADO 2.5 Programming (Wrox Press) realized a 33% performance boost using a .CacheSize of 10 (page 421). [With .CacheSize of 1, 10 and 100, they were able to serve 752, 1003, and 1033 pages, respectively.]”

http://www.4guysfromrolla.com/webtech/053100-1.shtml

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnproasp/html/workingwithcachesizeproperty.asp

http://www.programmingmsaccess.com/TheBook/ADOExcerpt/The%20Recordset%20object.htm

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iisref/html/psdk/asp/perf7xnp.asp

Set the ADO CacheSize property to a larger number than the default (1). By forcing ADO to retrieve multiple records in one transaction with the data source, you will eliminate a portion of the overhead involved in that transaction, and your application may become more scalable. Generally, you are most likely to see benefits if you set CacheSize to equal to either the number of records expected, or 100, whichever is less.

Use the ADO 2.0 AdExecuteNoRecords flag when executing commands that don't return data rows, or that return rows that you don't need to access or save. This new feature, introduced in ADO 2.0, was created to reduce the amount of overhead incurred by ADO, and thus increase performance and scalability.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/cutting0300.asp Accessing Recordsets over the Internet

Another property to consider carefully if you want to get the most out of your recordsets is CacheSize, which defines the number of rows that ADO will fetch and cache. If the required record is within the range of cached rows, reading it is much faster. The buffer is updated as soon as you move out from the current cache while scrolling the recordset. Choosing the right size for the cache is highly subjective. The default value is 1. You almost definitely want to increase this value to a level that makes sense for the data you're transmitting, proportional to the actual speed you experience between your client and server.

improvperf.asp Improving MDAC Application Performance

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wp/htm/wpimproveperformancemdacapplication.asp

Tune the Recordset.CacheSize Property

ADO uses the Recordset.CacheSize property to determine the number of rows to fetch and cache. This especially affects server-side cursors. While you are within the range of cached rows, ADO just returns data from the cache. When you scroll out of the range of cached rows, ADO releases the cache and fetches the next CacheSize rows. The default value for the CacheSize property is 1. How do you determine what value you should use for the CacheSize property in your application? Unfortunately, there isn't a single optimal CacheSize value for all applications. You should try tuning your application with different CacheSize values, and use the value that offers you the best performance. For example, knowing that a small CacheSize value significantly improves performance for fetching data from an Oracle data store might be an important factor for you.

               VB Example of Cachesize              rstRoySched.CacheSize = 30

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/mdprocachesizex.asp

Description of cachesize property

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vb98/html/vbprocachesize.asp

Interesting URL about the properties of the recordset object

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/mdobjodbrecpme.asp

Cachemanager Object

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/comsrv2k/htm/cs_sp_catalogobj_kpkg.asp

Locks

http://www.sql-server-performance.com/asp_sql_server.asp

When using recordsets, be sure to open them explicitly, not implicitly. When recordsets are opened implicitly, you cannot control the default cursor and lock types, which are, respectively, forward-only and read-only. If you always open your recordsets explicitly, then you can specify which cursor and lock types you want to invoke for this particular situation, specifying the types with the least amount of overhead to accomplish the task at hand. [6.5, 7.0, 2000] Added 12-14-2000

Information on the locktype command. This is interesting because I see that we are locking huge numbers of recordsets on the SQL server

http://www.4guysfromrolla.com/webtech/062799-3.shtml

Related article with graphs

http://www.4guysfromrolla.com/webtech/062799-3.report.shtml

http://www.vb2themax.com/Item.asp?PageID=TipBank&ID=264

If you must use a cursor-based Recordset, don't ask for more features than you actually need. For example, always specify LockType = adLockReadOnly if you don't plan to update the database (or if you can do it through direct UPDATE or INSERT SQL statements). Don't create a server-side dynamic cursor if you can be satisfied with a keyset cursor. And so on.

SQL Server Web Asssitant

http://www.4guysfromrolla.com/webtech/062200-1.shtml

Microsoft Article about breaking the recordset into pages:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnserv/html/server05222000.asp

reusing the same connection and objects can improve performance

http://www.eggheadcafe.com/articles/20010418.asp

Interesting article about reading large text strings.

http://www.4guysfromrolla.com/webtech/010401-1.shtml

Interesting article about using a third party app to convert asp into HTML for faster performance

http://www.4guysfromrolla.com/webtech/071800-1.shtml

Some simpler performance Tips

Use components

http://www.15seconds.com/issue/000106.htm

Convert the ASP into an Active X server side component

http://www.webdevelopersjournal.com/articles/asp_performance.html

http://www.webdevelopersjournal.com/articles/activex_for_asp.html

http://www.vb2themax.com/Item.asp?PageID=TipBank&ID=264

http://www.xtremewebdevelopment.com/article.asp?id=3

If you have more than 100 lines of ASP code try to write it in a COM Object. Compiled COM objects run faster than interpreted code. Compiled COM Objects allow you to use Early Binding, which is a more efficient means of invoking COM objects than the Late Binding which is used in script.

http://accesshelp.net/survival/responseasp.asp

http://www.sql-server-performance.com/asp_sql_server.asp

“Web sites that publish large amounts of text to web pages from text stored in SQL Server often experience performance problems. This is because it is time-consuming to run one or more queries against SQL Server data, retrieve the data from the database, and serve it up into a formatted web page, ready to display. While a request for a single web page is no big deal, but if you have a busy site and there are hundreds of people all wanting to see the same page at the same time, this can produce a large load on SQL Server.

What is especially frustrating is that each of your users will end up viewing the same page, even though SQL Server has to retrieve the same text over and over. This is a lot of wasted effort on SQL Server's part. Wouldn't it be more efficient if SQL Server only had to retrieve the data once, and not repeatedly?

The solution to this problem is to produce the static web pages only one time, and then serve up the static web page each time it is requested. This of course assumes that each page is not individually customized for the user. But if this is the case, why bother to store the text in a database in the first place? The reason has to do with management of the text. If you have hundreds or thousands of text articles to manage, this is very difficult to do by hand using HTML editors.

What is needed is a solution that combines storing and managing text in SQL Server, but that produces the static pages every time new text is added, or if the text should change.

There are several ways to deal with this. One way is to use the SQL Server Web Assistant Wizard. Another way is to create your own ASP pages or COM objects to create the static pages. Another option is to purchase a third party product. Whichever method you choose, don't force SQL Server to do the exact same thing over and over when it is not required. [6.5, 7.0, 2000]

XML

This might be useful

http://www.sql-server-performance.com/jg_xml_performance.asp

http://www.sql-server-performance.com/jb_openxml.asp

Time your ASP

http://www.developerfusion.com/show/240/