Есть скрипт, который тащит ~200 текстовых файлов с одного сервера
Работал нормально полгода в продакше и начал отваливаться — половина файлов не скачивается. Если повторять скачивание, то со временем приходят все файлы.

Фидлер сообщает, что запросы заканчиваются по таймауту. Если перезапустить запрос прямо в фидлере, файл приходит. Если тоже самое сделать в браузере — тоже приходит.
Каждый файл тащится по простому, через GET с connection : close.
Файлы скачиваются все хором. Если изменить это скажем, на 2 файла одновременно, то все работает хорошо.

Еще наблюдение — если эти же файлы качнуть через браузер, т.е. сгенерировав простыню из тегов, то снова все скачивается без единой ошибки. При чем браузер тащит также по 2 файла за раз, с той разницей что connection : keep-alive

Вопрос — что отломалось на сервере или где то в сети ?

Здравствуйте, Ikemefula, Вы писали:

I>Файлы скачиваются все хором. Если изменить это скажем, на 2 файла одновременно, то все работает хорошо.

Раньше было такое правило хорошего тона — не создавать больше 10-12 одновременных соединений к серверу. Правда, это из древних времен, когда сервера были на пару.
А вообще вариантов может быть несколько:
— Настройки сервера поменяли, и теперь он не обрабатывает больше, скажем, 100 соединений одновременно. Остальные просто ждут, пока не освободится какой-нибудь, скажем, поток в пуле.
— Канал до сервера стал уже, и теперь стягивание 200 файлов занимает слишком много времени — срабатывает таймаут.
— Сервер просто перегружен.

I>Еще наблюдение — если эти же файлы качнуть через браузер, т.е. сгенерировав простыню из тегов, то снова все скачивается без единой ошибки. При чем браузер тащит также по 2 файла за раз, с той разницей что connection : keep-alive

Да, в браузерах реализована очередь запросов, поэтому нагрузочное тестирование из браузера не проведешь.

Здравствуйте, Хреннос, Вы писали:

I>>Файлы скачиваются все хором. Если изменить это скажем, на 2 файла одновременно, то все работает хорошо.

Х>Раньше было такое правило хорошего тона — не создавать больше 10-12 одновременных соединений к серверу. Правда, это из древних времен, когда сервера были на пару.
Х>А вообще вариантов может быть несколько:
Х>- Настройки сервера поменяли, и теперь он не обрабатывает больше, скажем, 100 соединений одновременно. Остальные просто ждут, пока не освободится какой-нибудь, скажем, поток в пуле.
Х>- Канал до сервера стал уже, и теперь стягивание 200 файлов занимает слишком много времени — срабатывает таймаут.
Х>- Сервер просто перегружен.

Я проверил, если запросы ставить в очередь, 3 запроса уже стабильно дает сбой. При этом есть другое приложение, отлично справляется с большой кучей запросов на тот же сервер к тем же файлам.

I>>Еще наблюдение — если эти же файлы качнуть через браузер, т.е. сгенерировав простыню из тегов, то снова все скачивается без единой ошибки. При чем браузер тащит также по 2 файла за раз, с той разницей что connection : keep-alive

Х>Да, в браузерах реализована очередь запросов, поэтому нагрузочное тестирование из браузера не проведешь.

Я не провожу нагрузочное тестирование, я хочу выяснить, откуда взялись сбои, если код уже полгода никто не трогал.

Здравствуйте, Ikemefula, Вы писали:

I>Есть скрипт, который тащит ~200 текстовых файлов с одного сервера
I>Работал нормально полгода в продакше и начал отваливаться — половина файлов не скачивается. Если повторять скачивание, то со временем приходят все файлы.

I>Вопрос — что отломалось на сервере или где то в сети ?

Добро пожаловать в реальный мир. Любая сетевая операция должна подразумевать
1) определённый уровень толерантности к сбоям сети (перезапускать закачку в случае обрыва или таймаута, повторять N попыток коннекта в случае недоступности и т.п.)
2) минимальное уважение к текущей сетевой инфраструктуре, иначе количество сбоев сети будет черезмерным

Например: вот все ругают DLink-маршрутизаторы — дескать, глюкают, рвут связь, вафля отваливается и т.п. А не надо его нагружать грудой торрентов, да ещё на VPN-канале — и всё будет хорошо.

Так и в Вашем случае: где-то в середине вполне могла случиться замена оборудования, или просадка канала, или рост трафика или влюблая комбинация этих факторов. Результат — код работал успешно, будучи в тепличных условиях. Теперь пора бы обложить его fault tolerance.

Здравствуйте, Ikemefula, Вы писали:

I>Я проверил, если запросы ставить в очередь, 3 запроса уже стабильно дает сбой. При этом есть другое приложение, отлично справляется с большой кучей запросов на тот же сервер к тем же файлам.

Вывод очевиден: посмотрите, как реализовано "другое приложение", и сделайте так же.
Возможно, оно как-то по-другому ошибки обрабатывает.
Возможно, оно запросы как-то по-другому строит.
Вариантов масса.

Здравствуйте, Ikemefula, Вы писали:

I>Есть скрипт, который тащит ~200 текстовых файлов с одного сервера
I>Работал нормально полгода в продакше и начал отваливаться — половина файлов не скачивается. Если повторять скачивание, то со временем приходят все файлы.
Скрипт, можете показать?

I>Фидлер сообщает, что запросы заканчиваются по таймауту. Если перезапустить запрос прямо в фидлере, файл приходит. Если тоже самое сделать в браузере — тоже приходит.
Лог можете показать?
Таймаут когда наступает? При попытке подключится или уже в процессе передачи файла?

I>Каждый файл тащится по простому, через GET с connection : close.
I>Файлы скачиваются все хором. Если изменить это скажем, на 2 файла одновременно, то все работает хорошо.
Правильно ли я понимаю, что скрип пытается открыть 200 соединений одновременно?

I>Еще наблюдение — если эти же файлы качнуть через браузер, т.е. сгенерировав простыню из тегов, то снова все скачивается без единой ошибки. При чем браузер тащит также по 2 файла за раз, с той разницей что connection : keep-alive
Насколько я понимаю, это может быть причиной ( keep-alive заставляет использовать один и тот же низлежащий сокет, а close каждый раз новый ).
А если в скрипте добавить keep-alive header , что получается?

I>Вопрос — что отломалось на сервере или где то в сети ?

Конечно, не видя кода и логов, и не зная, на чем работает сервер (ось и что за сервер) это пальцем в небо.

Например, если произошел update сервера, и в системе обновился параметр, который отвечает за максимальное количесвто запросов в очереди _неустановленных_ запросов для сокета.

По дороге от клиента к серверу есть какие нибудь прокси-сервера? Там могли произойти изменения в настройках явно или неявно (после обновления)....

Здравствуйте, Mr.Delphist, Вы писали:

MD>Так и в Вашем случае: где-то в середине вполне могла случиться замена оборудования, или просадка канала, или рост трафика или влюблая комбинация этих факторов.

Скипнул капитанский бред. Есть сказать чего по делу ?

Здравствуйте, Ikemefula, Вы писали:

I>Скипнул капитанский бред. Есть сказать чего по делу ?

Правь свои потоки. Рестартуй при отпадении, очевидно же.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Так и в Вашем случае: где-то в середине вполне могла случиться замена оборудования, или просадка канала, или рост трафика или влюблая комбинация этих факторов.

I>Скипнул капитанский бред. Есть сказать чего по делу ?

Вам же уже многие сказали (и все капитаны, как на подбор): реагируйте на ошибку, рестартуйте закачку если отпала.

Здравствуйте, Mr.Delphist, Вы писали:

I>>Скипнул капитанский бред. Есть сказать чего по делу ?

MD>Вам же уже многие сказали (и все капитаны, как на подбор): реагируйте на ошибку, рестартуйте закачку если отпала.

Капитанили не все, а только ты. Рестарт закачки был реализован еще полгода назад, перед выходом в продакшн. Более того, приложение работает даже если закачка отваливается.

И это, преставь, не отменяет необходимости решать указаную в первом сообщении проблему.

Здравствуйте, Protey, Вы писали:

I>>Скипнул капитанский бред. Есть сказать чего по делу ?

P>Правь свои потоки. Рестартуй при отпадении, очевидно же.

Такая страховка уже с полгода как есть. Нужно выяснить ,почему отваливаются запросы именно в этом приложении, при чем это видно через Фиддлер. В другом приложении такое же количество запросов не отваливается, отрабатывает как положено.

P>>Правь свои потоки. Рестартуй при отпадении, очевидно же.
I>Такая страховка уже с полгода как есть. Нужно выяснить ,почему отваливаются запросы именно в этом приложении, при чем это видно через Фиддлер. В другом приложении такое же количество запросов не отваливается, отрабатывает как положено.
А если запустить _одновременно_ 200 wget'ов на эти 200 текстовых файликов — они тоже все благополучно скачают?
Ибо 200 соединений открывать одновременно ради такой задачи — моветон. Может ips по пути какой теперь считает вас ddos ботом.

Здравствуйте, ononim, Вы писали:

I>>Такая страховка уже с полгода как есть. Нужно выяснить ,почему отваливаются запросы именно в этом приложении, при чем это видно через Фиддлер. В другом приложении такое же количество запросов не отваливается, отрабатывает как положено.
O>А если запустить _одновременно_ 200 wget'ов на эти 200 текстовых файликов — они тоже все благополучно скачают?

Интересная идея, надо проверить.

O>Ибо 200 соединений открывать одновременно ради такой задачи — моветон. Может ips по пути какой теперь считает вас ddos ботом.

Идейка была в том, что бы максимально ускорить скачивание и это работало ажно полгода.

Здравствуйте, Ikemefula, Вы писали:

O>>Ибо 200 соединений открывать одновременно ради такой задачи — моветон. Может ips по пути какой теперь считает вас ddos ботом.

I>Идейка была в том, что бы максимально ускорить скачивание и это работало ажно полгода.

А у идейки есть какое-то экспериментальное обоснование, или она базируется исключительно на принципе "чем больше потоков, тем должно быть быстрее"?

Здравствуйте, Хреннос, Вы писали:

O>>>Ибо 200 соединений открывать одновременно ради такой задачи — моветон. Может ips по пути какой теперь считает вас ddos ботом.

I>>Идейка была в том, что бы максимально ускорить скачивание и это работало ажно полгода.

Х>А у идейки есть какое-то экспериментальное обоснование, или она базируется исключительно на принципе "чем больше потоков, тем должно быть быстрее"?

Было так — первоначальный код качал файлы последовательно. Я убрал препятствие, из за которого это было необходимо, и написал простейший вариант закачки, безо всяких дополнительных приседаний — всю пачку разом и это работало.
Более того, это же работает и в другой прилаге.

I>>>Идейка была в том, что бы максимально ускорить скачивание и это работало ажно полгода.
Х>>А у идейки есть какое-то экспериментальное обоснование, или она базируется исключительно на принципе "чем больше потоков, тем должно быть быстрее"?
I>Было так — первоначальный код качал файлы последовательно. Я убрал препятствие, из за которого это было необходимо, и написал простейший вариант закачки, безо всяких дополнительных приседаний — всю пачку разом и это работало.
А это точно было препятствие?


I>Более того, это же работает и в другой прилаге.
Вот так пишешь код, аккуратно обходящий все потенциальные грабли, а потом ктото приходмт и аццки рефакторит, вынося все обходные тропы, в результате executinion graph скачет по граблям а-ля горный козел по плотине гидроэлектростанции.

ЗЫ ознакомьтесь с этим

Здравствуйте, ononim, Вы писали:

I>>Было так — первоначальный код качал файлы последовательно. Я убрал препятствие, из за которого это было необходимо, и написал простейший вариант закачки, безо всяких дополнительных приседаний — всю пачку разом и это работало.
O>А это точно было препятствие?

Точно, ограничение никакого отношения к сети не имело

I>>Более того, это же работает и в другой прилаге.
O>Вот так пишешь код, аккуратно обходящий все потенциальные грабли, а потом ктото приходмт и аццки рефакторит, вынося все обходные тропы, в результате executinion graph скачет по граблям а-ля горный козел по плотине гидроэлектростанции.

O>ЗЫ ознакомьтесь с этим

Да, вроде как оно