[jira] [Resolved] (OAK-2543) Service user session creation isn't fast enough

["Michael Dürig (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Dürig resolved OAK-2543.
--------------------------------
    Resolution: Incomplete

Resolving as incomplete for now. Please reopen if this keeps being a problem providing benchmarking results so we can decide on an action.

> Service user session creation isn't fast enough
> -----------------------------------------------
>
>                 Key: OAK-2543
>                 URL: https://issues.apache.org/jira/browse/OAK-2543
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: Laurie byrum
>              Labels: performance
>             Fix For: 1.3.1
>
>
> We have some (very commonly hit) bits of code that need to read configs (for example), and thus need higher privileges. At one point, we were advised to make short-lived service sessions to handle this. We did this and found our
> performance was absolutely abysmal. We're on our 3rd bottleneck that we
> are working through. They have all pointed to session creation. Maybe each
> creation isn't too bad, but in aggregate, it's much slower than, for
> example, the actual reads or anything else.
> I was able to make the code usually avoid session creation in the first 2
> cases, but earlier this week we hit the third example where the answer seems to
> be one of 1) make creating sessions ignorably fast even when they are
> created a lot 2) cache whatever read is requiring the escalation and clean
> up in event listeners (those listeners will invariably have to listen to
> non-local events, but the events should be uncommon so far) 3) long-lived
> sessions used for reads across threads.
> Per Michael Duerig, #1 is the goal. Can we see if the current situation can be improved? Because it isn't ignorably fast today. Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)