[ 
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 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!

  was:
We found that the CPU time of createPipelineForRead 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. 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 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!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to