Может при какой то высокой скорости интернета и не успевает, но дело в том что я storj пользуюсь пол года и за это время использовал его на разных компьютерах, с разными провайдерами и скоростями интернета. Мои наблюдения говорят следующее - на любом ПК скорость загрузки файлов с uplink в облако всегда в 3 - 4 раза ниже реальной пропускной способности интернет канала. Например, если канал 300 мегабит, то в облако файлы уйдут со скоростью примерно 80 мегабит, если это 100 мегабит, то реальная скорость загрузки файлов в облако будет 25 - 30 мегабит, даже юзал uplink на скорости интернета в 10 мегабит, и там все резалось в 3 - 4 раза. Вот даже к своему компу на котором 300 мегабит режется в 3 - 4 раза подключаю интернет 100 мегабит, то уже знаю что получу скорость в 3 - 4 раза ниже этих же 100 мегабит, так что грешить на то что файлы не успевают шифроватся не спешу.
Кстати если заливать файлы в storj через веб интерфейс, то вижу точно такую же картину, там где файл без ограничений скорости в централизованные облака заливается минуту, в storj залить этот же файл займет 3 - 4 минуты. На любой скорости интернета, на любом провайдере storj режет скорость в 3 - 4 раза, исключений за пол года использования storj я еще не видел.
10 Mbait eto console pokazyvaet skorost zagruzki? 1GB fael eto originalnyi razmer?
tak kak pri shifrovanii on pomuimu uveli4ivaetsa primerno 2,6 raz esli ja pravelno pomnju.
peredavaemuju skorost nado smotret na routere. tam esli u4est esjo TCP dajot dopolnitelnyi objem.
Да, это скорость которую показывает консоль, но она постоянно очень сильно колеблется. 1 гигабайт это оригинальный размер файла. Почему файл увеличивается в 2,6 раз если с облака я скачиваю его обратно в исходном размере в 1 гигабайт? Насчет скорости которую нужно смотреть в роутере, когда буду подключатся через роутер, тогда и посмотрю. А так, я не раз уже подсчитывал время и скорость за которое в облако загружал файлы и побольше 1 гига, всегда видел закономерность что storj использует 25 - 30 % интернет канала.
originalnyi fael grubo govorja 29 kuskov, a sozdajot i zagruzhet on 80 kuskov, 4toby obespe4it bezopasnost hranenija. 4toby poly4it fael obratno nado ska4at tolko pervye 29 kuso4kov.
takim obrazom esli iz 80 nodov vyzhivet tolko 29, to fael budet dostupen.
esly vy polzujetes Gateway to zagruzhete tolko originalnyi fael, a dalshe GW server uzhe delit na kuso4ki i zagruzhet takzhe na nody.
Я использовал и Gateway и без него загружал файлы, разницы в скорости загрузки файлов не заметил.
gateway-mt imell vidu, eto tozhe samoe 4to 4erez web pomoimu
Копирую из консоли Would you like S3 backwards-compatible Gateway credentials? (y/N) выбирал и y и N варианты, разницы в скорости не заметил. Это через этот Gateway я загружаю оригинальный файл а дальше Gateway сервер делат файлы и загружает на ноды?
ja govorju pro eto GitHub - storj/gateway-mt: Storj edge services (including multi-tenant, S3 compatible server to interact with the Storj network)
this one works like, you upload file to server and encryption happening there on storj server that will destribute it to nodes.
in case of upling or just geteway all encryption hapen on your PC
Попробовал заливать файлы в облако через gateway-mt. Файлы загружаются на скорости 300 мегабит которые дает провайдер. Загрузка файла с облака на ПК через gateway-mt тоже четко соответствовала 300 мегабитам. Пробовал несколько раз, результаты одинаковые.
Так же по своему опыту работы с storj скажу что скачивание файлов с облака через браузер при соединении в 300 мегабит у меня ограничивается в пределах 10 - 20 мегабАйт в секунду, а это 80 - 160 мегабИт. Даже просто скачать файлы через браузер на полной скорости еще никогда не получалось. uplink тоже режет скорость скачивания еще больше чем их просто качать через браузер.
В итоге мой опыт работы с storj показывает что все инструменты, начиная с консольных и заканчивая веб интерфейсом ограничивают пользователей в скорости передачи данных. Исключением является gateway-mt. Насколько я знаю, при загрузке файлов через веб интерфейс файлы шифруются на стороне сервера, так же как и при использовании gateway-mt. Но почему тогда файлы через веб браузер загружаются в 4 раза медленнее чем через консоль при использовании gateway-mt?
А что происходит после загрузки всех нужных кусков файла на ноды, они живут своей жизнью и перестанут быть доступными когда их будет меньше чем на 29 нодах или в сети storj есть механизм который следит за тем чтобы куски файлов размещались на нодах так чтобы пользователь никогда не потерял доступ к исходному целому файлу?
если какая то нода надолго перестает отвечать то ее считают трупом и начинают восстанавливать, перекладывают всё что в ней было на другие ноды
в блоге была статья - что будет с storj если россия пропадет с радаров полностью, рф на 4ом месте по количеству нод в мире, и если они все разом погаснут сеть всё равно не пострадает, не потеряет ни одного файла
При использовании нативной интеграции:
- Вы загружаете данных примерно в 80/29 раз больше. Это expansion factor.
- Загрузка идёт изначально на 110 узлов пока первые 80 не закончатся раньше
- При скачивании скачивание начинается с 39 узлов и прекращается, как только первые 29 будут загружены (только 29 кусочков нужно чтобы восстановить сегмент).
- Есть довольно серьёзные требования к CPU и RAM при больших скоростях, вашему CPU приходится шифровать на лету. Однако если у вас достаточно и памяти и процессора, можно попробовать использовать параметр
--parallelism.
Если будете смотреть используемый трафик на роутере, вы увидите, что на самом деле используется больше, чем 80Мбит.
При использовании GatewayMT скачивание и загрузка происходят без expansion factor, т.е. 1:1. Но шифрование происходит на стороне GatewayMT. Процессор практически не используется, но может использоваться память, если вы будете загружать сегменты больших файлов параллельно.
Пробовал использовать этот параметр, подобрал значение для своего ПК при котором скорость загрузки файлов увеличилась, но до скорости GatewayMT еще далеко.
При использовании GatewayMT скачивание и загрузка происходят без expansion factor, т.е. 1:1. Но шифрование происходит на стороне GatewayMT.
Почему тогда через веб интерфейс файлы загружаются в 4 раза медленнее чем через GatewayMT если при загрузке файлов через веб интерфейс шифрование тоже происходит на стороне сервера?
Пока что web-приложениям далеко до CLI, хотя они и стараются. Через браузер загрузка всегда менее эффективна ввиду множества ограничений (например, однопотоковость большинства современных браузеров в плане загрузки данных), и собственных ограничений браузера.
Смотрел по этой ссылке как работать с gateway-mt. Все бы хорошо, но я вижу по этой ссылке информацию только как работать с файлами. А как загружать в облако через aws целиком папку из сохранением всей структуры подпапок и файлов внутри?
Вы можете использовать команду aws s3 sync, однако я бы тогда порекомендовал лучше использовать rclone и его команду rclone sync, эта утилита обладает большими возможностями, чем aws CLI, например, позволяет задавать сколько файлов загружать параллельно.
3 posts were split to a new topic: А можно ли в storj получить ссылку на папку и по ней качать эту папку?