jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shashank Gupta (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JCR-3838) [aws-ext] Proactive & Asynchronous caching of binary when its metadata is accessed from S3
Date Wed, 10 Dec 2014 05:47:13 GMT

     [ 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:* After completing HEAD request asynchronously cached binary. So next time binary's
metadata request is fulfilled from local cache.

  was:
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 after completing HEAD request asynchronously. So next time binary's
metadata request is fulfilled from local 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
>
>         Attachments: JCR-3838.patch
>
>
> 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:* After completing HEAD request asynchronously cached binary. So next time
binary's metadata request is fulfilled from local cache.



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

Mime
View raw message