[
https://issues.apache.org/jira/browse/BOOKKEEPER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13430953#comment-13430953
]
Rakesh R commented on BOOKKEEPER-336:
-------------------------------------
@Ivan Thanks a lot for the new idea. Just few clarifications.
bq. I'd prefer to only have one implementation of the reading schedule
@Flavio @Sijie
Would like to know your opinion on this. As we had talked about to have a
separate scheduling algo for the perf oriented strategies?
bq.When making a read request, if the last response time for the replica is
greater than a configured threshold, make the read request for the next replica
also.
You are suggesting to have parallel reads and whoever wins will send the result
back to the client. Also collect statistics of the previous reads.
Will the parallel read (to the quorum bookies) makes the bkserver busy/exhaust
with many read requests ?
bq.To do this, we maintain a array of int in PendingReadOp, int[] responseTimes
= new int[ensembleSize];
Since PendingReadOp is for single entry, bookie statistics should be maintained
behind and in the bkclient like,
HashSet bkResponseTimes <InetAddress, Integer> = new HashSet <InetAddress,
Integer>().
When reading, it justs initialize the PendingReadOp with previous
statistics(UNKNOWN/PENDING/+ve integer) and will send the requests to the
bookie which has good response time. Also I feel, the bookies can be reordered
based on the statistics by sending request to the good/fast bookies first.
> bookie readEntries is taking more time if the ensemble has failed bookie(s)
> ---------------------------------------------------------------------------
>
> Key: BOOKKEEPER-336
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-336
> Project: Bookkeeper
> Issue Type: Bug
> Affects Versions: 4.1.0
> Reporter: Brahma Reddy Battula
> Assignee: Rakesh R
> Attachments: BOOKKEEPER-336.1.patch, BOOKKEEPER-336.patch
>
>
> Scenario:
> 1) Start three bookies. Create ledger with ensemblesize=3, quorumsize=2
> 2) Add 100 entries to this ledger
> 3) Make first bookie down and read the entries from 0-99
> Output: Each entry is going to fetch from the failed bookie and is waiting
> for the bookie connection timeout, only after failure going to next bookie.
> This is affecting the read entry performance.
> Impact: Namenode switching time will be affected by adding this failed bookie
> readTimeOut also.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
