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.
Related
SCENARIO: I have a GridView which has DropDownList in each row that gets bound on rowbound event. This data comes from Database and doesn't change very often. (say it changes weekly). As per my understanding the database it hit as many times as there are rows in GridView. One thing that I can do to minimize database hits is to use ViewState or session. BUT, the dropdown data will still be transferred to client side again and again. This is huge data (3MB).
Even I use ajax calls there would still be a lot of data being transferred.
It might not be an issue for fast internet connections but for slow internet connection will result in slowdowns. I was wondering if I can save dropdown data on client side and and bind it from there?
I came across an article that explains how I can store data on clientside in HTML5 CLIENT SIDE CACHING
But I would like a solution that works on browsers that dont support HTML5 as well. What would by my best bet and why?
I think the approach of using the HTML5 local storage is the best and the only possible in caching data larger then 100kb on the client side, but it would be hard for you to deserialize, unless you store you object as json string to the local storage, Since local storage or HTML5 is an issue you can always use cookie, but, if it really 3mb (cant imagine the size of that drop-down) it will not be possible since cookie can store MAX~5KB
As said, data is more than 3mb also not changing frequently. Two things i would suggest to do,
1. Don't store this much amount of data on browser. Use server side Cache object.if possible try to use cache dependency.
2. Use auto complete dropdown kind of stuff. Always bind top 30( or more ) data to dropdown to reduce load on page. if data is not visible in top 30 then auto complete would help to search appropriate data.
Let me know if this idea helps..
A little while back, one of the junior developers at our company was tasked with creating a website for users to enter timesheets offsite. Mostly this is used for staff that reside offshore and have limited bandwidth (it's satellite internet, so we're already looking at a 500ms - 600ms response time, typically with only 10KB/s or less, including 10% - 20% intermittent packet loss).
So it's a challenging situation...
Recently I've been tasked with helping the junior to improve the speed and functionality of the website, mostly for my own benefit, since I'm usually a desktop dev. One thing I've noticed is that the website is using MultiView and I'm wondering if that's the best approach. I can see the reasoning; download the entire website once, then just make queries back and forth, showing/hiding the various views as necessary. Except it doesn't seem to work as smoothly as that.
95% of operations required a run by the server; i.e. add a new timesheet - need to tell the server, which in turn creates a new entry in the database. When the server is done, it seems to cause the client to download the entire webpage again, which is obviously counter productive.
So my question(s) are as follows;
Is this the expected behaviour, given the above situation? i.e. Should the entire webpage be getting re-downloaded once the server has completed it's actions?
If so, is this the best approach for the situation? Would it be better to have smaller, individual pages for the various features (timesheets/leave/etc.)?
I know this is probably a bit opinion based, but any ideas or assistance is greatly appreciated; for both our benefits.
Going from memory, Multiview only renders one of the views, not all of them, but since you mention the Multiview, that tells me you are using the older WebForms technology which often carries large amounts of overhead saving/restoring state. You can try and optimize that, especially if you are using some kind of grid control.
A better approach may be to ditch WebForms and switch to a newer technology like MVC. Rewrite the application to use AJAX with a webservice that returns JSON whenever possible to reduce the amount of data that needs to be sent to and from the server. Using MVC will also reduce the number of resources required for a page load (No resource.axd, etc) which will help page load times, especially over high latency links.
Make sure the server is set to compress dynamic pages with GZIP.
Compress and minify your javascript and CSS.
Don't use inline styles (the style attribute) in your HTML (use classes or IDs+children selectors) to reduce HTMLsize.
Bundle all your javascript and CSS.
Sprite your images in CSS where possible.
Run your images through a good image optimizer like http://kraken.io
Make sure you are caching whatever you can, and the cache duration is set properly.
Minify your HTML.
Stop using WebForms (or watch your page state, and control state very closely)
Check into some of the SPA architectures out there -- you may be able to make the whole application "offline-able" with the exception of the calls to get/update/create data.
Ultimately, each page should only require 1 HTML file, 1 CSS file, 1 Javascript file, and 1 sprite sheet on the first page hit, and then every page after that should only require a single HTML file.
You might also want to look into using a client side library like angular or knockout to handle rendering views. This can reduce the amount of traffic that needs to be sent (although it likely will increase the number of requests by one).
I think the best bet is a SPA (Single Page App) with Angularjs. Done right it greatly reduces the number of http requests. Navigation does not cause entire page reload in any case. Javascript files, css files etc, are loaded just one time at app load time. Once the app is loaded in the browser, the traffic is mainly sending JSON back and forth.
There are some tricks you should apply to reduce app load time:
Bundle javascript files into just one minified javascript file.
Bundle css files into just one css file.
Levearage http cache. You can use file versioning combined with MaxAge http header, so the browser does not even ask the server if the file has changed.
Some tools to help:
Fiddler, look at what is being cached and what isn't.
Facebooks augmented Traffic Control
To my understanding, ajax would be the best choice for you. If you want to access server 95% of times and reload the page with the new elements then the performance would hamper.
So instead of doing this make partial reloading with Ajax or Jquery. There are plenty of functionality available with jquery which would use ajax and reload specific portion of the webpage instead of whole page. It would increse the performance a lot.
One more thing I would like to add is that the response packet coming from server might be huge chunk. So instead of directly throwing the response from the server, implement GZip functionality in the website. It would compress the size of the data packet and the page would load/reload much faster.
Other than these, place your CSS and JS code inside some .css and .js file instead of placing it inside the page itself(and make sure to use it maximum time from all the pages). Browser would make a cache version of those files and reuse it instead of download it every time you want to connect to the server.
I believe that you have already figured out what's wrong. No Multiview is not good if it is implemented as is without tweaks. If your website uses viewstate and on top of that you have the multiview implemented, then it is going to be a costly affair.
Here are your options.
To use most out of the code, I would recommend to convert your methods HTTP GET / POST methods which can be then called separately from the needed actions in the html.
Don't re-render the entire page, but render the content which changes on menu action.
Change the non-changing part of your page / site to static content and apply compression on the static contents.
Enable page caching.
Cache the data offline wherever possible. (Remember it comes with a overhead of syncing data).
If you are considering a revamp give a thought about HTML 5 offline features.
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).
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
I need to improve the speed of my website and perfomance.
I've tried everything under the book from compression handling , whitespace removal , update panels and enable view state false.. but nothing seem to work.
The output page size is still 764 kb.. which is quite a lot. So can you guys tell me an out of the box or any other way to approach this to decrease the output page size!
Put styles to external css files
Put javascript to external files
Try to use divs instead of tables for positioning
Short id names can help too :)
P.S.: it's difficult to advice without seeing the source
If it really cannot get further decreased, consider implementing some dynamic solution. You could first only load a main frame (without 'real frames') content page which afterwards loads more content dynamically. May use AJAX (javascript) controls or a custom solution for it.
Also, such big html code still looks strange. I doubt, the information can be (over)viewed at the same time by the user. She would at least have to scroll through some big tables or so? If you need a more smooth experience for the user, a dynamic solution may also show the content in chunks, dynamically loaded via javascript. Every time she scrolls down and a new part gets visible, that content is loaded from the server on demand.
If you are using Update Panels, try removing it. Alone Update Panel can load script file(s) which can be > 300 KB.