Re: Clustering with Oracle, experiencing bottleneck problems, v. 2.14.0

[Woonsan Ko]

It's moved to:
- http://jackrabbit.apache.org/archive/wiki/JCR/Clustering_115513377.html

Regards,

Woonsan


On Tue, Feb 11, 2020 at 3:35 AM Raffaele Gambelli 
wrote:

> Hi Woonsan and thanks for your reply, I come again one year later 
>
> We can't reach your link https://wiki.apache.org/jackrabbit/Clustering,
> if I register an account then I'm not able to find that page, could you
> point me to a different documentation about Jackrabbit clustering?
>
> Really thanks, bye
>
> -Messaggio originale-
> Da: Woonsan Ko 
> Inviato: martedì 8 gennaio 2019 06:34
> A: users@jackrabbit.apache.org
> Oggetto: Re: Clustering with Oracle, experiencing bottleneck problems, v.
> 2.14.0
>
> On Mon, Jan 7, 2019 at 7:56 PM Raffaele Gambelli 
> wrote:
> >
> > Hi all,
> >
> > we are doing many stress tests over our web application above jackrabbit
> 2.14.0.
> >
> > Starting from a given load, we are experiencing big differences between
> 4 nodes versus 2 nodes, I mean that 2 nodes result much more performant
> than 4 ones.
> >
> > We use Oracle 12, only one db node, our PersistenceManager is configured
> in this way:
> >
> >  class="org.apache.jackrabbit.core.persistence.pool.OraclePersistenceManager">
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > Have you some hints or best practices to suggest when configure a
> Jackrabbit cluster?
> >
> > We have noticed that the most active statement is this:
> > update JOURNAL_GLOBAL_REVISION set REVISION_ID = REVISION_ID + 1
> >
> > For which reason it was choosen to have a simple NUMBER column to manage
> such an important information? It is really massively accessed and it may
> generate a big bottle-neck in high concurrency, am I wrong?
>
> That's used by the Cluster journal component. "Every change made by one
> cluster node is reported in a journal, ..." [1] Each cluster node needs to
> synchronize the changes by reading the journal periodically, and for that
> reason, it needs to increment the global revision number on journal
> addition, and compare with its own local revision number on the other
> cluster nodes. If you've observed that global revision number update
> statement, then I think it means your application makes changes (CUD) very
> often. If each of your cluster nodes makes the same amount of changes and
> so the total changes are increasing in your stress testing, I guess it
> should increase the overhead proportionally.
>
> Regards,
>
> Woonsan
>
> [1] https://wiki.apache.org/jackrabbit/Clustering
>
> >
> >
> > Thanks in advance, best regards
> >
> >
> >
> >
> >
> >
> >
> > [westpole]
> >
> > Raffaele Gambelli
> >
> > WebRainbow(r) Software Developer
> >
> >
> > P:  +39 051 8550 576
> > M:  #
> > E:  r.gambe...@westpole.it<mailto:r.gambe...@westpole.it>
> > W:  https://westpole.webex.com/meet/R.Gambelli
> > A:  Via Ettore Cristoni, 84 - 40030 Casalecchio di Reno
> >
> >
> > [www]<https://westpole.it/> [facebook] <
> https://www.facebook.com/WESTPOLESPA>   [twitter] <
> https://twitter.com/WESTPOLE_SPA>[linkedin] <
> https://www.linkedin.com/company/westpole>
> >
> > This email for the D.lgs.196/2003 (Privacy Code) and European Regulation
> 679/2016/UE (GDPR) may contain confidential and/or privileged information
> for the exclusive use of the intended recipient. Any review or distribution
> by others is strictly prohibited. If you are not the intended recipient,
> you must not use, copy, disclose or take any action based on this message
> or any information here. If you have received this email in error, please
> contact us (email:priv...@westpole.it) by reply email and delete all
> copies. Legal privilege is not waived because you have read this email.
> Thank you for your cooperation.
> > [green]
>

Re: Clustering with Oracle, experiencing bottleneck problems, v. 2.14.0

[Woonsan Ko]

On Mon, Jan 7, 2019 at 7:56 PM Raffaele Gambelli  wrote:
>
> Hi all,
>
> we are doing many stress tests over our web application above jackrabbit 
> 2.14.0.
>
> Starting from a given load, we are experiencing big differences between 4 
> nodes versus 2 nodes, I mean that 2 nodes result much more performant than 4 
> ones.
>
> We use Oracle 12, only one db node, our PersistenceManager is configured in 
> this way:
>
>  class="org.apache.jackrabbit.core.persistence.pool.OraclePersistenceManager">
> 
> 
> 
> 
> 
> 
> 
> 
>
> Have you some hints or best practices to suggest when configure a Jackrabbit 
> cluster?
>
> We have noticed that the most active statement is this:
> update JOURNAL_GLOBAL_REVISION set REVISION_ID = REVISION_ID + 1
>
> For which reason it was choosen to have a simple NUMBER column to manage such 
> an important information? It is really massively accessed and it may generate 
> a big bottle-neck in high concurrency, am I wrong?

That's used by the Cluster journal component. "Every change made by
one cluster node is reported in a journal, ..." [1] Each cluster node
needs to synchronize the changes by reading the journal periodically,
and for that reason, it needs to increment the global revision number
on journal addition, and compare with its own local revision number on
the other cluster nodes. If you've observed that global revision
number update statement, then I think it means your application makes
changes (CUD) very often. If each of your cluster nodes makes the same
amount of changes and so the total changes are increasing in your
stress testing, I guess it should increase the overhead
proportionally.

Regards,

Woonsan

[1] https://wiki.apache.org/jackrabbit/Clustering

>
>
> Thanks in advance, best regards
>
>
>
>
>
>
>
> [westpole]
>
> Raffaele Gambelli
>
> WebRainbow(r) Software Developer
>
>
> P:  +39 051 8550 576
> M:  #
> E:  r.gambe...@westpole.it
> W:  https://westpole.webex.com/meet/R.Gambelli
> A:  Via Ettore Cristoni, 84 - 40030 Casalecchio di Reno
>
>
> [www] [facebook] 
>    [twitter] 
> [linkedin] 
> 
>
> This email for the D.lgs.196/2003 (Privacy Code) and European Regulation 
> 679/2016/UE (GDPR) may contain confidential and/or privileged information for 
> the exclusive use of the intended recipient. Any review or distribution by 
> others is strictly prohibited. If you are not the intended recipient, you 
> must not use, copy, disclose or take any action based on this message or any 
> information here. If you have received this email in error, please contact us 
> (email:priv...@westpole.it) by reply email and delete all copies. Legal 
> privilege is not waived because you have read this email. Thank you for your 
> cooperation.
> [green]