jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Trivial Update of "Performance" by MichaelDürig
Date Mon, 08 Mar 2010 14:50:15 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "Performance" page has been changed by MichaelDürig.
http://wiki.apache.org/jackrabbit/Performance?action=diff&rev1=10&rev2=11

--------------------------------------------------

  
  == Q. How can I improve performance with DavEx remoting (jcr2spi / spi2davex) ==
  On the current trunk there are 3 parameters which can be used to tweak performance for jcr2spi/spi2davex.
These are the size of the item info cache, the size of the item cache and the depth of batch
read operations.
+ 
  Some Background:
- The item cache contains JCR items (i.e. nodes and properties). The item info cache contains
item infos. An item info is an entity representing nodes or properties on the SPI layer. The
jcr2spi module receives item infos from an SPI implementation (i.e. spi2davex) and uses them
to build up a hierarchy of JCR items.
+ 
- When an item is requested from the JCR API, jcr2spi first checks whether the item is in
the item cache. If so, that item is returned. If not, the request is passed down to the SPI.
But before actually calling the SPI the item info cache is check first. If this cache contains
the requested item info the relevant part of the JCR hierarchy is build and the corresponding
JCR item is placed into the item cache. Only when the item info cache does not contain the
requested item info a call will be made to the SPI. Here the batch read depth comes into play.
Since calls to the SPI cause some latency (i.e. network round trips), the SPI may - in addition
to the actually requested item info - return additional item infos. The batch read depth parameter
specifies the depth down to which item infos of the children of the requested item info are
returned.
+ The item cache contains JCR items (i.e. nodes and properties). The item info cache contains
item infos. An item info is an entity representing nodes or properties on the SPI layer. The
jcr2spi module receives item infos from an SPI implementation (i.e. spi2davex) and uses them
to build up a hierarchy of JCR items. When an item is requested from the JCR API, jcr2spi
first checks whether the item is in the item cache. If so, that item is returned. If not,
the request is passed down to the SPI. But before actually calling the SPI the item info cache
is check first. If this cache contains the requested item info the relevant part of the JCR
hierarchy is build and the corresponding JCR item is placed into the item cache. Only when
the item info cache does not contain the requested item info a call will be made to the SPI.
Here the batch read depth comes into play. Since calls to the SPI cause some latency (i.e.
network round trips), the SPI may - in addition to the actually requested item info - return
additional item infos. The batch read depth parameter specifies the depth down to which item
infos of the children of the requested item info are returned.
+ 
+ Overall the size of the item info cache and the batch read depth should be used to optimize
for the requirements of the back-end (i.e. network and server). In general, the item info
cache should be large enough to '''easily''' hold all items from multiple batches. The batch
read depth should be a trade off between network latency and item info cache overhead. Finally
the item cache should be used to optimize for the requirements of the front-end (i.e. the
JCR API client). It should be able to hold the items in the current working set of the API
consumer.
+ 
- Overall the size of the item info cache and the batch read depth should be used to optimize
for the requirements of the back-end (i.e. network and
- server). In general, the item info cache should be large enough to '''easily''' hold all
items from multiple batches. The batch read depth should be a trade
- off between network latency and item info cache overhead. Finally the item cache should
be used to optimize for the requirements of the front-end (i.e.
- the JCR API client). It should be able to hold the items in the current working set of the
API consumer.
  Some pointers:
- Batch reading: org.apache.jackrabbit.spi.RepositoryService#getItemInfos()
+ 
+ Batch reading:
+ 
+  * org.apache.jackrabbit.spi.[[RepositoryService#getItemInfos.28.29|RepositoryService#getItemInfos()]]
+ 
- org.apache.jackrabbit.spi2davex.Spi2davexRepositoryServiceFactory#PARAM_BATCHREAD_CONFIG
+  * org.apache.jackrabbit.spi2davex.Spi2davexRepositoryServiceFactory#PARAM_BATCHREAD_CONFIG
+ 
  Item info cache size:
+ 
- org.apache.jackrabbit.spi2davex.Spi2davexRepositoryServiceFactory#PARAM_ITEMINFO_CACHE_SIZE
+  * org.apache.jackrabbit.spi2davex.Spi2davexRepositoryServiceFactory#PARAM_ITEMINFO_CACHE_SIZE
+ 
  Item cache size:
+ 
- org.apache.jackrabbit.jcr2spi.Jcr2spiRepositoryFactory#PARAM_ITEM_CACHE_SIZE
+  * org.apache.jackrabbit.jcr2spi.Jcr2spiRepositoryFactory#PARAM_ITEM_CACHE_SIZE
+ 
  Related JIRA issues:
- JCR-2497: Improve jcr2spi read performance
- JCR-2498: Implement caching mechanism for ItemInfo batches
- JCR-2461: Item retrieval inefficient after refresh
- JCR-2499: Add simple benchmarking tools for jcr2spi read perform
  
+  * JCR-2497: Improve jcr2spi read performance
+ 
+  * JCR-2498: Implement caching mechanism for ItemInfo batches
+ 
+  * JCR-2461: Item retrieval inefficient after refresh
+ 
+  * JCR-2499: Add simple benchmarking tools for jcr2spi read perform
+ 

Mime
View raw message