[
https://issues.apache.org/jira/browse/HDDS-15602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Andika updated HDDS-15602:
-------------------------------
Description:
We found that the CPU time of createPipelineForRead during high read traffic is
mostly spent waiting on the SecureRandom monitor lock during the UUID random
generation. SecureRandom is static and requires therefore lock should be
static. Since the SecureRandom is static, it also contends with all other UUID
generation and can affect performance (as per Amdahl's law). I don't think it
is required to use SecureRandom for read pipeline ID since the read pipeline ID
is not sensitive (AFAIK it's throwaway ID) and predicting the next read
pipeline ID should not have any security implication. We can also check whether
it's necessary to use random pipeline ID at all (Edit: Seems it's needed for
the client-side pipeline cache key).
!image-2026-06-18-17-44-58-985.png|width=855,height=678!
was:
We found that the CPU time of createPipelineForRead during high read traffic is
mostly spent on random UUID generation that uses SecureRandom. SecureRandom is
static and requires therefore lock should be static. Since the SecureRandom is
static, it also contends with all other UUID generation and can affect
performance (as per Amdahl's law). I don't think it is required to use
SecureRandom for read pipeline ID since the read pipeline ID is not sensitive
(AFAIK it's throwaway ID) and predicting the next read pipeline ID should not
have any security implication. We can also check whether it's necessary to use
random pipeline ID at all (Edit: Seems it's needed for the client-side pipeline
cache key).
!image-2026-06-18-17-44-58-985.png|width=855,height=678!
> PipelineId randomId does not need to use secure random
> ------------------------------------------------------
>
> Key: HDDS-15602
> URL: https://issues.apache.org/jira/browse/HDDS-15602
> Project: Apache Ozone
> Issue Type: Improvement
> Reporter: Ivan Andika
> Assignee: Ivan Andika
> Priority: Major
> Attachments: image-2026-06-18-17-44-58-985.png
>
>
> We found that the CPU time of createPipelineForRead during high read traffic
> is mostly spent waiting on the SecureRandom monitor lock during the UUID
> random generation. SecureRandom is static and requires therefore lock should
> be static. Since the SecureRandom is static, it also contends with all other
> UUID generation and can affect performance (as per Amdahl's law). I don't
> think it is required to use SecureRandom for read pipeline ID since the read
> pipeline ID is not sensitive (AFAIK it's throwaway ID) and predicting the
> next read pipeline ID should not have any security implication. We can also
> check whether it's necessary to use random pipeline ID at all (Edit: Seems
> it's needed for the client-side pipeline cache key).
> !image-2026-06-18-17-44-58-985.png|width=855,height=678!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
