I noticed when I was testing Jan's latest instance listing patch that there was a performance issue. I have not completely tracked it down yet, but I don't think it is directly related to that patchset, as I noticed the same behavior when on another branch without those patches. To see where I am talking about, go to a pool with some instances (the path to this may have changed, depending on if you have Tomas' patch that removes the left nav). The initial page load is fairly normal (though, even that I think is a little slower than it should be). However, once the ajax call goes out to get the table, there is a very long wait. I think this is something specific to this path, as if you go to /instance directly, it seems much faster. Here is an example snippet from my log showing just the slow bit:
Rendered instance/_instances (940.2ms) Completed in 1492ms (View: 954, DB: 19) | 200 OK [http://localhost/pool/list/1?ajax=true]
As a reference, the initial page load is:
Rendered layouts/_main_nav (14.5ms) Rendered layouts/_notification (2.4ms) Completed in 346ms (View: 147, DB: 17) | 200 OK [http://localhost/pool/1]
So the 2nd call takes over 4 times as long! I tried to write a profile test for this, but realized that since the issue is isolated in the ajax call, I cannot replicate it in that kind of test, as perf tests don't run ajax. Hopefully this is enough information to go on. Jan or Tomas, if either of you guys have time to track this down, that would be really good, as this _has_ to be fixed (anyone else with time, feel free to jump in instead). I'll check in if anyone has any insight on this when I get back Thursday. Thanks,
-j
On 07/20/2010 11:06 PM, Jason Guiditta wrote:
I noticed when I was testing Jan's latest instance listing patch that there was a performance issue. I have not completely tracked it down yet, but I don't think it is directly related to that patchset, as I noticed the same behavior when on another branch without those patches. To see where I am talking about, go to a pool with some instances (the path to this may have changed, depending on if you have Tomas' patch that removes the left nav). The initial page load is fairly normal (though, even that I think is a little slower than it should be). However, once the ajax call goes out to get the table, there is a very long wait. I think this is something specific to this path, as if you go to /instance directly, it seems much faster. Here is an example snippet from my log showing just the slow bit:
Rendered instance/_instances (940.2ms) Completed in 1492ms (View: 954, DB: 19) | 200 OK [http://localhost/pool/list/1?ajax=true]
As a reference, the initial page load is:
Rendered layouts/_main_nav (14.5ms) Rendered layouts/_notification (2.4ms) Completed in 346ms (View: 147, DB: 17) | 200 OK [http://localhost/pool/1]
So the 2nd call takes over 4 times as long! I tried to write a profile test for this, but realized that since the issue is isolated in the ajax call, I cannot replicate it in that kind of test, as perf tests don't run ajax. Hopefully this is enough information to go on. Jan or Tomas, if either of you guys have time to track this down, that would be really good, as this _has_ to be fixed (anyone else with time, feel free to jump in instead). I'll check in if anyone has any insight on this when I get back Thursday. Thanks,
-j
Hi, this problem is related to condormatic util. Pool calls method "condormatic_instances_sync_states" when listing instances. And in condormatic_instances_sync_states method is slow parsing of condor XML output with REXML.
Patch "Replaced REXML by Nokogiri in condormatic" replaces REXML with Nokogiri for parsing, here are some results:
Pool list before patch (REXML): time in condormatic_instances_sync_states 3.1s rendered 4657ms overall request time (firebug) 5.2s
Pool list with Nokogiri: time in condormatic_instances_sync_states 0.7s rendered 2265ms overall request (firebug) 2.8s
I think it's possible to improve performance also by setting state of instances only once, but this perf. improve will be much smaller.
Jan
deltacloud-devel@lists.fedorahosted.org
-
Jan Provazník -
Jason Guiditta