I have a table with 2K+ rows in it.
In chrome, firefox and IE8,9 it works fine, but in IE 7 the user will have to wait 30s or so...
The table is built using .NET's GridView.
According to some reading I've made, setting the width of the cells myself, rather than let the browser calculate it for each TD is better approach, and that what I've done...
What can I do to improve the loading time of the page?
Thanks in advance.
what you should do anyway is add paging and avoid showing 2K records on the same page inside a Grid. This should be done anyway also on the database access level, pointless to query all those rows out of the database, transport them to the web server and render them in the same page. Set up grid paging and limit the page size to something smaller usually between 20 to 100 depends on the context.
For a step by steg guide on how to enable paging, see here:
GridView Examples for ASP.NET 2.0: Paging and Sorting the GridView's Data
Like what Davide suggested, showing 2k rows is alot, and either cutting down that number or using something like http://www.datatables.net/ that can split it into multiple pages or all on one page but only loads the pages you can see.
It also supports async loading, so the users get a mucher better experience
Related
I have created web page that retrieves data from MS SQL database and display it to the user in well formatted manner. Data retrieved depend upon criteria selected by the user. But sometimes data retrieved is very large. I want to display records to the user page wise, i.e. 100 records on first page and next 100 records displayed when user clicks next button. This means only 100 records should be retrieved when user first select search criteria, next 100 records retrieved when he clicks next button and so on, as to reduce data transferred from server to client.
Please suggest me how to achieve this as soon as possible. Thanks in advance.
What you are looking for is called paging.
This can be done a million ways. You mention jquery, javascript and asp.net. For displaying purpose that is quite all righ but for good performance you want to make sure that the actual selection of the page has to be done at the backend.
One approach is this:
http://msdn.microsoft.com/en-us/library/aa479347.aspx This is not jquery but it shows a way to do it.
You can use jqGrid or DataTables. Both are very popular grids
Ask user to set there criteria and then render the grid according to that.
If you want simple fast and way then think in using jQuery plugins like these
jpaging OR datatables.
you should search for design pattern for this.
kindly look at this Easily build powerful client-side AJAX paging, using jQuery
Your use of both asp.net and C# makes me (probably because I am partial to it) think "WebMatrix". If, indeed you are using WebMatrix, check out its Grid Helper. However, be warned that this method can generate some very serious overhead for your html page (by that I mean that if you query 1,000 rows and only use 100 per page, it will retrieve all 1,000, use 100, and waste the other 900). Also, using the WebGrid generates the results in a table, which may not be your preferred style.
Alternatively (still thinking "WebMatrix"), you could use this article here (this is my preferred method): http://www.mikesdotnetting.com/Article/150/Web-Pages-Efficient-Paging-Without-The-WebGrid
Don't worry, that article is explained with EXCELLENT brevity and accuracy (and explained better than I could, so I leave it to Mike to vicariously answer that one).
GridView in my ASP.NET application is working very slowly when changing pages. I know that this is most probably caused by a lot of data being pooled out of database each time page is updated but I don’t know how to fix this since I’m not to ASP.NET.
My current configuration is GridView with ObjectDateSource and paging enabled. I don’t have any code behind or anything similar. ObjectDataSource is bined to typed data set.
You are correct about the cause of this – it’s the fact that you have to get all the data from database even if you only want to display one small part. For example, you retrieve 5000 rows from DB only to display 15 rows in current page.
Solution for this is implementing custom paging.
In order to get this to work with your current configuration you’ll need to update your current select method to accept the starting index and maximum number of rows input parameters and also update following properties in your grid view
“StartRowIndexParameterName”, “MaximumRowsParameterName”, “SelectCountMethod”.
Here is a great article that covers what you need but there are also a lot of topics here on StackOverflow that cover this topic.
I found the same problem and implemented a custom gridview which is now opensource, you can find it here https://github.com/vcliment89/GridViewEX. You don't need to implement all the gridview but there's an example of a custom pager on the demo project.
Now this is going to be a very absurd question. But what can I do, it's the client's requirement. Basically, we have a grid (master-detail type) that goes up to about 15 thousand plus rows (has the potential to go up to 30-50 thousand rows in a few years time).
My client does NOT want any paging, does not want any data cropped as well. Also he isn't exactly using the latest hardware so rendering on browsers is a big issue. He wants to view everything by printing it out or looking through it on the browser. (You may all think how insane that sounds, and it sure is).
Now I want to resolve this issue by rendering html quickly. At the moment its a simple asp.net grid view w/o paging. That essentially renders HTML tables. My options that I think are:
- Manually rendering html using div (for quick loading)
- export it to pdf or excel (is there any way to export without the need to resort to third party controls?)
- give the finger (to the client :D j/k)
So to sum up, whats the best way to show 10,000 plus records of data on html?
consider using the "Scroller" plug-in for Datatables..
As part of DataTables 1.8 release a new plug-in called "Scroller" was
introduced as part of the download package. Scroller is an
implementation of virtual scrolling for DataTables, which presents a
vertically scrolling table, scrolling the full height of the table,
but drawing only the rows which are necessary for the visible display,
leading to a huge performance increase. This is quite an exciting
plug-in for DataTables not only for the performance increase, but also
because it effectively provide a new user interaction with the table,
allowing full scrolling of very large data sets.
I know this is almost a year late, but in case it helps someone.
Use SlickGrid - It uses divs instead of tables, which gives so much more performance in IE. Check this example
He wants to view everything by printing
This is imho the only viable solution to view all information. PDF or Excel is much better at handling a large number of rows.
Doing the rendering is quite easy. Just set the excel mime type and return a HTML table.
http://www.designdetector.com/archives/05/07/HTMLToExcelTheEasyWay.php
When it comes to PDF, you probably have to use an external library like PDFSharp.
You should do the paging - it does not mean that you need to show only one page of data at a time but rather you should retrieve and render pageful of data at a time (and keep continuously fetching pages one after one till data is finished).
For example, send the first page of data from the server in the initial request. Setup a js timer and use AJAX requests to retrieve subsequent pages of data and load that into the browser. You can have multiple (say 3-4) AJAX requests going on simultaneously for retrieving pages - only thing would be to achieve the ordering correctly in such approach.
I will personally avoid grid-view and render the html table using manual java-script (with help for jquery) or use some java-script template engine. I will use JSON for retrieving the data from the server.
Hi
Let's say that I've to list thousands of records for my client.
How should I implement this? Some say that I have to retrieve just 300 or 400 records from the database and show those to the client. But I think there will be some problem with pagination. If I get all records from the database then I will have a performance problem. Some say to implement our own store procedure. How should I do this?
Thanks
You definitely have to use paging and not retrieve all the records at once, I recommend using some ORM tool to abstract the complexity of the required query for paging, if using LINQ it would be something very simple: ...Skip((pageNo-1)*pageSize).Take(pageSize)
I am in favor of sending ~100 records with the page, paginating through them by JavaScript, and retrieving further records in a batch by some higher number, say, 1000, when user navigates to unloaded data. All with no-script fallback links if you can't force user's to use JavaScript.
(Not sure how easy this is with C# frameworks; with Java's Wicket, this is quite easy.)
Paginate the records ! That will the the only solution (which you haven't yet tried by the way!). You could add Button controls to move between pages, and data loaded to a page when the page is loaded. Or the records could be loaded all at once and stored by the app, and just shown to the user when a page is shown.
Paging is definitely an answer to this. However - Do all your match inside SQL Stored Proc.. Instead of depending on the GridView default paging...
If you don't want to use Paging (some clients are very adamant to show all records) then you can use Scroll event to fetch records on the fly. If you using a Web Application, you can use Ajax Call to fetch next set of records by passing the pageNo,pagesize etc....
I'm working on a page that has several server side dropdown lists, one with 500 items. Based on what's selected, I show/hide other page elements during postback (I only bind the data on initial load). The customer opens this page a lot and I don't want them pulling the 500 items down every time they open it. Currently, it takes about 2 to 5 seconds for the page to render. I've started to migrate to a fully javascript/jquery version of the page but want your opinion because I'm not loving the new version.
Is there a way to make this page faster and limit pulling down all 500 items every time?
Note: Some users will want to enter the dental procedure code directly. Others will need to do a look up.
We work on a system where a user's name can be selected from a dropdown list and then user information is displayed below. There are approximately 600 users and one of the stakeholder requirements was that the users had to be selectable in a dropdown list - the stakeholders felt that non-technical users better "understood" how to use a dropdown list.
Our performance for loading the dropdown list is very good. We do the following:
Load the page as quickly as possible but DO NOT load the dropdown list
On page load, display a loading indicator and then immediately fetch the data for the dropdown list
We get the data by calling a webservice using jQuery that returns ONLY usernames and IDs and data is returned in JSON format
The query that requests the data is cached on the server for future requests
The resulting JSON object is used to populate the dropdown list
Hide the loading indicator and you're done
The above occurs extremely quickly and makes for a very pleasant user experience.
If anything, try very hard to do the following:
Avoid postbacks even if you're using an Update Panel - these will kill performance if you have a large viewstate
Only return the absolute bare minimum of data that you need to populate the dropdown list
Don't access any data that isn't immediately necessary. Get the page loaded as quickly as possible and then fetch the remaining information while the user is reading the page
When adding large amounts of data to a page, milliseconds count. Anything you can do to reduce calls for data (and the subsequent adding of that data to the page) will drastically improve the user experience.
It's been a while since I've done asp.net but remember something from the Ajax control toolkit that is like a set of filtering drop downs that group items so you don't have to get the full list.
For example if you're getting a list of all cars, you could have the first drop down as Manufacturer, which when selected activates a second drop down with their range of Models. It limits the ammount of data you have to load at once.
A dropdown list is not a good container for 500 items because the looong list looks ugly and it's hard to locate an item. You can change it to a table-like control(from server view, a gridview or a repeater) with paging function(e.g. display 20 items per page), also you can add some textboxes above the table, users can quickly locate an item by typing some keywords. After that, put the table in a update panel to make the page partially updated when clicking some button.
Anything you can do on the page that doesn't require the entire page to change can be made AJAX-y by enclosing it in an UpdatePanel. UpdatePanels and ScriptManagers allow ASP.NET pages to perform partial postbacks using AJAX, which will speed up anything but a full page reload by drastically reducing the number of data that has to come across.
Other performance tips/tricks:
If you're using an ORM, or generic queries, to pull in records, try to pull the minimum amount of data you need to show the results. The more data that has to come from the DB and be digested into the viewmodel, the slower the back-end will be.
Avoid nested MultiViews. Multiviews are great for organizing a lot of data in a "tabbed" fashion, but behind the scenes a MultiView is rendered as a series of divs with CSS to hide/show them. That means that EVERY tab of a MultiView must be rendered on the initial page load. When multiple MultiViews are nested as Views of other MultiViews, the problem is compounded. You can avoid this by using the codebehind to dynamically select and insert the proper control into the page, or by using other code to detect whether the View that this control corresponds to is the currently-selected view, and skip any heavy lifting of data retrieval/processing that would otherwise happen. You may combine either approach with some AJAX components.
I'd start with correctly indexing the database.
One way to speed things up would be to get rid of the postbacks. Showing/hiding page elements is a client-side operation and doesn't require a postback. If you're using jQuery already, you can .show() and .hide() any element on the page.
This doesn't necessarily address the performance of the initial page load, but would improve the performance of the overall user experience when interacting with the page.
For the initial load, perhaps break out various data-bound elements into AJAX calls that happen behind the scenes after the initial page markup loads? I'm kind of shooting in the dark here without knowing a whole lot about the page, but it's worth a try. Maybe load the basic markup without the data in the lists, then on $(document).ready() make an AJAX call to a server-side handler which returns the elements for the first menu. Then, when each menu is selected, fetch the elements for the next menu in the same manner.
The overall load time would be roughly the same (maybe even a fraction of a second longer), but the UI would fully render in the meantime and you'd be using the time the user spends looking at the page and starting to interact with it, a few precious seconds, to load the rest.
Edit: In response to one of your comments above on the question, maybe you can use the jQuery UI Autocomplete to improve the user experience a little? Do the users necessarily want to select the codes from a list, or would it be easier for them to start typing the code and narrow down to the correct one? From a data-entry perspective, avoiding mouse usage is often a good idea.
Using javascript or any of client script is not an solution because the client browser may have javascript disabled...
I would suggest you these opmization,
Optimise database query if your table containing 500 records and
is not frequently have insert/update operations then create unclustered indexes.
Cache the data if not changes frequently.
Create stored procedures improves query results because it's being precompiled query and prevents sql injection attacks.