gpeeraer
asked on
ISAPI and NOT buffering output
I'm writing a Delphi ISPAI dll that uses several TPageProducers like :
Response.Content := MyPageProducer.Content
The problem is that the dll waits untill my entire Pageproducer finishes before sending anything to the browser, thus buffering ALL output.
Now MyPageProducer has some heavy queries in it and I want my application sending all available output while still processing the queries (thus NOT buffering the output)
Using ASP you can access some server settings to NOT buffer output, but I haven't found an equivalent in the TIsapiResponse and TISAPIRequest object.
Any ideas how i can send info to the browser while still processing the initial request?
Response.Content := MyPageProducer.Content
The problem is that the dll waits untill my entire Pageproducer finishes before sending anything to the browser, thus buffering ALL output.
Now MyPageProducer has some heavy queries in it and I want my application sending all available output while still processing the queries (thus NOT buffering the output)
Using ASP you can access some server settings to NOT buffer output, but I haven't found an equivalent in the TIsapiResponse and TISAPIRequest object.
Any ideas how i can send info to the browser while still processing the initial request?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I don't think the problem relies on the use of threads. You have a page that has to be produced and you probably won't gain any performance improvement by introducing multiple threads for 1 request.
I only said the most simple solution would be, to split up the page into different parts. For instance one main result page which includes 5 hyperlinks to other pages with subresults. This way your pageproduce time would be devided over the multiple pages/requests.
I only said the most simple solution would be, to split up the page into different parts. For instance one main result page which includes 5 hyperlinks to other pages with subresults. This way your pageproduce time would be devided over the multiple pages/requests.
ASKER
That's the problem. It's a all or nothing scheme so subresults are not available. Another solution is to provide extra frames, but this introduces the same problem, I have to wait till processing ends. The overload of one extra thread is in my situation not a real issue (intranet with limited amount of simultaneous users)
But thanks anyway.
Yesterday I tried a small example with a small browser-side javascript which every 100 msec checks if a .js file is entirely loaded. With the initial call, I spin off a thread to do the heavy processnig and respond with a page that says "wait please" and loads a .js file. This call waits untill the thread stops, then fills the js file and sends it back to the browser. if it is loaded entirely then I change the page dynamically.
The only remaining problem is the timeout of the browser when calling the js-file
I'll have to look on that too.
But thanks anyway.
Yesterday I tried a small example with a small browser-side javascript which every 100 msec checks if a .js file is entirely loaded. With the initial call, I spin off a thread to do the heavy processnig and respond with a page that says "wait please" and loads a .js file. This call waits untill the thread stops, then fills the js file and sends it back to the browser. if it is loaded entirely then I change the page dynamically.
The only remaining problem is the timeout of the browser when calling the js-file
I'll have to look on that too.
If you're browser is timing out over an intranet connection, you're total pageproduce time is indeed VERY long.
Are you sure you can't optimize the code which produces the result? For instance, with Delphi you have the benefit of using the BDE instead of ODBC, which drammaticly improves performance. If you are using ODBC or OLE DB, make sure you limit the amount of calls/queries. In general you get far better performance when you use a few advanced SQL queries, instead of allot of little queries.
Succes,
Leon.
Are you sure you can't optimize the code which produces the result? For instance, with Delphi you have the benefit of using the BDE instead of ODBC, which drammaticly improves performance. If you are using ODBC or OLE DB, make sure you limit the amount of calls/queries. In general you get far better performance when you use a few advanced SQL queries, instead of allot of little queries.
Succes,
Leon.
ASKER
I haven't encountered a time-out for now, but the project i'm involved has about 25 decentral offices, connected through very slow connections. On other projects we had a lot of problems with that aspect, so i'm foreseeing more or less the timeout problem.
I already apply both suggestions (BDE and complex queries), But even those complex queries take 10-30 seconds to complete.
(I'll be out for more than a week, so i'll stop this thread)
Happy year ending,
Geert
I already apply both suggestions (BDE and complex queries), But even those complex queries take 10-30 seconds to complete.
(I'll be out for more than a week, so i'll stop this thread)
Happy year ending,
Geert
ASKER
Your suggestion is valuable, but it introduces a lot of programming complexity (first spin of some threads and answer with html+links, which are then called by the browser, these second calls have to wait for the end of the thread and the answer to the browser) while with not-buffered output I could work from within one thread.
Is it possible to pretend that a dll is an ASP-page? (Otherwise said, can I do delphi-programming for ASP?)
If there's no other way, then I have no other choice, but have to see whether it is worth the trouble.