Subject: Grouper Users - Open Discussion List
- From: "caleb racey" <>
- To: <>
- Subject: initial performance findings
- Date: Tue, 18 Sep 2007 16:58:15 +0100
Hi we are testing the grouper to see how it works and performs
As a test we have exported our existing mailing list infrastructure
groups from sympa and added them as groups under a stem
(ncl:webapps:lists:) and then populated those groups with the existing
memberships of mailing lists
This has resulted in 1600 groups created under the ncl:webapps:lists:
stem and 120,000 memberships associated with those groups. We have 28000
users in our user database.
We used the grouper shell to load these groups, in total it took 62
minutes to load up the 120,000 memberships. We consider this to be good
performance and are happy with the grouper shell as an admin tool.
We do have some issues with performance to do with ui interactions.
If I login as myself, a user with a membership of 39 groups (35 of them
email lists), and click the "Hide Stem hierarchy and show your groups"
button, then my 39 groups show relatively quickly. Analyses of the
query log shows 597 select statements where issued on the database, this
seems excessive but performs acceptably.
The performance issues come when I decide to navigate the stem hierarchy
to see my groups. If I navigate to ncl:webapps and click on the lists
I get shown my 35 email list memberships after a wait of 10 seconds. The
query log shows 21506 select statements where performed. This does not
look particularly scalable to me, it would not take many concurrent
users to saturate the database with queries.
Is this level of querying expected behaviour?
We have "hibernate.cache.use_query_cache = false" I'm not sure if
enabling the cache would help reduce the burden.
- initial performance findings, caleb racey, 09/18/2007
Archive powered by MHonArc 2.6.16.