You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Shashank Gupta (JIRA)" <ji...@apache.org> on 2014/12/10 06:24:12 UTC
[jira] [Updated] (JCR-3838) [aws-ext] Proactive & Asynchronous
caching of binary when its metadata is accessed from S3
[ https://issues.apache.org/jira/browse/JCR-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shashank Gupta updated JCR-3838:
--------------------------------
Description:
When there is length request for a binary( not present in local cache),S3DS just send HEAD request of binary in S3 to fetch the metadata. The actual binary is not retrieved and cached locally. The reason is that length is often needed in list pages and caching these binaries locally slow down the response time. The impact is higher if there is large binaries( say 1GB) are there in list pages.
Customer reported that in their application sees lot of HEAD request ( approx 1500) for the same binary as it is not cached in HEAD request. Now it seems that the bottleneck are the HEAD requests that are hitting the S3.
*Solution: Cache binary in getLength call asynchronously. So next time getLength call it is fulfilled from cache.
> [aws-ext] Proactive & Asynchronous caching of binary when its metadata is accessed from S3
> ------------------------------------------------------------------------------------------
>
> Key: JCR-3838
> URL: https://issues.apache.org/jira/browse/JCR-3838
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-data
> Affects Versions: 2.9
> Reporter: Shashank Gupta
> Fix For: 2.9
>
>
> When there is length request for a binary( not present in local cache),S3DS just send HEAD request of binary in S3 to fetch the metadata. The actual binary is not retrieved and cached locally. The reason is that length is often needed in list pages and caching these binaries locally slow down the response time. The impact is higher if there is large binaries( say 1GB) are there in list pages.
> Customer reported that in their application sees lot of HEAD request ( approx 1500) for the same binary as it is not cached in HEAD request. Now it seems that the bottleneck are the HEAD requests that are hitting the S3.
> *Solution: Cache binary in getLength call asynchronously. So next time getLength call it is fulfilled from cache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)