[Javascript] Timing Issues

[David Lovering]

I'm afraid even though the data selection is made from the client side, the
data upload is server-side driven, and it only knows what is in the query
that was submitted to it.  If a gazillion cells result from the query, the
server is obliged to squirt them all upstream as fast as it is able.
[Customer specs are a real pain, aren't they?]

If we think the "flush" method might move the already constructed <tr></tr>
blocks onto the screen, I'm perfectly willing to try doing a flush after
every record.  That would certainly improve the appearance of the
throughput, even though the total build time would be almost exactly the
same.

Just for kicks, does one do the refresh on the record, the table, or the
window?  (Or some baroque combination of all of them)...

-- Dave Lovering

----- Original Message -----
From: "Mike Dougherty" <mdougherty at pbp.com>
To: "'[JavaScript List]'" <javascript at LaTech.edu>
Sent: Monday, July 21, 2003 7:47 AM
Subject: RE: [Javascript] Timing Issues


> Are you issueing the data request from the client?  If yes, you could
> request data in smaller chunks, and write the data in whatever chunk
> size you want.  Probably no, because that approach opens other security
> related issues (and would lead to allowing cross-domain
> scripting/requests)
>
> I don't know about PHP, but the ASP model uses buffering to cache the
> whole HTML page before submitting it to the browser - but you can also
> flush the buffer periodically during the page composition steps - which
> would give the look and feel of an updating page (as long as the results
> can adequately be expressed in a stepwise manner)
>
> Another idea would be to cache the resultset of your query on the
> server, then show smaller pages - of course, that would require a paging
> scheme which can become complicated or cumbersome.  The benefit of
> server side caching is that you might never have to send all the data
> across the internet to the client, which could be a significant
> load-time performance increase.  The downside is that there could be a
> large number of round-trips from the user to the server requesting
> pages, as well as the complexity involved with implementing the cache
> and paging routines.
>
> If the purpose is more of an analytic nature, it might be better to
> suffer the long download of data then manipulate a local cache in some
> format (like XML)
>
> Usually the answer to this type of problem revolves around your answer
> to the question, "Why does the client really need such a humongous
> recordset?  If we provide a decent filter mechanism, would it be
> possible to have the user request less data in the first place?"  In the
> cases I've seen, the marketing department (for example) requests 2
> million records because they 'want everything' so they can pick out the
> 10-20k records of interest.  There's no way they can eyeball that much
> data, so they are filtering what IT delivers anyway...
>
> Or did I miss the point altogether?
>
> -----Original Message-----
> From: javascript-bounces at LaTech.edu
> [mailto:javascript-bounces at LaTech.edu] On Behalf Of David Lovering
> Sent: Monday, July 21, 2003 9:22 AM
> To: [JavaScript List]
> Subject: [Javascript] Timing Issues
>
>
> *This message was transferred with a trial version of CommuniGate(tm)
> Pro*
> One of the apps I'm working on now is a database engine for a web-site
> which
> occassionally requires humongous tables to appear on the remote
> (client-side) screen.  Since I'm using a combination of server-side
> PHP/SQL
> and client-side JavaScript to paint this, there are timing issues
> involved
> on both sides.
>
> Aside from indexing, caching, hash-codes, compression, etc. (which I'm
> investigating), one obvious way to appease the user on the client window
> is
> to paint the screen record-by-record as the data comes in, rather than
> waiting until the entire table is completed before updating the
> aforesaid
> window.  What is the best way to do this?  Are there any JavaScript/DOM
> directives that will force intermediate updates rather than waiting for
> the
> object load to complete?  Should I use the createElement directive to
> build
> each <tr> as a separate object?  Does anybody have any feel for this?
>
> -- Dave Lovering
>
>
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
>
>
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
>