Revise PUT load registry storage #29

New issue

Open

opened 2025-12-28 18:13:38 +00:00 by sami · 3 comments

sami commented

2025-12-28 18:13:38 +00:00

Owner

Originally created by @carpawell on GitHub (Oct 4, 2023).

Expected Behavior

PUTing an object to NeoFS should do put an object to NeoFS not something else:

iteration_duration.......: avg=2.01s min=277.33µs med=1.76s max=18.59s p(90)=2.85s p(95)=3.51s
...
neofs_obj_put_duration...: avg=1.97s min=641.68ms med=1.72s max=18.52s p(90)=2.8s  p(95)=3.43s

Current Behavior

Sometimes it is possible to get such results:

iteration_duration.......: avg=6.94s min=270.07µs med=6.32s    max=27.76s p(90)=11.46s p(95)=13.61s
...
neofs_obj_put_duration...: avg=1.38s min=608.86ms med=948.46ms max=18.71s p(90)=2.07s  p(95)=3.44s

An average iteration exceeds NeoFS network part more than 4 times.

Possible Solution

Do not write objects to a local registry. See also how good an object generation is.

Steps to Reproduce (for bugs)

Just repeat and repeat and repeat load with a registry turned on and wait until iteration_duration and neofs_obj_put_duration differs enough not to make results believable.

Context

Sometimes PUT load may have extremely low speed and it does not seem like a NeoFS error: xk6 just does not provide a satisfying load.
NOTE: could be fixed in https://github.com/nspcc-dev/xk6-neofs/pull/67. Should be rechecked.

Originally created by @carpawell on GitHub (Oct 4, 2023).  ## Expected Behavior PUTing an object to NeoFS should do _put an object to NeoFS_ not something else: ``` iteration_duration.......: avg=2.01s min=277.33µs med=1.76s max=18.59s p(90)=2.85s p(95)=3.51s ... neofs_obj_put_duration...: avg=1.97s min=641.68ms med=1.72s max=18.52s p(90)=2.8s p(95)=3.43s ``` ## Current Behavior Sometimes it is possible to get such results: ``` iteration_duration.......: avg=6.94s min=270.07µs med=6.32s max=27.76s p(90)=11.46s p(95)=13.61s ... neofs_obj_put_duration...: avg=1.38s min=608.86ms med=948.46ms max=18.71s p(90)=2.07s p(95)=3.44s ``` An average iteration exceeds NeoFS network part more than 4 times. ## Possible Solution Do not write objects to a local registry. See also how good an object generation is. ## Steps to Reproduce (for bugs) Just repeat and repeat and repeat load with a registry turned on and wait until `iteration_duration` and `neofs_obj_put_duration` differs enough not to make results believable. ## Context Sometimes PUT load may have extremely low speed and it does not seem like a NeoFS error: xk6 just does not provide a satisfying load. NOTE: could be fixed in https://github.com/nspcc-dev/xk6-neofs/pull/67. Should be rechecked.

sami added the

bug

labels

2025-12-28 18:13:38 +00:00

sami commented

2025-12-28 18:13:39 +00:00

Author

Owner

@carpawell commented on GitHub (Oct 4, 2023):

Maybe add some metrics that say what time registry operations take.

@carpawell commented on GitHub (Oct 4, 2023): Maybe add some metrics that say what time registry operations take.

sami commented

2025-12-28 18:13:39 +00:00

Author

Owner

@roman-khimov commented on GitHub (Oct 4, 2023):

Do not write objects to a local registry

I have not looked at its internals, but it seems to me we need this registry for subsequent object fetching. But does it need to be stored anywhere or in-mem map will suffice is an open question to me.

@roman-khimov commented on GitHub (Oct 4, 2023): > Do not write objects to a local registry I have not looked at its internals, but it seems to me we need this registry for subsequent object fetching. But does it need to be stored anywhere or in-mem map will suffice is an open question to me.

sami commented

2025-12-28 18:13:39 +00:00

Author

Owner

@carpawell commented on GitHub (Oct 4, 2023):

I have not looked at its internals, but it seems to me we need this registry for subsequent object fetching.

Yes, it is needed only if we are PUTting and GETting objects at the same time. So we are testing a storage and using another storage for it with undefined (by default) i/o latency (from an object iteration point of view). So in-mem may look better, yes.

@carpawell commented on GitHub (Oct 4, 2023): > I have not looked at its internals, but it seems to me we need this registry for subsequent object fetching. Yes, it is needed only if we are PUTting and GETting objects at the same time. So we are testing a storage and using another storage for it with undefined (by default) i/o latency (from an object iteration point of view). So in-mem may look better, yes.