Obviously, I understand what you said, performance issues are often not easy to fix.
About performance, I have another issue. I made some tests about memory occupation when I’m using Gridweb with large workbook. You will find the test project attached to this post. I created a new application on IIS which point on these project sources. This allows me to see the evolution of w3wp.exe memory occupation through the time. What I did is quite simple. I just repeated the following scenario many time: launch the application, press the “Load The Executed Workbook” button and then close the window. Here is the evolution of w3wp process memory occupation step by step :
- Execution of iisreset cmd to clean w3wp memory occupation
- Opening the application -> 500M
- Pressing the Load The Executed Workbook button -> 1G
- Closing the window and reopening the application -> 1.2G
- Pressing the Load The Executed Workbook button -> 1,5G
- Closing the window and reopening the application -> 1.7G
- Pressing the Load The Executed Workbook button -> 1,8G
- Closing the window and reopening the application -> 1.8G
- Pressing the Load The Executed Workbook button -> 1,9G
As you can see the memory occupation of w3wp process does not stop to increase. Obviously, this phenomenon causes some perfomance issues because the server become more and more slow computing the response… And even more if there are multiple users connected on the same application. For 2 users, you can multiply by 2 the values of the above scenario. This means that the server becomes fastly saturated…
I have tested your scenario using your sample project on Windows 8 using Google chrome. I have followed your steps but I could not find your mentioned issue (regarding memory increasing all the time) when clicking the second button “Load the executed workbook”, the memory does not go up that much, it takes just some MBs to load the process. However, I see memory goes up significantly when I click the first button to load a bigger file though. We need to conduct the test on IE11. Please spare us a little more time as we will test your case on IE11 as I think you are using this browser.
This is to update you that I have performed further tests on Windows 10 x64 by deploying your sample application on IIS Express as well as IIS 10.0.10586.0 and executing the mentioned steps in IE 11, however, I am not able to see the memory consumption as discussed in your post. I have noticed that the memory usage spikes up to 900MB but it eventually decreases opposed to consistent increase.
That said, we will keep this case open to perform more test and discuss it with the concerned member of the product team, if required. In the meanwhile, please provide more information of your testing environment. Please also state if you have evaluated this case on machines other than yours. If yes, please share your findings.
Actually, my tests were performed on Windows 7 x64 and I deployed the application on IIS 7.5. I’m using this computer as a server and a client. The steps I have sent to you in the previous post were executed on IE11 on the same computer.
Thank you for sharing the environment details. Please allow me some more time to perform further tests on Windows 7 with IIS 7.5 & IE 11. I will share my finding here for your reference.
This is to update you that I am able to observe the memory utilization by the IIS Worker Process as discussed in this post. Based on my findings, I have logged this incident as CELLSNET-44285 for further investigation by the product team. Please spare us more time to properly analyze the scenario in order to isolate the problem cause. In the meanwhile, we will keep you posted with updates in this regard.
This is to update you that we have looked into the scenario logged earlier as CELLSNET-44285 (Memory Utilization by IIS Worker Process) while using the .NET Memory Profiler application, and we strongly believe that the memory utilization keeps on increasing because garbage collection is not being triggered on machine where we were originally able to replicate the issue on our side. While using a profiling application such as one mentioned above, the garbage collection is being done forcefully at the time of taking snapshots of processes being executed, as a result we are not able to observe the same behaviour as mentioned in this post. During our tests (using Memory Profiler) we have noticed that the memory utilization keeps between 200+ MB to approximately 500 MB which seems fair. Attached to this post are a few snapshots for your reference. Moreover, we suggest you to use some memory profiling application to further troubleshoot the scenario on your side as well.
We have fixed your issue and incorporated the enhancements (as mentioned below) now. We will soon provide the fix after performing QA and incorporating other enhancements and fixes. Once the fix is available for public use, we will let you know here.
FYI, now if the request range is in cache, it will not post to server to request the data. If the request range is partially covered in cache, it will post to server to request the new data, e.g. if row 0 to 32 is in the range, when scrolling down, and then scrolling back, we get a request range of 0 to 32, it will use the cache data. If the request range is 20 to 52, it will use the range of 20 to 32 data in cache and request 33 to 52 only this time.
Test Steps: click the down arrow in right down corner of the vertical scroll bar, then the data will be loaded and sometime if it meets a new range, it will do web request. After a while, for example, we get row data of 200, then scroll up to any other location. it will display the data from cache (will not do web post request anymore).
Sorry for my late answer, I suspended my work on gridweb because of other urgent stuffs.
I just integrated on my project the 8.8.2.0 version of the GridWeb however I cannot notice any change about the lazy loading feature (EnableAsync=true). For me, it’s still unusable for the user. When I scroll down, this makes the next rows appear but they suddenly disappear and the scrollbar goes to the top and grid displays the first rows…
Could you please send me a video capture about how it works for you?
Could you try our latest version/fix: Aspose.Cells.GridWeb v8.8.3.2 (attached).
If you still find the issue regarding lazy loading, kindly do create a sample project (runnable) with v8.8.3.2 with some screenshots (or demo video) to show the issue, we will check it soon.
We have evaluated the recently shared concerns while using Aspose.Cells.GridWeb for .NET 8.8.3.2, and we are able to notice the said issues, that is; scrollbar moves down on IE11 and sometimes GridWeb looses grid formatting. We have logged these concerns in our database as CELLSNET-44580 for further investigation & correction. Please spare us little time to properly analyze the case and get back to you with updates in this regard.
I have noticed another issue. When I set the Height property of the GridWeb to 100%, the control takes the whole height of the browser window when I launch my application. However, each time I scroll down and so generate a postback, the control height grows and takes more than the available height.
Please tell me if you are able to notice the same issue.
I have tried to evaluate the recently shared scenario while using your previously provided sample application. I have noticed that the GridWeb’s height & Width is already set to 100% therefore I didn’t make any changes to the project (except for referencing Aspose.Cells.GridWeb 8.8.3.2 along with corresponding JavaScript files) however, I didn’t notice the problem in IE 11. Please be kind enough to share the updated sample project as well as snapshots/video showing the problematic behaviour.
I just executed the project I attached you on previous post. Indeed, the Width and Height properties are already set to 100%. So you have no update to do on the project. The only thing you have to do to reproduce the issue is to scroll down until a postback happens.
Please have a look on the video I attached to this post. You will see that after my scrolldown action, the scrollbar moves down and the gridweb height grows (e.g I cannot see the footer bar with save and worksheet buttons) …
I just executed the project I attached you on previous post. Indeed, the Width and Height properties are already set to 100%. So you have no update to do on the project. The only thing you have to do to reproduce the issue is to scroll down until a postback happens.
Please have a look on the video I attached to this post. You will see that after my scrolldown action, the scrollbar moves down and the gridweb height grows (e.g I cannot see the footer bar with save and worksheet buttons) ...
Thank you for sharing the video. You are correct that the bottom area of the GridWeb control disappears after scroll down postback, indicating that the height of the control has increased. I have logged this incident as CELLSNET-44583 in our bug tracking system for further investigation. As soon as we have completed the preliminary analysis, we will share the results here for your kind reference.
This is to inform you that we have fixed your issues (“CELLSNET-44580” and “CELLSNET-44583”). We will soon provide the fix after performing QA and incorporating other enhancements and fixes.
Because you have not released the fix yet I want to give you another issue. If I set the gridweb height to 100%, a vertical scrollbar appears on the container. However this scrollbar is fully useless. I am able to fix this issue by setting overflow:hidden on the container but it’s not a clean solution…
I have attached you a screenshot to show you the issue and a sample project to help you to reproduce it.
Sets consent for sending user data to Google for online advertising purposes.
Sets consent for personalized advertising.
Cookie Notice
To provide you with the best experience, we use cookies for personalization, analytics, and ads. By using our site, you agree to our cookie policy.
More info
Enables storage, such as cookies, related to analytics.
Enables storage, such as cookies, related to advertising.
Sets consent for sending user data to Google for online advertising purposes.
Sets consent for personalized advertising.
Cookie Notice
To provide you with the best experience, we use cookies for personalization, analytics, and ads. By using our site, you agree to our cookie policy.
More info
Enables storage, such as cookies, related to analytics.
Enables storage, such as cookies, related to advertising.
Sets consent for sending user data to Google for online advertising purposes.