We figured out our slowness problem. It was, of course, some custom code we had
added.
tl;dr
We have a button in the main navigation to "Submit a New Item" if the
logged-in user has permissions to submit to *any* collection. This is relying
on brute-force authentication checking.
<code>
boolean userCanSubmit = false;
Collection[] submitCollections = Collection.findAuthorized(context,
null, Constants.ADD);
if((submitCollections!=null) && (submitCollections.length > 0))
{
userCanSubmit=true;
}
</code>
The solution is to remove that code until I can come up with a better way of
checking authentication.
Thanks for your help!
-----Original Message-----
From: Tim Donohue [mailto:tdono...@duraspace.org]
Sent: Friday, February 28, 2014 12:04 PM
To: Ingram, William A; dspace-devel@lists.sourceforge.net
Subject: Re: [Dspace-devel] slowness when logged in
Hi Bill,
On 2/28/2014 11:28 AM, Ingram, William A wrote:
> Hi Tim,
>
> This is DSpace 3.2, XMLUI. The slowness seems to occur on every page, but
> ONLY when the user is logged in. That makes sense given the eperson and
> epersongroup queries, which couldn't run otherwise.
> We will give http://www.yourkit.com/ a try and report back if we get
> anywhere. I haven't done enough detailed analysis of the queries. But at
> first blush, it looks like DSpace is gathering all the groups the eperson is
> a member of (ditto all the parent groups) and then running another query for
> every other eperson in each of those groups. Since we have eperson groups
> based on AD groups, some of these can be very large (e.g., "Students"). You
> can see how this could be a problem if the system was running a database
> query for every eperson from every group the logged-in user is a member of.
> But like I said, I'm not a hundred percent sure that is even what's happening.
> To be continued....
Actually, AD groups shouldn't be a problem. These types of external groups are
"Special Groups" within DSpace. Essentially in DSpace, they have no members.
But, when you login, a query is performed against AD or LDAP which then
determines which of these Special Groups you are a member of. Then you are
added to those DSpace groups *only for the remainder of your session*.
IIRC, what is essentially supposed to happen is this...
(1) You login, your EPerson info is queried in the database and is cached in
the Session's Context object, as the "currentUser"
https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/core/Context.java
(2) Any Special Groups you are found to be a member of (by querying external AD
or LDAP or similar) are also cached in the Context object (as the
"specialGroups" list)
(3) When any Group objects are loaded (by a database query), those Group
objects are also cached in the Context Object (using cache() and fromCache()).
The odd thing here is that, based on what you've said/provided, it sounds like
#3 is not happening properly (since every page seems to rebuild those Group
objects by re-querying the database). It's possible there's an odd bug here
that is not readily apparent. I'm hoping maybe YourKit can give us some more
clues as to what could be going on.
- Tim
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
