Полагаю потому, что тогда ТГ в рф в том числе через них ходил. Я не очень уверен, что это значит, но может «у этого оператора прямой маршрут к серверам ТГ а у других операторов - более сложные маршруты.
Это не значит, что весь трафик рф в тг ходит через этих ребят, это значит что через этих ребят ходит быстрее.
Ps может про маршруты я ошибаюсь, лучще перепроверить. Но доказательство слабовато. И устарело уже
+100500 дело не в том, что в IT просто дело в том, что в других профессиях дойти до такой ЗП почти невозможно не из-за сложности а потому, что их там нет
тут такой нюанс, проц (ядро) ведь на самом деле не может быть занят на 60% Он либо занят либо нет.
А 60% просто означает что "за последние 5 секунд он был занят 60% времени"
Соответственно, % загрузки означает сколько времени вам нужно будет ждать своей очереди. Чем больше загрузка - тем с бОльшим количеством других задач придётся толкаться.
А ещё второй нюанс действует (это мы в AWS словили):
в x86 процессорах ядра "располовинены" гипертрейдингом. И это круто, но - это не полноценные ядра. это просто возможность использовать незанятые инструкции ядра для других задач.
То есть если у у вас все задачи одинаковые (простейшие задачи для проца) - гипертрейдинг не даст плюса вовсе.
На деле так, конечно, не бывает - если вы кидаете http-запрос это порождает пачку разнообразных задач для процессора и за счёт этого гипертрейдинг даёт хороший прирост.
Но всё же не х2
Полагаю что поэтому, когда проц увеличивается выше 60% (а порой и выше 40%) мы уже начинаем ощущать тормоза ("половинка каждого ядра" выделенная как целое ядро из-за гипертрейдинга занята почти полностью)
я не говорю, что это дикие тормоза. Просто время отклика чуточку начинает плавать.
PS это не для всех систем актуально. Но в нашей системе у многих операций время отклика по вебсокету 1-8ms, так что мы замечаем.
хорошо - это когда в среднем утилизация ресурсов 10%-30% а в пиках 30%-60%
выше не стоит, потому что при 70%-80% система будет уже заметно тормозить а в облаках в некоторых ситуациях уже и после 40% становится заметно что времена отклика начинают расти
на самом деле это очень интересно - почему тесты приложения в докере могут выдавать результаты, сильно отличающиеся от того же приложения, не в докере.
В смысле - я не сомневаюсь в ваших результатах, но мне важно, в каких условиях они воспроизводятся (много работаю с приложениями в докере, хочется лучше понимать его ограничения) Можете рассказать о подходе к тестированию?
Для затравки я расскажу, как я это вижу: Интересен тест близкий к целевому, так что будем не просто нагружать проц а кидать HTTP-запросы - Нужно 2 сервера на Linux (источник нагрузки и объект тестирования) - на серверах выполняем настройки, типа увеличения диапазона портов, tw_reuse, всякое такое, чтобы настройки операционки не мешали Часть настроек можно взять отсюда https://docs.gatling.io/concepts/operations/
========== тест 1: запускаем приложение на сервере объекта тестирования
тест 2: Запускаем то же самом приложение на том же самом сервере, но в докер-контейнере. У контейнера прописаны Request достаточные, чтобы запустить приложение, а Limit не прописаны вовсе (можно прописать для лимит для памяти равный 80% от свободной оперативки на сервере, но для CPU) точно не нужно прописывать лимит, троттлинг может очень сильно зааффектить на приложение в контейнере ==========
Сами тесты одинаковые, со второго сервера подаём постепенно увеличивающуюся нагрузку. Смотрим где захлебнётся (прекратится рост производительности, начнут расти времена отклика или ошибки)
Для проверки лучше брать приложение, которое не работает с диском.
Будете ещё НТ делать - приходите к нам, в @QA_Load - тусовка НТшников в телеге. Если понадобится - поможем с анализом. У нас тепло, ошибки помогают найти а не ищут в них повода повыпендриваться осуждением
проф.деформация - мы видим только код с ошибками, а значит не видим в нём ничего "необычно-плохого".
Я работаю в НТ и часто встречаю "простые" ошибки даже у крутых разработчиков. Отсутствие кэширования, запрос в цикле..
Что уж говорить про мои собственные ошибки :) ============= Простые ошибки хороши тем, что ты их делаешь только один раз, и напоровшись единожды больше их не повторяешь. Но то, что комментатор в интернете про эту ошибку уже хорошо знает (напоровшись сам или прочитав яркую статью - типа вашей, кстати) - так вот, это не значит, что он сам никогда не совершал ДРУГУЮ простую ошибку.
PS А может и не совершал. Бывают крутые супервнимательные люди. Честь им и хвала! Жаль, что я не такой.
тут речь не о критике а о стиле критики. Скажите "если вы сделаете вот так или так - ваш код может получиться ещё лучше" - и человек к вам прислушается.
Скажите "детский сад" и человек пропустит все ценности вашего поста мимо ушей.
Сорри, но недоступность оригинальных деталей связана не с «запланированным устареванием» а с «чем-то другим»
А вы прям ждали возможности расчехлить :)
Спасибо за ответы на незаданые вопросы :)
Предположу что доступ извне оставили чтобы поменять настройки впн когда конкретный впн сервер/протокол заблокируют
Для секретных данных вообще очень мало что стоит использлвать
а в этой статье говорится, что телеграм аффилирован с фсб потому, что один провайдер когда-то давно порадовался, что тг разблочен
https://gblnet-ru.gbl.dev.it-service.io/news/39
Полагаю потому, что тогда ТГ в рф в том числе через них ходил. Я не очень уверен, что это значит, но может «у этого оператора прямой маршрут к серверам ТГ а у других операторов - более сложные маршруты.
Это не значит, что весь трафик рф в тг ходит через этих ребят, это значит что через этих ребят ходит быстрее.
Ps может про маршруты я ошибаюсь, лучще перепроверить. Но доказательство слабовато. И устарело уже
выглядит красиво
но под крышечкой!
чёт мне кажется у дальнобоев профессия убегает вовсю
+100500
дело не в том, что в IT просто
дело в том, что в других профессиях дойти до такой ЗП почти невозможно
не из-за сложности а потому, что их там нет
тут такой нюанс, проц (ядро) ведь на самом деле не может быть занят на 60%
Он либо занят либо нет.
А 60% просто означает что "за последние 5 секунд он был занят 60% времени"
Соответственно, % загрузки означает сколько времени вам нужно будет ждать своей очереди. Чем больше загрузка - тем с бОльшим количеством других задач придётся толкаться.
А ещё второй нюанс действует (это мы в AWS словили):
в x86 процессорах ядра "располовинены" гипертрейдингом. И это круто, но - это не полноценные ядра. это просто возможность использовать незанятые инструкции ядра для других задач.
То есть если у у вас все задачи одинаковые (простейшие задачи для проца) - гипертрейдинг не даст плюса вовсе.
На деле так, конечно, не бывает - если вы кидаете http-запрос это порождает пачку разнообразных задач для процессора и за счёт этого гипертрейдинг даёт хороший прирост.
Но всё же не х2
Полагаю что поэтому, когда проц увеличивается выше 60% (а порой и выше 40%) мы уже начинаем ощущать тормоза ("половинка каждого ядра" выделенная как целое ядро из-за гипертрейдинга занята почти полностью)
я не говорю, что это дикие тормоза. Просто время отклика чуточку начинает плавать.
PS это не для всех систем актуально. Но в нашей системе у многих операций время отклика по вебсокету 1-8ms, так что мы замечаем.
ок, пожалуй согласен
хорошо - это когда в среднем утилизация ресурсов 10%-30% а в пиках 30%-60%
выше не стоит, потому что при 70%-80% система будет уже заметно тормозить
а в облаках в некоторых ситуациях уже и после 40% становится заметно что времена отклика начинают расти
на самом деле это очень интересно - почему тесты приложения в докере могут выдавать результаты, сильно отличающиеся от того же приложения, не в докере.
В смысле - я не сомневаюсь в ваших результатах, но мне важно, в каких условиях они воспроизводятся (много работаю с приложениями в докере, хочется лучше понимать его ограничения)
Можете рассказать о подходе к тестированию?
Для затравки я расскажу, как я это вижу:
Интересен тест близкий к целевому, так что будем не просто нагружать проц а кидать HTTP-запросы
- Нужно 2 сервера на Linux (источник нагрузки и объект тестирования)
- на серверах выполняем настройки, типа увеличения диапазона портов, tw_reuse, всякое такое, чтобы настройки операционки не мешали
Часть настроек можно взять отсюда
https://docs.gatling.io/concepts/operations/
==========
тест 1: запускаем приложение на сервере объекта тестирования
тест 2: Запускаем то же самом приложение на том же самом сервере, но в докер-контейнере.
У контейнера прописаны Request достаточные, чтобы запустить приложение, а Limit не прописаны вовсе (можно прописать для лимит для памяти равный 80% от свободной оперативки на сервере, но для CPU) точно не нужно прописывать лимит, троттлинг может очень сильно зааффектить на приложение в контейнере
==========
Сами тесты одинаковые, со второго сервера подаём постепенно увеличивающуюся нагрузку.
Смотрим где захлебнётся (прекратится рост производительности, начнут расти времена отклика или ошибки)
Для проверки лучше брать приложение, которое не работает с диском.
Будете ещё НТ делать - приходите к нам, в @QA_Load - тусовка НТшников в телеге. Если понадобится - поможем с анализом.
У нас тепло, ошибки помогают найти а не ищут в них повода повыпендриваться осуждением
проф.деформация - мы видим только код с ошибками, а значит не видим в нём ничего "необычно-плохого".
Так сказать, "ошибка невыжившего", ахаха :)
Я работаю в НТ и часто встречаю "простые" ошибки даже у крутых разработчиков.
Отсутствие кэширования, запрос в цикле..
Что уж говорить про мои собственные ошибки :)
=============
Простые ошибки хороши тем, что ты их делаешь только один раз, и напоровшись единожды больше их не повторяешь.
Но то, что комментатор в интернете про эту ошибку уже хорошо знает (напоровшись сам или прочитав яркую статью - типа вашей, кстати) - так вот, это не значит, что он сам никогда не совершал ДРУГУЮ простую ошибку.
PS А может и не совершал. Бывают крутые супервнимательные люди. Честь им и хвала!
Жаль, что я не такой.
тут речь не о критике а о стиле критики.
Скажите "если вы сделаете вот так или так - ваш код может получиться ещё лучше" - и человек к вам прислушается.
Скажите "детский сад" и человек пропустит все ценности вашего поста мимо ушей.
Очень спорное утверждение. Почему вы так считаете?
а на сколько% железо должно быть использовано в пике, по вашему мнению?
20% это имхо как раз хорошо (пока денег на такое железо хватает)
как много "злых" комментов.
Это печально.
Все совершают ошибки, такие статьи помогают их избегать.
Статья интересная, спасибо за неё!
Я HD Tune предпочитал
Ну значит началось со смерти TJ
Прочитал вашу ссылку и понял, что сперва неверно вас понял :)
Вы писали про подключение к одному серверу 1с а я решил что это подключение от имени одного пользователя 1с
спасибо за инфу!