Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ton storage active serving capacity / load tests with a lot of bags? #1245

Open
ice-cronus opened this issue Oct 5, 2024 · 0 comments
Open

Comments

@ice-cronus
Copy link

ice-cronus commented Oct 5, 2024

Hi guys! In one of blog posts I noticed that ton storage is gonna be decentralized replacement of CDN, but CDN is serving millions of files, is ton storage implementations (ton-storage-daemon / tonutils storage) capable to serve thousands / hundreds thousands / millions of bags, did you load test it or maybe anyone is running provider (as I understood it is based on ton storage daemon) with a lot of bugs?

I noticed in provider setup that it goes with 100 contracts / bags by default but value seems too low to build a decentralized CDN. I tried to experiment myself with 2 daemons running on the same machine (different ports) and in one I created a lot of bags (started with ~1000) and in another one initiated download of them by bagID (add-by-hash), and I noticed only 9 bags were downloaded right away, others were stuck in resolving (fetching header) state or downloading with 0 bytes. Tried also tonutils-storage implementation, it works much better ~100-200 bags were downloaded right away and then it continued to download them but slowly.

Anyway looks like single daemon will be unable to serve millions uploads to other nodes concurrently, so it is needed to multiplex it with multiple instances, so actual question is how many bags / active uploads one ton storage instance can handle? Or what's count of bags can be served by CPU core?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant