|
|
Posted by Erland Sommarskog on 10/02/87 11:45
IanIpp (ian.ippolito@gmail.com) writes:
> I'll give you a real life example. This is the most heavily used page
> on the site (about 60% of the volume of traffic) and thus 60% of the
> queries to the database:
>
> http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequests.asp?lngBidRequestListType=3&optSortTitle=2&lngBidRequestCategoryId=-1&txtMaxNumberOfEntriesPerPage=10&optBidRequestPhase=2&lngSortColumn=-6&blnModeVerbose=True&optBiddingExpiration=1
>...
> Some other interesting things. The biggest killer of time on that page
> is the fact that it involves paging. This means that:
So each time I request the next page the query is rerun? Here is a tip
from a pure end-user perspective. Spit out 100 of entries at time rather
than just 10. I don't know why web designers insist on giving my small piece
at time. Give me at least 100 items at a time. I've better things to do all
day, than paging forth and back in a lousy web browser. On top of that,
if the query is rerun each time I page, I may get to see different results.
From a more technical perspective, saving the search results in a process-
keyed table could be an option, although it means that each initial search
will require a write operation, and if users don't page very often, it
could just make matters worse. (Then again, here is an easy option to
scale out: the middle tier could receive the full result set, and then
write the search to different server.)
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Navigation:
[Reply to this message]
|