I'm developing an application using ASP.Net.
For first the idea: "My WebApp needs an chronometerto be shared by users and all users will se the same value in cronometer. When a user clicks on a button, the cronometer needs to be restarted and all users will need to see that!"
All right, now I'd like to know what's the best choose to improve more performace an make sure that all users will see the same value in chronometer?
Need I use JSon (with jquery in client side), Timer with UpdatePanel of Ajax Extensions, pure Ajax (with JQuery) or any idea to suggested ? Any suggestion for how to shared a cronometer for all users in C# (put information in Cache or database) ?
Thanks all
Cheers
It is impossible for all users to see the same value in the chronometer. JQuery will be faster than an UpdatePanel (an UpdatePanel needs to post the whole page back to the server), but still some kind of polling to the server is needed. You could set the polling period to 1 second - in that case the difference in users' chronometers will be at the most 1 second. Even that value however is too low for a repeating Ajax request and could easily hog browser's resources.
Related
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.
Why do I need script on an aspx page?
Javascript will allow you to perfrorm client side coding, so to avoid having to post back to the server.
From Using JavaScript Along with ASP.NET
Working logic and application
processes on the client-side allows
browser based applications to seem
more responsive and to have more
"snappiness" to them.
For client scripting, i.e. validation. There are many scenarios where you need to execute certain logic on the browser's end.
Javascript runs on the client side. So if you want anything to happen or change without refreshing the whole page you use javascript.
There are a lot of things the server can't really do that well. For example if you want to manipulate the page. You could post the whole thing back to the server with some sort of action and get the server to give you a new page. Or you could just use javascript to change it for you and avoid the trip to the server. It is faster for the client and takes the load off of your server.
It helps in doing things on the client side, which essentially means you can :
reduce burden on your server
by doing less postbacks.
do a round of validations on the client
side itself if they are non critical.
Do some fancy stuff like animations etc with out contacting the server
There are a lot more implications/uses of using JavaScript.
For knowing more, remember google is your friend!
Thanks
I'm not sure if you mean why ASP.NET pages requires Javascript, or if you mean additional scripts on the page.
ASP.NET uses Javascript for several types of postbacks. If you for example have a LinkButton, a script is making a postback instead of the default action of the link.
You can use additional scripts on the page for visual effects and to verify data before doing a postback to prevent unneccessary postbacks. (Of course you should also verify the data on the server side to protect against malicious actions.)
I have an application that makes a series of WCF calls that return JSON via JSONP. In turn javascript code will then bind that returned data to HTML controls.
When a bot / spider hits my application, no data would be indexed because javascript would not execute in the bot.
What are some good patterns for dealing with this problem? Ideally I'd like to not have to maintain two sets of data-binding code (one on the server side and one on the client side).
Essentially I need the resulting data to come downstream. Some ideas I had were to.
1) link RSS/ATOM equivalent data
2) a backdoor HTML page
3) an HTML renderer that can execute an ASPX page server side ahead of time and then pass that off to the client
Any guidance would be helpful
Option 3 can I think solve the problem, I will suggest to try this:
Try to see if javascript is enable/bot is browsing the page or not
If it is bot or js is disabled, load the page without web service call and render it with server side code
otherwise go for js version.
I will recommend this if your data is relatively low and the implementation cost is not too high.
Let's consider that I have an asp.net page which will go to the server after a client-side event and will do "some stuff" and show a return value of this process on the UI afterwords.
My question is, if I am working in the same domain, how should I decide between creating a web-service and calling that AND simply raising a post-back and handle this "some stuff" on the aspx page itself?
Under what conditions creating a web-service becomes meaningful to overcome some processes while working in the same domain?
There are no hard-and-fast rules. However, I can offer a few high-level guidelines:
Prefer an .aspx page if the result includes a significant amount of markup (HTML, JS, etc), or where generating the results is simplified by having access to control state from the original page. Keep in mind that the Page object carries a significant amount of overhead with it.
Prefer a web service for queries that can be parameterized and that return structured data
Prefer an HttpHandler for queries with simple parameters that return either simple, full-custom text or binary (such as an image)
I would look at how fast it takes for the post and reload action to occur. It depends on the user's expectations. Most people, if they know they are using a browser, will find that up to two seconds is just about acceptable for the action to occur, and the screen to be reloaded. On the other hand, in one of my jobs, I was using ASP.NET to drive a touchscreen, and this just looked totally wrong, so I refactored the code to use a static web page plus a WebService component.
You also need to take into account the capabilities of the browser. In the example above, I knew that I was only using IE6, so I could afford to write my Javascript code to take advantage of that browser. You may not be so lucky. If you are to use a web service which has client update, you should ensure that you target a version of Javascript and DOM that is supported by all your target browsers.
I have to build a site like an auction-site:
I Have a detail page from items where a countdown should run down.
In this page nearly every second a update must be possible without a postback for the user:
coundown must be reset
money of aucton must be updated
gridView with last bidders must be updated
What kind of timer should I use for the countdown?
How can I update every second from DB? ( Ajax? )
How can I update the values / gridView?
You can use an UpdatePanel with Ajax.
However, given the nature of "Internet weather," one second per update is pretty aggressive for that approach.
You might instead consider using Silverlight. You would have much more control that way, and could minimize the amount of data that needs to go over the wire. In fact, you could use long polling with raw TCP connections, to further increase scalability.
For the countdown, you can use the JavaScript timing events. To access the database, if you don't want postback then you indeed need to access the data service by using Ajax. To make things easier, I recommend that you take a look at any Javascript libary such as JQuery.
For the timer I would use Threading.Timer so this can count down uninterrupted in a separate thread. You could also use a TimerCallback delegate which would do the database processing. However, I would be wary about trying to query the database at such a rate.
I would advise you look at using Ajax Update Panel for updating the countdown section of the page alone so you don't have to refresh the entire page.