1. #1
    Sencha Premium Member Troy Wolf's Avatar
    Join Date
    May 2007
    Location
    Kansas City
    Posts
    250
    Vote Rating
    2
    Troy Wolf is on a distinguished road

      0  

    Default A script on this page is causing IE to run slowly...

    A script on this page is causing IE to run slowly...


    I am developing my first Ext app of any consequence and have encountered the dreaded:
    Quote Originally Posted by Internet Explorer
    A script on this page is causing Internet Explorer to run slowly. If it continues to run, your computer may become unresponsive. Do you want to abort the script?
    • Windows XP Professional SP2
    • 1 GB RAM
    • Internet Explorer 6.0
    • Ext 2.0 Beta

    Security restrictions won't allow me to post my code, so I'd have to create a completely separate, generic app to demonstrate the problem--which may be what I end up doing anyway. For now, I post what I know at this point in case this is a known issue, has a known solution, or is something one of you wants to dive into. One thing is for sure, if not resolved, it will be a show-stopper for using Ext with this app. I do NOT want that! Don't take my Ext away!

    Before you all post to tell me "I'm not having any problems" , understand my app is one that if a memory leak exists, it's probably going to find it.

    My app's architecture
    The only javascript loaded is Ext javascript, the popular GridFilter plugin, and of course my javascript to create and interact with my Ext objects. The HTML body of my document is completely empty--everything is written by Ext after page load.

    The app is a grid, but specifically, it is a GridPanel using the GridFilter 'filters' plugin. The grid also uses a GroupingView to provide row text color styling. The grid's store is a GroupingStore using a JsonReader. My ColumnModel has 5 simple columns with one simple custom renderer.

    I am using a Viewport to contain my grid to provide auto-resizing to fill the browser window.

    I am using a TaskMgr to load the store every 5 seconds. Obviously it is this recurring processing that is somehow leaking memory or causing some kind of script slowness.

    -----------------------------------------------------------------------------

    I have one theory that I am investigating, but I'm sure one of you gurus can just tell me. When I use the TaskMgr to load a store every 5 seconds, does that literally occur every 5 seconds regardless of whether the previous request has finished?

    In my current, non-Ext AJAX app, I load my table "every 5 seconds", but really, I call the asynchronous load, then on return of that load, I set the table to reload in 5 seconds. So, if for some reason, the server or database is slow and the request takes 15 seconds to return, my client's app simply waits, gets the data, then sets to reload in another 5 seconds.

    This issue takes many hours to appear. If I just sit and watch memory and CPU, I don't notice a problem. My theory is that perhaps over enough time, I end up with several of these asynchronous requests loading and thus updating the grid simultaneously? It's something for me to start looking at anyway.

  2. #2
    jay@moduscreate.com's Avatar
    Join Date
    Mar 2007
    Location
    Frederick MD, NYC, DC
    Posts
    16,361
    Vote Rating
    81
    jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all

      0  

    Default


    5 seconds?! wow.

    how many rows and columns?

  3. #3
    Sencha Premium Member Troy Wolf's Avatar
    Join Date
    May 2007
    Location
    Kansas City
    Posts
    250
    Vote Rating
    2
    Troy Wolf is on a distinguished road

      0  

    Default


    Quote Originally Posted by djliquidice View Post
    5 seconds?! wow.

    how many rows and columns?
    5 columns x 100 rows

    A server-side script can take a lot more time than just the code processing. For example, query large database tables with complicated queries, wait for a signal on a socket, request content from remote web services, etc. So a server-side script that takes 5 or 6 seconds to return is not all that crazy--it just depends on what you are asking it to do.

    Of course, if you know your script regularly needs at least 5 seconds just to return, you should not create a client-side script that requests the data every 5 seconds.

    You may be making the assumption that my server-side script regularly takes longer than 5 seconds to process. It does not. In fact, it usually responds within 180 or so milliseconds. It is making a simple, fast postgres table query, counting the resultset, JSON-encoding the data, and serving it back.

    However, there is always the possibility of momentary conditions that cause the overall process to take longer than expected or even to fail.

    Here is what I've learned so far.

    First, the TaskMgr does fire my grid's load method every 5 seconds--just like I told it to do. However, it first checks the previous request, and if it's still running, it cancels it.

    My Ext store is loading my grid from JSON-encoded data returned from a PHP script. If, at the top of that PHP script, I add:
    PHP Code:
    sleep(10); // Sleep for 10 seconds, then continue processing. 
    No data is ever loaded in my grid. This is easily explained--since the TaskMgr was told to load the data every 5 seconds, and after waiting 5 seconds, it cancels the previous request and starts a new one, the PHP script is never allowed to return it's data to Ext.

    The worst part of this, though, is that every 5.00 seconds, a new request is sent to my Apache webserver to process a PHP script that takes approximately 10.03 seconds. Do the math, and you quickly see how you'll run out of Apache processes. This is, of course, not Ext's fault, and something I can and should code around.

    It seems the obvious alternative is instead of using the TaskMgr, to use the store's onload event to set another load in 5 seconds. This way, you never have more than one load requested and you always wait for that load to return before setting up another one. I may want data loaded every 5 seconds, but if the server needs 8 seconds to return the data every now and then, my browser needs to wait and be patient. The browser cancelling a request does not stop the process on Apache, so relying on Ext to just cancel and move on with more requests is not a workable solution.

    Now here is the part where I may have exposed a bug--I am not yet able to consistently reproduce the issue, but I've now seen in both IE and Firefox that after Ext had to cancel enough of these XMLHTTP requests, the browsers complained about the script using too many resources. I continue to debug and test. (Notice I say may have exposed a bug. Believe me, I suspect my code at this point--not Ext.)

  4. #4
    Ext User DigitalSkyline's Avatar
    Join Date
    Apr 2007
    Location
    Rochester, MI
    Posts
    461
    Vote Rating
    1
    DigitalSkyline is on a distinguished road

      0  

    Default


    I cant imagine under what circumstances you would want to tax the server/client/network with a request every 5 seconds. Seems a little ridiculous. Have you at least tried extending this to say 10/15/20 seconds? It might also help if instead of returning the full results you just append the changes... or in other words if you just polled to check if a change occurred in the data, if so return the changed records, if not, return false... something along those lines.

    Otherwise it seems like your expecting a little bit much from a web based app...

  5. #5
    jay@moduscreate.com's Avatar
    Join Date
    Mar 2007
    Location
    Frederick MD, NYC, DC
    Posts
    16,361
    Vote Rating
    81
    jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all

      0  

    Default


    asking any framework to refresh 500 cells every 5 seconds is not good. Remember that it has to clear (destroy) the cache and rebuild every refresh.

    at this point i would not say that it's ext's fault.

    you're stepping on yourself when you want the grid to refresh ever 5 seconds, but the SSS takes longer to return data. that makes the refresh of 5 seconds impossible.

  6. #6
    Sencha Premium Member Troy Wolf's Avatar
    Join Date
    May 2007
    Location
    Kansas City
    Posts
    250
    Vote Rating
    2
    Troy Wolf is on a distinguished road

      0  

    Default


    Quote Originally Posted by DigitalSkyline View Post
    I cant imagine under what circumstances you would want to tax the server/client/network with a request every 5 seconds.
    Quote Originally Posted by djliquidice View Post
    asking any framework to refresh 500 cells every 5 seconds is not good. Remember that it has to clear (destroy) the cache and rebuild every refresh.

    at this point i would not say that it's ext's fault.

    you're stepping on yourself when you want the grid to refresh ever 5 seconds, but the SSS takes longer to return data. that makes the refresh of 5 seconds impossible.
    Guys, you are focused on the wrong points here. I have to say, both from my own posts and questions posed by others both in this community and elsewhere, I am continually surprised by the narrow scope that many people seem to think in when it comes to browser-based applications. Think beyond websites used as blogs, photo galleries, checking your bank balance, etc. Think beyond public websites--private, corporate intranets can host web applications that have ultra high-speed fiber connections to local databases and local web servers. In these conditions, you can build "web apps" or browser-based applications that are way outside the "box" of normal websites.

    The particular app I'm working on right now is a "Log Viewer" for a high-speed, controlled, corporate intranet. Developers and support staff use this browser-based app to keep an eye on system events (Info, Warnings, Errors) as close to real-time as possible. In production, under normal conditions, every 5 seconds is nothing--hardly any noticeable load on the web server or database even with 50 of these log viewers running.

    I've already designed the app to only query for records newer than what is already in the Ext store. If no records are found, the server-script returns a 304 NOT MODIFIED HTTP header. This is all working splendidly.

    I should add that I already have pre-Ext Log Viewer app that uses YUI AJAX to update every 5 seconds. It has been in production for over a year, and works well. So the concept is one that works and has been proven over a long period of time. I'm now trying to create v2 of this app using Ext to improve the richness of the interface and features.

    Now, my old version of this app actually returns the entire HTML table every 5 seconds and just replaces an innerHTML. It works great--no issues, no page blinking. However, its rather ugly overall because my design skills, to use the technical term, suck.

    So yes, as you point out, djliquidice, a big difference of my Ext grid solution is that the browser has to individually manipulate 500 cells. I'm using the store's load add:true modifier (append rather than replace the store data), and I'm only querying for new records. So on most 5 second loads, I have zero to 3 records to add to the grid. However, due to the logic I'm using to remove the oldest records (maintaining 100 records in the store) and the sorting requirement, Ext is probably having to process all 500 cells every time.

    HOWEVER, I can tell you that at least on my computer, most of the time Ext does not seem to have any problem at all updating those 500 cells every 5 seconds -- tested on IE and FF on Windows and FF on SUSE 10 Linux. When things are normal, it works fine. There is some condition that happens occasionally that over time (hours) eventually causes a resource issue. And so far, my data seems to point to it being related to when Ext has to cancel XMLHTTP requests.

    TO BE CLEAR -- I'm not saying, "hey why can't Ext process 500 cells every 5 seconds?" I'm not saying Ext has a performance problem. In fact, I'm very impressed with the speed that it performs considering how rich it is.

    My point is, regardless of whether what I'm doing is a good idea, if Ext is leaking memory, it's an Ext problem that I (and I'd hope others) would be very interested in improving.

    I'll continue to research and get to the bottom of this. I posted hoping others may have already encountered this issue and have helpful information. Instead, so far, I'm finding that people are overlooking the specific issue and instead blasting my architecture--which would be fine if it was my architecture that is causing the issue.

  7. #7
    jay@moduscreate.com's Avatar
    Join Date
    Mar 2007
    Location
    Frederick MD, NYC, DC
    Posts
    16,361
    Vote Rating
    81
    jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all

      0  

    Default


    Troy,

    I setup an 'open events' view for our Tivoli Enterprise Console, which spans events for my company which has global reach with thousands of properties. I think that 60 second refresh is more than adequate for a display.

    i realize i'm sidetracking, but why 5 seconds. What if you scaled down to 60 seconds - does it still have the problem?

  8. #8
    jay@moduscreate.com's Avatar
    Join Date
    Mar 2007
    Location
    Frederick MD, NYC, DC
    Posts
    16,361
    Vote Rating
    81
    jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all

      0  

    Default


    Another note, can you setup a perfmon log (if on windows) and track IE/FF real memory usage over time?


    What method are you using to refresh your grid?

  9. #9
    Sencha Premium Member Troy Wolf's Avatar
    Join Date
    May 2007
    Location
    Kansas City
    Posts
    250
    Vote Rating
    2
    Troy Wolf is on a distinguished road

      0  

    Default


    Quote Originally Posted by djliquidice View Post
    Troy,

    I setup an 'open events' view for our Tivoli Enterprise Console, which spans events for my company which has global reach with thousands of properties. I think that 60 second refresh is more than adequate for a display.

    i realize i'm sidetracking, but why 5 seconds. What if you scaled down to 60 seconds - does it still have the problem?
    I honestly appreciate that you realize this is a sidetrack from the real issue, and I definitely do not mind explaining this a bit. I don't assume to understand your business requirements. You can't possibly know mine. The type of service my company provides requires us to count processing time and network latency in microseconds (one millionth of a second). In our business, if our data feeds slow down to 10 milliseconds (1,000th of a second) instead of 5 milliseconds, we have customers calling our support desk to find out what is wrong. If it takes our support desk even 30 seconds to know about a problem, customers will be calling to report the problem before we know about it. Seriously.

    And for a real-world example of the viability of having web pages or components that update every 5 seconds, here is some of my handy-work. It is a public website page that includes not one but three components that update every 5 seconds. Hundreds of people hit these tools all day long. You'll want to view the page during normal market hours to see the updating nature of the components. 9AM - 4PM Eastern.
    http://www.batstrading.com/data/

    So yes, there are definitely real-world, web-app scenarios where 5 second updating is logical--and it's being done by a lot of people. Thanks for asking.

  10. #10
    Sencha - Community Support Team hendricd's Avatar
    Join Date
    Aug 2007
    Location
    Long Island, NY USA
    Posts
    5,962
    Vote Rating
    10
    hendricd will become famous soon enough hendricd will become famous soon enough

      0  

    Default


    Troy: you likely owe to yourself to see if the problem is a:

    - server-response-time issue alone, or
    - a grid-load{add:true}-filterBy-sort-render issue

    You might try something like this at different intervals to see if the problem disappears:

    Code:
    var runner = new Ext.util.TaskRunner()
    var task = {run: ds.reload, interval: 5000};
    
    ds.on({'beforeload': function(){  runner.stop(task); },
           'load': function(){  runner.start(task); }
          });
    runner.start(task);
    This gives server AND those heavy datastore operations you've got going -- room to breath
    "be dom-ready..."
    Doug Hendricks

    Maintaining ux: ManagedIFrame, MIF2 (FAQ, Wiki), ux.Media/Flash, AudioEvents, ux.Chart[Fusion,OFC,amChart], ext-basex.js/$JIT, Documentation Site.


    Got Sencha licensing questions? Find out more here.