On Wed, Jul 18, 2012 at 12:28 PM, John Dennis <jden...@redhat.com> wrote: > On 07/18/2012 02:59 PM, Stephen Ingram wrote: >> >> On Wed, Jul 18, 2012 at 6:45 AM, Petr Vobornik <pvobo...@redhat.com> >> wrote: >>> >>> On 07/17/2012 11:43 PM, Stephen Ingram wrote: >>> >>> 8><------ >>> >>> >>>>>> >>>>>> I'm beginning to think this is just the Web UI itself instead of 389 >>>>>> although it is really difficult to tell. I've poured over the debug >>>>>> logs and didn't see anything that caused me concern. >>>>>> >>>>>> It's certainly usable, but I just got really spoiled by the >>>>>> unbelievable quickness of 2.1.3. When your release notes indicate it >>>>>> should be faster, what are you comparing it to? Maybe this only >>>>>> happens with upgraded instances and not fresh installs. >>>>> >>>>> >>>>> >>>>> >>>>> It is always possible something didn't get upgraded properly but I've >>>>> done >>>>> 2.1.3 -> 2.2.0 upgrades and haven't seen this. When we say something is >>>>> faster we're always referring to the previous version (or versions). >>>> >>>> >>>> >>>> Maybe I was just lucky with 2.1.3. On a first load it might take some >>>> time to load the "frame" as I call it. But the data would load almost >>>> instantaneously from there (certainly no more than 1 s) as you moved >>>> from page to page. Here, even if I return to the same page, the system >>>> acts as if the data is begin fetched for the very first time as it is >>>> no faster than the first load. Maybe that is significant to the >>>> problem? >>> >>> >>> >>> I think the culprit is Web UI paging capabilities introduced in 2.2. With >>> lot of users, responses might grow in size. You can check their size and >>> duration in browser developers tools. I suggest chrome/chromium - press >>> F12 >>> and choose 'network' tab. >>> >>> This new feature can't be disabled in configuration. To test if the >>> slowdown >>> is done by paging you can (at own risk) replace line >>> /usr/share/ipa/ui/facet.js:538 >>> >>> that.pagination = spec.pagination === undefined ? true : spec.pagination; >>> >>> with: >>> >>> that.pagination = false; >>> >>> Note: It will break some other parts of the UI - so for testing only. >> >> >> I've made the substitution in the code (was line 507 for me-do I have >> a different version?). Looking at the time chart in Chrome I see that >> the bulk of the time is for /ipa/session waiting. Would "waiting" mean >> waiting for the directory server or memcached? > > > Actually neither, it means waiting for a response from the web server > (technically it's making an RPC call via HTTP Ajax). The RPC call needs to > go through the web server, memcached, and typically will invoke one or more > directory server queries, and run a bunch of Python to massage everything > before the RPC returns with the result. > > It doesn't look like you've got much difference in times between with > pagination on and pagination off. I don't know the pagination code but I > suspect it's run after the RPC call returns so the RPC timing is not telling > us much with respect to that. > > Waiting for up to 3 seconds for an RPC call does seem on the high side. Do > you have a lot of LDAP data?
No. 49 users, 17 hosts, 25 services, 6 DNS zones, only 1 of which has any significant amount of hosts in it. > But really, unless we get timing results for each component we're grasping > at straws :-( Understood. Steve _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users