Make pool choose the node according to container/object storage policy #25

New Issue

Open

opened 2023-03-08 23:37:45 +00:00 by snegurochka · 1 comment

snegurochka commented

2023-03-08 23:37:45 +00:00

Collaborator

Original issue: https://github.com/nspcc-dev/neofs-sdk-go/issues/297

When a protocol gate tries to PUT or GET an object, it uses the client pool connections to a technically random storage node. If it could use the node from the set of container nodes (if there is any of them in current connection pool), it could improve performance. If there are no nodes from the container set, everything would work as it is now.

The cost of modification:

Adding Network Map operation to API and having netmap sync logic in the client
Adding code to sync netmap version (epoch field observed from messages, WS subscriptions, etc)
Need to get policy from container structure
Additional calculation (CPU is usually not a bottleneck in our case)

Protocol gateways have a container cache on their side, hence it may be better to accept the storage policy as an argument.

Original issue: https://github.com/nspcc-dev/neofs-sdk-go/issues/297 When a protocol gate tries to PUT or GET an object, it uses the client pool connections to a technically random storage node. If it could use the node from the set of container nodes (if there is any of them in current connection pool), it could improve performance. If there are no nodes from the container set, everything would work as it is now. The cost of modification: - Adding Network Map operation to API and having netmap sync logic in the client - Adding code to sync netmap version (epoch field observed from messages, WS subscriptions, etc) - Need to get policy from container structure - Additional calculation (CPU is usually not a bottleneck in our case) Protocol gateways have a container cache on their side, hence it may be better to accept the storage policy as an argument.