I am using multi-threading to update/display the content of page. Page is using multiple ( and nested ) update panels. Right now, i am using following logic to update page.
I have seven threads, each thread gets data by querying database and display them in specific section of page. We start threads and wait for 2 mints, after passing 2 mints if some threads still working then we break those and display the populated data on page, these calls to thread are making on page load event.
Problem here is that we must need to wait for specific time before page load, and then after that time limit, page 'll be displayed with populated data. Users need to wait for long to see the page, which making a really bad impression.
If we remove the limit of 2 mints, then page rendered fast but it does not display all data.
What i want here, when we call threads, we don't need to wait for all, when one thread completes it should show its data on page, and as soon as other threads being complete then they should display their data accordingly.
I found solution of this problem after testing many techniques.
To implement this, we don't need to use threading. When we call a page, server makes an object of this page and perform all required executions and then it render this page, destroy its object on server and send rendered page to Client Browser. So after rendering we can't receive thread's response. To receive thread's response, we must have to stop page being rendered explicitly (it causes delay, which we don't want).
So our solution is using JSON Ajax API with Web Methods (with Serialization and Deserialization if you are dealing with complex objects).
We have to load page with all controls on it, onload event of page, call javascript method which call Web Method using JSON API, after receiving response from Web Method, we have to update respective controls using JavaScript/JQuery manually.
Related
I have a performance issue where we have a 2 page setup as part of a workflow in a bigger system. This section is dedicated to rendering reports allowing users to chose their own parameters.
Page1.aspx collects parameter information for a report. It takes the information submitted on a form and validates it. If it validates OK, it stores the selections in the DB as XML, then redirects to Page2.aspx with the run id in the query string. Simple enough, performance is great.
Page2.aspx pulls the ID out of the DB and hydrates a Crystal ReportDocument object (taking milliseconds) then we call ExportToHttpStream which then renders the report as a PDF or DOC or XLS download (output format is determined in Page1.aspx). The performance of the ExportToHttpStream method is very poor due to the way our reports are written and DB indexes on the target system. This is outwith my control at the moment but I am promised that they are being worked on.
So the problem is, that when the submit button in Page1.aspx is pressed, the user experiences a very long delay before the download starts. It is then compounded by the user pressing the submit button again thinking there is a problem.
I think what I need to do is have Page1.aspx redirect to Page2.aspx. Page2.aspx should render the master page furniture and a loading div, and the report should render asynchronously somehow in the background before the save dialogue automatically pops up, after this i'd like to change the loading div to a 'Report generated, click here to go back'.
If this is the best way to achieve this, how can I load a full page, then request the report asynchronously? I'm open to any suggestions here.
You could use ajax to load the report on Page2.aspx and show a loading message while it's processing.
Look at the jQuery.load() method. This might be the easiest way to accomplish what you are trying to do.
Page1.aspx - collect parameters
Page2.aspx - report view, calls Page2Details.aspx via ajax.
Try loading Page2.aspx inside iframe and use jQuery to display waiting indicator and hide it after Page2.aspx download
Whilst both answers gave me some ground to go out and research in the right direction. My solution included using the fileDownload plugin from John Culviner to facilitate a similar solution:
jQuery fileDownload by John Culviner
This allowed me the following page structure:
Page1.aspx, gathers and validates parameters for the report and puts them into Oracle.
Page2.aspx, whilst passed in the runid (pointer to the parameters in the db) via the query string setup 3 hidden divs. Loading, Error and Success.
The script mentioned above was employed at this point. jQuery firstly sets the loading div visible then calls the plugin. The plugin dynamically creates an iframe and downloads the binary (xls/doc/pdf) from Page3.aspx. It then fires a success callback or failure. The success callback is fired by means of a cookie set at the end of the response in Page3.aspx.
I believe the plugin mentioned downloads using a 'text/plain' AJAX call in jQuery avoiding the limitation of there not being an octet-stream equivalent in AJAX.
It works, its not the cleanest solution by any means, it doesn't degrade one bit, but provides the users on our controlled intranet with an extremely responsive and pleasing UI.
I have a listview with 250 rows and 4 columns in my ASP.Net 4.0/C# application. The Rendered page size (from Trace) is 650,000 Bytes. The entire listview is in an update panel.
The listview facilitates view/add/edit/delete operations on the listview records.
Every POSTBACK action (i.e. edit click, delete click) causes a POSTBACK request of size 112,000 Bytes and an AJAX Response of ~650,000 Bytes.
The listview gets the data from a declarative data source (SQLDataSource) on the page. And the listview is bound on each round trip.
I want to reduce the data going back and forth in every call because on a slow connection, these AJAX calls take 2-3 minutes to complete.
What I have tried -
Removed the update panel over the entire listview and added an update panel over each:
ItemTemplate contents
AlternateItem Template contents
Edit Template contents
Insert Template contents
I was hoping that with the template in each row, it would reduce the size of the AJAX response since only the HTML for the update panel would come back. Unfortunately, it does not seem to work that way.
Any inputs on how the problem in my case can be solved?
Thanks in advance for looking this up.
The problem with an UpdatePanel is that you are not using real AJAX. Instead ASP.NET uses some really clever hacks to create the illusion of a partial page update. On the background, your whole page life cycle is executed. This also means that your complete ViewState is send back and forth.
If you want a faster experience, you should not use UpdatePanels. Instead, use plain HTML controls (preferably not even server controls) and use JavaScript and a server side webservice (such as WebAPI or a WCF service) to respond to the client side requests.
Those requests and response will only contain some JSON data and no markup. Your data can be kept to a minimum. If for example, a user removes a row, you only have to send the Id of the row to your service and it will return success or failure. The client will use JavaScript and maybe something like KnockoutJS to render the result. This will give you minimal overhead and a better performance.
The best possible way to do this is to not use the ASP.NET user controls and instead do this cleanly using JavaScript, JSON, HTML and a server side web service/http handler
That way you don't have to send large HTML responses from the server to client. You can also control when need to refresh and rebind your data.
I bet the whole size issue has to do ViewState. The reason being that on every postback, even if it's an AJAX postback the ViewState travels with it on every request. The only thing you can do, without making any changes, is to enable compression on the IIS side. This, at least, will send the response compressed and the browser will take care of decompressing it.
The best approach is not to use UpdatePanel and ScriptManagers at all and instead make AJAX requests using jQuery (or whatever framework you prefer) by invoking a WCF Web service. This will not trigger the full page lifecycle and will not send the ViewState on every request.
I have a web application with some pages take quite a long time to load because of what they have to do in code behind. I would like to show what is going on to the user by showing the different status of the process.
I was thinking about calling recursively (by ajax) a page which ready a value in the session. This value is set by the page that take time to load.
The problem is that the page called by ajax is not executed while the other page load is finished.
Is there some way to do that?
Thanks advance
The usual pattern here is to load an initial status page that triggers an AJAX call to retrieve the final version of the page, overwriting the original with the result of your AJAX call when it completes.
Separate the part of the code that takes a long time and call it asynchronously (e.g. as a WebMethod) on page load, e.g. if using jQuery, on document.ready. You could also fake this using an UpdatePanel which is set to conditional refresh, and the code is never run by default. Then refresh it from script using __doPostBack('updatePanelUniqueID','').
I work on ASP.NET C#. Under button click event I want to save something it's work fine, but after press the refresh button of browser, this event occurs again I want to stop this event.
An article on this subject.
Preventing Duplicate Record Insertion on Page Refresh
Approach 1
A simple solution is to
Response.Redirect back to the same
page after the INSERT command is
called. This will call up the page
without transmitting any post headers
to it. Using Request.Url.ToString()
as the first parameter of
Response.Redirect will cause both the
URL and the page's querystring to be
included in the redirect. The use of
false as the second parameter will
suppress the automatic Response.End
that may otherwise generate a
ThreadAbortedException. A
disadvantage of this approach is that
any ViewState that had been built up
will be lost.
Approach 2
A related approach would be for the form to submit to an intermediate processing page and then Response.Redirect back to the calling page, similar to the classic ASP approach to form processing. This has the same effect as simply using the Response.Redirect in the Button_Click event so it has the same disadvantages, with the added disadvantage of creating another page for the website developer to manage.
Approach 3
The next batch of solutions works by
determining whether the user has
refreshed the page in the browser
instead of pressing the form's submit
button. All of these solutions depend
on the ability of the website to use
Session variables successfully. If
the website uses cookie-based
Sessions, but the user's browser does
not permit the use of cookies, these
solutions would all fail.
Additionally, should the Session
expire these solutions would also
fail.
Approach 4
Should the user somehow manage to
circumvent the above mentioned solutions described
above, the last line of defense is at
the database. There are two methods
that can be employed to prevent a
duplicate record from being inserted
into the database. For each method,
I've moved the SQL code into a stored
procedure, since there are now more
processing steps involved and these
are easier to illustrate in a separate
stored procedure. Note however that a
stored procedure is not strictly
required in order for these methods to
work.
In my ASP.Net application I have a requirement that when a user clicks on an UI element we generate a PDF for them which they can download. This is currently implemented by doing a form post to an ashx page. This page essentially inspects the form and then executes the correct server side page which either results in HTML or a PDF document of that pages HTML.
On the client I know ahead of time if we are going to be getting a PDF or HTML, when its an HTML I open a new window and direct the form post to that window and all works well. When its a PDF I don't change the target for the form and it remains on the current page.
This works, the user is presented with a save dialog, and the current page is not changed or lost.
The problem I have is that generating the PDF takes anywhere from 1-15 seconds. What I want to do is popup a please wait dialog. Displaying the popup is going to be easy, what I am not sure of is how do I know to close the popup? The popup will be a div in the current page.
The popup can have a client side timer which polls the server for task completion. The long running server task should update the progress in a database table or a server cache object which can be accessed by the polling service.
Couple of old articles from MSDN magazine. You should be able to use the same concepts with newer libraries like asp.net Ajax.
Reporting Task Progress With ASP.NET 2.0
Simplify Task Progress with ASP.NET "Atlas"
just have some javascript on the client side and let it show some animated GIF for 1-15 seconds (your choice) and close itself after the designated time.
Gulzar's suggestion was spot on. I have a simple ajax enabled wcf service which checks a session variable. My ashx page sets the variable to false when it starts processing and then true when its done.
I think there might be a race condition if the client checks before we set the session item to false; however, there are ways around that if we modify the service to set the session item to false after a client gets an im done response.
The tricks is still going to be figuring out what the intervalon the client should be. If we set it to low the user could save the file and then see the still processing message. I'm debating myself between half a second and a second. Anything less then a half a second seems unnessecary.
You said:
When its a PDF I don't change the
target for the form and it remains on
the current page.
If that is the case then the original page will be gone when the PDF is opened. In that situation I would have a loading animated gif and open it using Javascript into a div tag overlaying the rest of the page. You would not need to close it, so no timer or polling needed. It would just be gone when the page is gone.