We are working on a project with a page that contains many of your controls:
3 RadTreeViews, 4 RadGrids, 2 RadMenus and many Telerik controls.
Lately, we have to examine our project’s performance in real time, over the Internet.
We were surprised to see that between the user’s click on a button at client-side until the arrival of the command on the server side – the duration is ABOUT TWENTY SECONDS!!!
THIS IS NOT ACCEPTABLE AND NO CLIENT WILL NOT AGREE TO SUCH A TURNAROUND!!!
We would like to get a solution for this critical issue asap.
Thanks,
Daniel.
UI Project Leader.
.NET Technology
ISR Corp.
6 Answers, 1 is accepted
Hi Daniel,
Could you examine the network tab of the browser dev toolbar and see what is the timing of the request? The goal is to see whether the request is initiated immediately and it takes a while to travel to the server, or it takes time to initiate the request.
If it is the former, then the issue is most likely related to the network and/or server performance/load and there is nothing we could do about it. If it is the latter, you could try simplifying the page to improve its performance. For example, rarely used functionality can be put into RadWindows so their iframes will only be loaded on demand, validation will have less fields to work with and the POST request will have less fields.
Another thing that may help reduce the server load and the resources a client machine requests from your server is using the CDNs we provide (for both skins and scripts), in addition to the MS AJAX CDN. There is even a simple web.config switch that will result in a combined script/stylesheet being downloaded to the client, instead of having many requests. You can find it here (see the Telerik.ScriptManager.TelerikCdn.CombinedResource and Telerik.StyleSheetManager.TelerikCdn.CombinedResource keys).
Also, if the time is measured through the JavaScript date and the server date, it is possible that this is simply a sync issue between the two clocks.
Generally, our controls cannot affect the performance of the network, they only provide UI functionality within the browser and they have no control over the TCP/IP stream the browser works with under the hood, because their JavaScript code is sandboxed by the browser. I can, therefore, advise that you reach out to your network administrators and see if they can help with troubleshooting networking issues.
Regards,
Marin BratanovTelerik
Rank 1
Hello Marin,
Thank you for your quick and detailed answer.
We have started doing the tests that you have suggested.
To our surprise, we have found that after the user presses a button, the requests is PENDING.
Also, the size of the data which is sent with the request is very big (around 1 MB).
It seems to us that the size of data is related to VIEW STATE.
We have a few critical questions:
A) Why is the request PENDING?
B) How can we drastically decrease the size of the data?
Please watch the attached video carefully:
https://youtu.be/dvTKkvwRumA
Looking forward for your reply,
Thank you in advance
Daniel.
UI Project Leader.
.NET Technology
ISR Corp.
Hi Daniel,
A request is shown as pending before any server response is received initially. You can see this with a simple AJAX (e.g., a button inside an UpdatePanel) by adding a call like System.Threading.Thread.Sleep(10000) to the button.Click event. The following page explains the timeline of the requests in more detail: https://developer.chrome.com/devtools/docs/network#resource-network-timing.
The first request shown in the video is the image for the loading panel, and Chrome visualizes it in the list. In the video it is taken from the browser cache.
As for the ViweState - large WebForms pages tend to have large viewstate. You can disable it for controls that do not need it and/or store it on the server instead of in a hidden field. This is a generic page optimization and the following search can help get you started with examples and more explanations: https://www.google.bg/search?q=optimize+viewstate. You may also find useful the Optimizing Performance help article, the Optimizing ViewState usage in RadGrid article, together with its entire secion on improving RadGrid's performance.
Other reasons for large AJAX responses is the way AJAX is setup on the page - if there are too many HTML elements taking part in each request, it will be larger than it needs to be. This is often the result of very high level UpdatePanels (e.g., ones placed around the main placeholder of a master page) as they result in very large portions of the page being transmitted with each postback.
Yet another possible reasons for such a long wait could be the data retrieval. For example, it could be taking a long time for the IIS to connect to the SQL server.
Neither of these are, however, issues related to or stemming from our tools directly.
Regards,
Telerik
Rank 1
Hello Marin,
Thank you for your quick answer.
We have tries to implement the compression in our project.
It does indeed help reduce the response time!
However, there is still around 7-8 seconds pending time.
If you have any further suggestions on how to reduce this time, kindly tell us.
Regards,
Daniel.
As my colleague already stated this issue doesn't seem to be directly related to Telerik UI for ASP.NET AJAX controls but a general one. You can make a further investigation on the matter to see where does the issue stem from:
- Revise the AJAX settings to ensure you are not transmitting too much content between postbacks.
- Debug the server-side logic responsible for fetching the data from the SQL server.
- Disable the ViewState of the controls that do not needed or optimize it as per the provided resources.
Regards,
Danail Vasilev
Telerik
Rank 1
There is a problem with '/api/reports/clients' request. This request takes a lot of time, and that is because of cached data located on the server-side. I don't remember exactly where is that cached data. If you could help with that it would be useful.
Greetings,
Luis Alberto Saucedo Quiroga