From jira-events at lists.jboss.org Wed Oct  6 02:28:40 2010
Content-Type: multipart/mixed; boundary="===============1557305301961135696=="
MIME-Version: 1.0
From: Trustin Lee (JIRA) <jira-events at lists.jboss.org>
To: infinispan-issues at lists.jboss.org
Subject: [infinispan-issues] [JBoss JIRA] Issue Comment Edited: (ISPN-663)
 Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1 vs
 4.0
Date: Wed, 06 Oct 2010 02:28:39 -0400
Message-ID: <1906357960.17425.1286346519984.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
In-Reply-To: 658357275.15886.1285149688708.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com

--===============1557305301961135696==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


    [ https://jira.jboss.org/browse/ISPN-663?page=3Dcom.atlassian.jira.plug=
in.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D12555451#actio=
n_12555451 ] =


Trustin Lee edited comment on ISPN-663 at 10/6/10 2:26 AM:
-----------------------------------------------------------

I was able to achieve the similar behavior using AsyncStore:

          AsyncStoreConfig asyncConfig =3D new AsyncStoreConfig();
          asyncConfig.setEnabled(true);
          ...
          cacheStoreConfig.setAsyncStoreConfig(asyncConfig);

However, because AsyncStore does not delay the store() operations late enou=
gh (i.e. performs the enqueued operations ASAP), the test result remains th=
e same.  If I put an arbitrary delay in the AsyncStore's processor, I can g=
et the numbers similar to that of 'disabled store()' (<a href=3D"#action_12=
554367">here</a>).  To address this issue, we have to improve AsyncStore to=
 keep the enqueued store() operations and flush them periodically or for ev=
ery N modifications.  (See ISPN-328)

Let me continue to investigate on why it is still 5~10 times slower without=
 store().

      was (Author: trustin):
    I was able to achieve the similar behavior using AsyncStore:

          AsyncStoreConfig asyncConfig =3D new AsyncStoreConfig();
          asyncConfig.setEnabled(true);
          ...
          cacheStoreConfig.setAsyncStoreConfig(asyncConfig);

However, because AsyncStore does not delay the store() operations late enou=
gh (i.e. performs the enqueued operations ASAP), the test result remains th=
e same.  If I put an arbitrary delay in the AsyncStore's processor, I can g=
et the numbers similar to that of 'disabled store()' (#action_12554367).  T=
o address this issue, we have to improve AsyncStore to keep the enqueued st=
ore() operations and flush them periodically or for every N modifications. =
 (See ISPN-328)

Let me continue to investigate on why it is still 5~10 times slower without=
 store().
  =

> Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1=
 vs 4.0
> -------------------------------------------------------------------------=
-------
>
>                 Key: ISPN-663
>                 URL: https://jira.jboss.org/browse/ISPN-663
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Eviction, Loaders and Stores
>    Affects Versions: 4.1.0.Final
>         Environment: Win32 JRE 1.6.0_21
>            Reporter: Paul Nardone
>            Assignee: Trustin Lee
>             Fix For: 4.2.0.BETA1, 4.2.0.Final
>
>         Attachments: InfinispanPassivationTest.java
>
>
> Eviction with passivation enabled using the JdbmCacheStore appears to be =
significantly slower in 4.1.0.FINAL vs 4.0.0.FINAL.
> The degredation in performance is so signficant to make it impossible  to=
 use
> The  performance issue seems to due as the JdbmCacheStore synching the fi=
lesystem via FileDescriptor.sync() or similar which occurs during every obj=
ect passivation and each passivation occurs as a new object is added beyond=
 the EvictionMaxEntries capacity.
> The attached test inserts 1000 values into two caches
> Both caches use a JdbmCacheStore and  LRU
> PASSIVATIONLRU10 runs with cache with EvictionMaxEntries  10
> PASSIVATIONLRU1000 runs with cache with EvictionMaxEntries  1000
> 4.1.0.FINAL
> PASSIVATIONLRU10 Time Taken : 51704
> PASSIVATIONLRU1000 Time Taken : 4484
> 4.0.0.FINAL
> PASSIVATIONLRU10 Time Taken : 281
> PASSIVATIONLRU1000 Time Taken : 141
> 4.2.0.ALPHA2
> PASSIVATIONLRU10 Time Taken : 51047
> PASSIVATIONLRU1000 Time Taken : 5156

-- =

This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
ps://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       =20

--===============1557305301961135696==--