2014-09-03 4 views
1

У меня есть вопрос относительно скорости загрузки в Google Cloud Storage с использованием возобновляемых загрузок. Я написал клиентский Java-клиент для загрузки больших файлов в GCS (у него есть некоторые специализированные функции, поэтому gsutil не был ответом для моей компании). Во время тестов, проведенных около 2 месяцев назад, он очень хорошо использовал имеющуюся пропускную способность канала с примерно 20 Мбит/с из 25 Мбит/с. Проект был заморожен в течение почти двух месяцев, и теперь, когда он вновь открыт, тот же клиент загружается с очень низкой скоростью примерно на 1,4 Мбит/с из 25 Мбит/с. Я написал простой скрипт Python, чтобы проверить, будут ли у него одинаковые проблемы, и это немного быстрее, но все же примерно на 2 Мбит/с. Инструмент Gsutil выполняет почти то же самое, что и мой скрипт Python. Я также проверил тест на различной сетевой инфраструктуре со скоростью загрузки более 50 Мбит/с.GCS возобновляемая скорость загрузки

Результаты также довольно беден:

  • Java клиент 2.4Mbps
  • Python скрипт 3.2Mbps
  • GSUtil 3.2Mbps

Единственное, что изменилось это Google Cloud Версия API хранения. Я использую JSON API, и первые тесты выполнялись в версии v1beta API. В настоящий момент нет никакой разницы, если я все еще использую обесцененный API или новый.

Кто-нибудь сталкивался с одинаковым снижением скорости загрузки?

Какова средняя скорость выгрузки?

Что может быть возможной причиной столь резкого снижения производительности загрузки?

Будут ли параллельные загрузки составных объектов помочь мне полностью использовать доступную полосу пропускания?

ответ

1

Чтобы узнать, какую максимальную пропускную способность вы можете ожидать, мы предлагаем запустить команду gsutil perfdiag.

Например, чтобы увидеть, насколько хорошо она будет загружать 100 Мб файл с:

gsutil perfdiag -t wthru -s 100M gs://bucketname 

Это будет загружать 100MB файл в пять раз и сообщить о результатах. Пример вывода из моего запуска:

------------------------------------------------------------------------------ 
           Write Throughput        
------------------------------------------------------------------------------ 
Copied a 100 MB file 5 times for a total transfer size of 500 MB. 
Write throughput: 71.61 Mbit/s. 

Он также выдаст много другой информации, которая может помочь диагностировать проблему. Если вывод perfdiag показывает гораздо более высокую пропускную способность, чем ваше приложение, то что-то может быть неправильным с вашим кодом. Если выход perfdiag также является низкой пропускной способностью, то что-то может быть неправильным с вашим сетевым путем на серверах Google, что выход perfdiag может помочь определить проблему. Если это не поможет решить вашу проблему, отправьте файл результатов (perfdiag -o output.json) на адрес [email protected]

+0

Спасибо за ваш ответ, это было очень полезно для меня. Мне не удалось запустить команду perfdiag -t wthru на gsutil версии 4.5, потому что она бросала объект «NoneType» не вызываемым. Исключение (я заметил, что тестовые файлы присутствовали в ведре GCS, несмотря на ошибку). Лат и Рентру бежали без проблем. Мне удалось запустить тест на gsutil 4.2, загружающем 100M-файлы. Результаты для одного потока были такими же, как для моего скрипта Python со скоростью около 3,2 Мбит/с. Я также провел тестовый прогон для 4 потоков, и ему удалось обновить скорость загрузки до более 8 Мбит/с. –

+0

Результаты тестов означают, что мой код в порядке, и у меня проблемы с моим сетевым подключением. Интересно, почему была такая большая разница во время тестов, проведенных на одной сетевой инфраструктуре 2 месяца назад. Есть ли у вас какие-либо предложения, что я могу проверить в журналах, я должен распознать причину ограниченной скорости загрузки на серверах Google или отправить вам файлы журнала json? Еще раз спасибо за помощь. –

+0

Вы не в США? Если вы в ЕС, убедитесь, что вы пишете в ведро ЕС. В противном случае попробуйте маршрут трассировки к storage.googleapis.com – jterrace