|
 |
asp_databases thread: Re: Parsing results
Message #1 by "Ken Schaefer" <ken@a...> on Fri, 1 Nov 2002 14:36:01 +1100
|
|
a) Why are you displaying 20,000 records on a single page? Can you use
record paging instead?
b) Are you using lots of Response.Write() statements or are you building a
huge string on the server and then doing a Response.Write(strHTML)? If the
latter, then you'll have problems because string concatenation in VBScript
sucks performance wise.
c) You do have Response.Buffer = True?
d) Suppose each record is 1000 bytes. You add various bits of HTML to it.
You're talking about sending a 20 MB(!!) HTML page to the browser. Lots of
browsers will choke on rendering this, especially if you have nested tables
etc. If you really need that sort of data, try to unnest tables, create
multiple tables (since a table will not be rendered until the closing
</table> tag is reached) etc.
Cheers
Ken
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "Stephan Bussing" <Stephan_bussing@h...>
Subject: [asp_databases] Parsing results
: I have a problem and I'm wondering if anyone here is able to help me out.
: I'm developing an intranet application with ASP and SQL 2000. To retrieve
: records from the database I use stored procs in the SQL DB This all
: together is no probleem. But when I want to display the results It takes
: so much time that in some cases there is a scripttimeout. Of course I can
: set the timeout property higher, but I don't think it'll solve the
: problem. I'm talking 1000 till 20.000 records which have to be shown. I
: build in some checkpoint where I measure the performance. What I found out
: is, that it takes about 2 seconds to retreive the recordset. But after
: that I have to iterate through the recordset and add some html to show the
: records. To retrieve the results form the database for about 5000 records
: is maybe takes 1 second if I use the query analyser. In the asp pages it
: takes at least 20 seconds before the result is shown. All I could find out
: is that the whole page is already in memory, but when it's parsed to the
: client there's a dramatic loss of performance. Does anyone have
: suggestions to speed this up.
:
: Thx.
:
: Stephan
Message #2 by "Stephan Bussing" <stephan_bussing@h...> on Fri, 1 Nov 2002 07:33:37
|
|
Hi Ken,
I was wondering if I could use paging. I didn't look into it yet. I do use
response.buffer = true. Should I use the false value? Anyway, I don't use
multiple response.write statements nor a lot of nested tables. I'll try to
give an example:
I use classes to connect to and retrieve data from the database. One
record has about 10 fields. Around each field I put the <td>-tags. All
this is put in one string. The function which retrieves the data sends
this whole string back as a result.
I also made a template like this (this is only a part of it of course.
You'll miss the <html>-tags etc.)
<body>
<table>
@String_to_be_replaced@
</table>
</body>
After I received the data from the function I described, I use an other
class to parse this data to the template and then replace the @_@-...
with this data. There's nothing special about this. The replacement is
done with regular expressions. As mentioned earlier I build in some
checkpoint to see how long each step in the process takes. Unfortunatly I
cannot measure the time between the data parsed to the template and the
time the result is shown. At that point all asp-code has already been
excecuted. I use this construction to seperate the ASP-programming from
the HTML-pages. Because of this construction I think I cannot use paging.
I hope you know what I mean by all this! :)
Thanks for your replies.
> a) Why are you displaying 20,000 records on a single page? Can you use
record paging instead?
b) Are you using lots of Response.Write() statements or are you building a
huge string on the server and then doing a Response.Write(strHTML)? If the
latter, then you'll have problems because string concatenation in VBScript
sucks performance wise.
c) You do have Response.Buffer = True?
d) Suppose each record is 1000 bytes. You add various bits of HTML to it.
You're talking about sending a 20 MB(!!) HTML page to the browser. Lots of
browsers will choke on rendering this, especially if you have nested tables
etc. If you really need that sort of data, try to unnest tables, create
multiple tables (since a table will not be rendered until the closing
</table> tag is reached) etc.
Cheers
Ken
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "Stephan Bussing" <Stephan_bussing@h...>
Subject: [asp_databases] Parsing results
: I have a problem and I'm wondering if anyone here is able to help me out.
: I'm developing an intranet application with ASP and SQL 2000. To retrieve
: records from the database I use stored procs in the SQL DB This all
: together is no probleem. But when I want to display the results It takes
: so much time that in some cases there is a scripttimeout. Of course I can
: set the timeout property higher, but I don't think it'll solve the
: problem. I'm talking 1000 till 20.000 records which have to be shown. I
: build in some checkpoint where I measure the performance. What I found
out
: is, that it takes about 2 seconds to retreive the recordset. But after
: that I have to iterate through the recordset and add some html to show
the
: records. To retrieve the results form the database for about 5000 records
: is maybe takes 1 second if I use the query analyser. In the asp pages it
: takes at least 20 seconds before the result is shown. All I could find
out
: is that the whole page is already in memory, but when it's parsed to the
: client there's a dramatic loss of performance. Does anyone have
: suggestions to speed this up.
:
: Thx.
:
: Stephan
Message #3 by "Ken Schaefer" <ken@a...> on Mon, 4 Nov 2002 12:33:06 +1100
|
|
Hi,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "Stephan Bussing" <stephan_bussing@h...>
Subject: [asp_databases] Re: Parsing results
: I was wondering if I could use paging. I didn't look into it yet.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As I said before - if you are dumping 20,000 records to the browser, and
each record is 1 kb, then you are sending a 20 MB HTML file to the browser.
You will have a *major* delay not in the ASP processing, but in the HTML
rendering of this by the browser.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: I do use response.buffer = true. Should I use the false value?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: Anyway, I don't use
: multiple response.write statements nor a lot of nested tables. I'll try to
: give an example:
:
: I use classes to connect to and retrieve data from the database. One
: record has about 10 fields. Around each field I put the <td>-tags. All
: this is put in one string. The function which retrieves the data sends
: this whole string back as a result.
:
: I also made a template like this (this is only a part of it of course.
: You'll miss the <html>-tags etc.)
:
: <body>
: <table>
: @String_to_be_replaced@
: </table>
: </body>
:
: After I received the data from the function I described, I use an other
: class to parse this data to the template and then replace the @_@-...
: with this data. There's nothing special about this. The replacement is
: done with regular expressions. As mentioned earlier I build in some
: checkpoint to see how long each step in the process takes. Unfortunatly I
: cannot measure the time between the data parsed to the template and the
: time the result is shown. At that point all asp-code has already been
: excecuted. I use this construction to seperate the ASP-programming from
: the HTML-pages. Because of this construction I think I cannot use paging.
: I hope you know what I mean by all this! :)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is still unclear what is happening. Are you saying that you are creating
one mammoth string and placing it into the above "template"? If so, you
could be having a string concatenation problem. You may be able to get
around this problem by having multiple Response.Write() statements (rather
than concatenating a huge string and Response.Writing() the single string).
Also, you need to be aware that if you have a single HTML <table></table>,
the browser will *not* render (display) anything until it gets to the
</table> tag. To improve "perceived" response time, you could split your
table into mulitple HTML tables, ie:
<table>
<!-- 100 records here -->
</table>
<table>
<!-- Next 100 records here -->
</table>
etc
Cheers
Ken
Message #4 by "Stephan Bussing" <stephan_bussing@h...> on Mon, 4 Nov 2002 17:26:17
|
|
Hi again,
thx for the advice. I think the last solution come more in hand. Splitting
into multiple table. I will try to do that. As faras concerning you
question about one udge string, thats correct. It's just one big string.
Thanks. I don't know wath else I can do about it. But again. Thanks for
the help.
Greetz
> Hi,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "Stephan Bussing" <stephan_bussing@h...>
Subject: [asp_databases] Re: Parsing results
: I was wondering if I could use paging. I didn't look into it yet.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As I said before - if you are dumping 20,000 records to the browser, and
each record is 1 kb, then you are sending a 20 MB HTML file to the browser.
You will have a *major* delay not in the ASP processing, but in the HTML
rendering of this by the browser.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: I do use response.buffer = true. Should I use the false value?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: Anyway, I don't use
: multiple response.write statements nor a lot of nested tables. I'll try
to
: give an example:
:
: I use classes to connect to and retrieve data from the database. One
: record has about 10 fields. Around each field I put the <td>-tags. All
: this is put in one string. The function which retrieves the data sends
: this whole string back as a result.
:
: I also made a template like this (this is only a part of it of course.
: You'll miss the <html>-tags etc.)
:
: <body>
: <table>
: @String_to_be_replaced@
: </table>
: </body>
:
: After I received the data from the function I described, I use an other
: class to parse this data to the template and then replace the @_@-...
: with this data. There's nothing special about this. The replacement is
: done with regular expressions. As mentioned earlier I build in some
: checkpoint to see how long each step in the process takes. Unfortunatly I
: cannot measure the time between the data parsed to the template and the
: time the result is shown. At that point all asp-code has already been
: excecuted. I use this construction to seperate the ASP-programming from
: the HTML-pages. Because of this construction I think I cannot use paging.
: I hope you know what I mean by all this! :)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is still unclear what is happening. Are you saying that you are creating
one mammoth string and placing it into the above "template"? If so, you
could be having a string concatenation problem. You may be able to get
around this problem by having multiple Response.Write() statements (rather
than concatenating a huge string and Response.Writing() the single string).
Also, you need to be aware that if you have a single HTML <table></table>,
the browser will *not* render (display) anything until it gets to the
</table> tag. To improve "perceived" response time, you could split your
table into mulitple HTML tables, ie:
<table>
<!-- 100 records here -->
</table>
<table>
<!-- Next 100 records here -->
</table>
etc
Cheers
Ken
Message #5 by "Ken Schaefer" <ken@a...> on Tue, 5 Nov 2002 12:57:47 +1100
|
|
Hi Steven,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "Stephan Bussing" <stephan_bussing@h...>
Subject: [asp_databases] Re: Parsing results
: Hi again,
:
: thx for the advice. I think the last solution come more in hand. Splitting
: into multiple table. I will try to do that.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: As faras concerning you
: question about one udge string, thats correct. It's just one big string.
: Thanks. I don't know wath else I can do about it.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I've told you several times: One solution is to use multiple
Response.Write() statements.
If you're not careful, string concatenation will kill your application:
http://www.adopenstatic.com/experiments/stringconcatenation.asp
(there are ways to get around this problem - using a concatenation class for
example)
Cheers
Ken
|
|
|
View Cart
