Комментарии 30
Видимо это совсем не интересно.
Не переживайте, инфа найдёт своего потребителя)
Утилита поддерживает исполнение JS? (в JS могут быть вызовы API, которые тоже добавляют нагрузку на сервер)
Утилита поддерживает исполнение JS? (в JS могут быть вызовы API, которые тоже добавляют нагрузку на сервер)
Я не переживаю. Скорее удивлён. Но спасибо за поддержку )
Вроде на хабаре жалуются что мало технических статей. Но вот взяли и заминусовали.
Я думал почему. Пришёл к выводу — решаемый баг оказался пшиком. Я мог конечно придумать более эпичную концовку, но честно написал как было. Думал статья будет интересна как пример поиска бага. Как подходил с разных сторон. Но это никому не интересно — как оказалось. Возможно статья имеет низкий технический уровень. Не знаю.
Что качается вашего вопроса — утилита написана на C#. HTTP запросы сам формирую. Т.е. в коде. Утилита писал чисто для тестов. На C# можно быстро писать подобные утилиты.
Поддержку JS — что бы ответить надо понять что вы имели ввиду.
Если в качестве скриптового языка для запросов в утилите — то разумеется нет. Конечно можно реализовать — но это вообще не моя цель. Если надо устроить DOS на API — так это обычные AJAX запросы. Я точно также могу их набросать в коде — и запросы будут уходить на сервер. Ответ на AJAX — та же html страница. Делай с ней что хочешь.
Собственно скриптовый язык запросов для меня это — исходники утилиты. Придумал запрос. Написал его в коде. И в работу.
Вроде на хабаре жалуются что мало технических статей. Но вот взяли и заминусовали.
Я думал почему. Пришёл к выводу — решаемый баг оказался пшиком. Я мог конечно придумать более эпичную концовку, но честно написал как было. Думал статья будет интересна как пример поиска бага. Как подходил с разных сторон. Но это никому не интересно — как оказалось. Возможно статья имеет низкий технический уровень. Не знаю.
Что качается вашего вопроса — утилита написана на C#. HTTP запросы сам формирую. Т.е. в коде. Утилита писал чисто для тестов. На C# можно быстро писать подобные утилиты.
Поддержку JS — что бы ответить надо понять что вы имели ввиду.
Если в качестве скриптового языка для запросов в утилите — то разумеется нет. Конечно можно реализовать — но это вообще не моя цель. Если надо устроить DOS на API — так это обычные AJAX запросы. Я точно также могу их набросать в коде — и запросы будут уходить на сервер. Ответ на AJAX — та же html страница. Делай с ней что хочешь.
Собственно скриптовый язык запросов для меня это — исходники утилиты. Придумал запрос. Написал его в коде. И в работу.
а по каким причинам если не секрет? Будет иронично, если низкий технический материал и не соответствует тематике хабра, что опять же указывает на не справедливость… Если орфографические ошибки, то я всего одну увидел, где Вы себя в женском роде написали [сказала], но минусовать за это это дико по моему мнению
а по каким причинам если не секрет?
Не понял вопроса. Вы спрашиваете почему по моему мнению заминусовали статью? Если да то для меня это секрет. Собственно статья может быть не интересной — ну тогда просто уходишь. Зачем ставить минус? Я сам никогда не ставлю — не вижу смысла. Думаю что может люди ставили минус потому что баг в результате оказался слишком банальным.
Зачем ставить минус?
Во-первых, это обратная связь автору.
Во-вторых, это некий сигнал тем, кто идет по ленте, и выбирает статьи почитать.
Я бы предпочёл разгромный комментарий. Хоть понятно что не так. Опять же я постоянно замечаю что минусы и плюсы ставят за компанию.
Но я не жалуюсь. Просто констатирую факт.
Но я не жалуюсь. Просто констатирую факт.
Нет, когда дизлайкают ставят причину. Автор статьи всегда может посмотреть причину минусов). Причины минусов есть всегда [низкое качество; ничего не понял; не соответствует тематике хабра; офограыические ошибки; личная неприязнь; другое] Это Вы можете посмотреть, просто нажав на оценку вашей статьи в виде стрелочек. Вот я и спросил Вас по какой причине задисили)))
Спасибо. Не знал про такой функционал. Собственно там было низкий технический уровень 60%, ничего не понял 20%, ошибки 20%
Посмотрев другие варианты — понял что некоторые вряд ли вообще пользуются популярностью. Вроде — личная неприязнь к автору.
Впрочем такие ответы — особо ничего не говорят. И так были догадки либо технический уровень. Либо ошибки. Но если технический уровень — куда его ещё повышать в тематике подобной статьи? Выкладывать портянки кода с подробным анализом каждой строки? Может минусующие вообще не согласны с способом поиска бага и у них совершенно другие взгляды на это. Но к сожалению они посчитали объяснения выше своих сил.
Кстати причина по которой я не знал что при установки минуса — нужно писать почему, та что я никого никогда не минусил) Забавный случай.
Посмотрев другие варианты — понял что некоторые вряд ли вообще пользуются популярностью. Вроде — личная неприязнь к автору.
Впрочем такие ответы — особо ничего не говорят. И так были догадки либо технический уровень. Либо ошибки. Но если технический уровень — куда его ещё повышать в тематике подобной статьи? Выкладывать портянки кода с подробным анализом каждой строки? Может минусующие вообще не согласны с способом поиска бага и у них совершенно другие взгляды на это. Но к сожалению они посчитали объяснения выше своих сил.
Кстати причина по которой я не знал что при установки минуса — нужно писать почему, та что я никого никогда не минусил) Забавный случай.
Возможно имеется ввиду оформление. У меня так две статьи задисили. Одну я даже убрал. Видимо хотят чуть попроще и картинок побольше. Хотя фиг его знает. Низкого уровня я не заметил. Пишите ещё. Попробуйте в науч-поп, но по вашей тематике. Еще мне кажется чем больше карма, тем больше читают, но я смотрю со второй статьёй Вы карму и приподняли. Пишите не останавливайтесь.
НЛО прилетело и опубликовало эту надпись здесь
Именно так. На хабре кстати много таких «умников» обитает, есть и конкретные мракобесы.
Ахахах. Я от вас убежал из этой темы, так вы за мной сюда пришли? Признавайтесь вы мне карму понизили? К слову я вам не понижал (да и ни кому не ставлю минусы) — хоть вы в той теме преследовали только одну цель — облить помоями собеседника.
Что касается «компетенции» — ВООБЩЕ нету спора с моей стороны о компетенции статьи. Я лишь настаиваю — ну блин напишите пару слов, что не так? Если тема статьи лежит вне интереса читающего — так проходи мимо. Тем много.
А так поставят минус — собственно мне на них наплевать. Но меня начинает мучить вопрос. Раз поставили минус, значит где то я не прав. Значит есть куда расти. Но минусующие — сами походу не знают за что они минусы ставят.
Что касается «компетенции» — ВООБЩЕ нету спора с моей стороны о компетенции статьи. Я лишь настаиваю — ну блин напишите пару слов, что не так? Если тема статьи лежит вне интереса читающего — так проходи мимо. Тем много.
А так поставят минус — собственно мне на них наплевать. Но меня начинает мучить вопрос. Раз поставили минус, значит где то я не прав. Значит есть куда расти. Но минусующие — сами походу не знают за что они минусы ставят.
НЛО прилетело и опубликовало эту надпись здесь
Он не может Вам карму понизить, потому что у него карма вечно в минусе. Интересно, что у него нулевая карма была благодаря мне, но он всё равно с кем-то уже поругаться успел. Стоит убрать плюсик и он в минусе не на два очка будет, а на 4-ре. Его не очень сообщество любит…
Т.е Вы сейчас полностью устранили баг с socket? И после перезапуска не надо все эти процедуры повторять заново? Статья хорошая!
Тот который описывался в статье — да. Однако проводя дальнейшие испытания — удалось выявить другие. Непонятные — то ли стек переполняется, то ли сжираются все ресурсы процессора. Есть простор для испытаний.
А те процедуры который я описывал в статье — они были предназначены для проверки не только сокета, но и механизмов веб сервера. Как создаются и удаляются клиенты. Как обслуживается очередь клиентов. Порты и прочее. Всё это проверено — работает соответственно ожиданиям. И дальше уже не надо запускать эти процедуры.
А те процедуры который я описывал в статье — они были предназначены для проверки не только сокета, но и механизмов веб сервера. Как создаются и удаляются клиенты. Как обслуживается очередь клиентов. Порты и прочее. Всё это проверено — работает соответственно ожиданиям. И дальше уже не надо запускать эти процедуры.
Продолжая эксперименты, я обнаружил в коде один хитрый перехватчик исключений на слушающим socket.
…
В этом exсeption была паузу.
Поясните, пожалуйста, это в вашем коде был такой обработчик исключений? Или, не дай бог, в библиотеке?
Как видно – для работы с слушающим socket нужно 3 действия. Создали. Слушаем. Принимаем клиентов. Схема настолько простая что программисту не остаётся никаких способов для манёвров, ну или возможностей отстрелить себе ногу.
Вот в этом-то и состоит оборотная сторона высокоуровневых средств: они могут скрывать под собой кое-что существенное с низкого уровня — там где ногу отстрелить себе таки можно (вы в этом убедились).
Потому что на уровне API ОС (в Windows он по старинке называется WinSock, сейчас это — часть Win32 API, а вообще этот API — он родом с BSD, и в современных *nix он везде весьма похож) -там не три, а (минимум) четрые действия: если брать изначальные вызовы (сейчас вместо них в Windows обычно используются их расширенные варианты, но общая логика осталась), то это будут socket (создание слушающего сокета), bind(установка адреса и порта для прослушивания), listen(запуск прослушивания) и accept (прием подключения с получением приемного сокета). Из этих операций вы не видите listen, а он есть, и имеет параметр — длину очереди (т.е. на уровне API длина настраивается, но вообще она не оень велика, ЕМНИП не более 65535): макс. число подключений, принятых ОС, но ожидающих обработки со стороны приложения (вызовом accept или его аналога). Как только эта очередь исчерпывается, то ОС перестает принимать подключения и получается ровно та картина, которую вы видели — это вторая причина отказа соединения, кроме того, что порт вообще не прослушивается.
Поэтому у людей, работавших с WinSock на низком уровне, при виде такой картины сразу возникает мысль: а не мешает ли что своевременному вызову accept (у вас это была задержка в обработчике исключений)?..
Ну, а всякие высокоуровневые оболочки для WinSock нередко запускают accept в отдельном потоке, чтобы цикл приема подключений случайно не заблокировался (VCL в Delphi, к примеру именно так делала). А в MS в TPL, я гляжу, понадеялись на асинхронность (и это правильно — в той же Delphi при принятых тогда подходах поток подключений мог запросто породить сотню-другую потоков, по одному на подключение) и на осведомленность программиста — а вот с этим сложнее: не только лишь все программисты сейчас знают низкоуровневые детали Sockets/Winsock API (подозреваю, что заминусовавшие вашу статью — как раз знают давно и хорошо) и проистекающие отттуда возможные неприятности.
Поясните, пожалуйста, это в вашем коде был такой обработчик исключений?
Да это был обработчик в веб сервере.
А по поводу сторонних библиотек я с вами полностью согласен. Никогда не знаешь выиграешь или потеряешь. Если реализовал — и всё работает. Выиграл. Если столкнулся с тем что функционал не подходит или не дай бог баг — проиграл. Потому как по итогу времени на исправление займёт больше чем на свой велосипед.
По поводу socket в .net — ИМХО, там изначально всё было достаточно корявенько. О чём свидетельствуют многочисленные вопросы в топиках. И если не использовать Task — а всякие callback — то выглядит не очень. Хотя может это и не вина .net.
И опять же мне удалось убить socket огромным числом подключений — что бы разобраться что к чему — надо лезть в исходники socket. И тут получается ситуация что мы уже начинаем терять от использования готового. Если бы использовался самый низкий уровень — проблема была бы видна.
Хотя опять же — может и не socket виноват, а стек программы. Это на вскидку — потому как вроде не должен стек переполняться. Просто симптомы такие же как в этой статье — ничего не работает. А почему, пойди разберись. Потом окажется что опять какая то фигня. Но что бы найти ту фигню почему то надо очень сильно постараться и опять 100500 разных экспериментов провести.
что бы разобраться что к чему — надо лезть в исходники socket.
Не обязательно. Мысль была в том, что концептуальное понимание, как работает на низком уровне используемая технология — оно помогает сделать разумное предположение о причине проблемы и без копания в деталях в исходниках (кстати, я в них загляывал когда писал предыдущий ответ — и там все очень непрозрачно).
PS Непосредственной причиной, почему не был вызван вовремя accept, возможно, явлилось то, что кончились потоки в пуле, которым можно было бы поручить эту задачу: все висели на Delay. Но это неточно. Однако симптоматика (а вы ее достаточно нарыли: порт прослушивается, но соединение все равно отвергается) уже сразу указывала именно на невызов accept вовремя.
Увидев это в своих рекомендациях по интересам в Гугле, решил специально отписаться об этой статье .
Зачем делать велосипед, если есть софт от Apache для тестирования балансировки нагрузки, который как по мне лучше костылей всяких работает.
Тестить это с Windows — безумие.
И есть несколько вариантов http флуда: забивать его сокетами (пока их не хватит для новых подключений), флудить максимально столько, чтобы на сервере вообще места не осталось.
Советую присмотреться к софта ntopng чтобы понимать как работают подключения, и ведёт себя трафик.
Есть пару ультит ещё для доса под лину. Сказать точно не смогу, ни дома, пишу с тел. Отпишусь обязательно...!))
По поводу софта — я попытался объяснить свою точку зрения, повторюсь.
Разумеется наверняка есть много полезных утилит для тестирования. Но их надо искать, качать, изучать и настраивать для работы.
И что же делают эти утилиты. Ну скорее всего они делают http запросы. Мне было намного проще делать http запросы в своём велосипеде. Подобного рода программы на C# пишутся за минут 10-20.
Конечно мои доводы могут быть совершенно неверны. Но я по крайней мере привожу их. За использования сторонних утилит — я доводов пока не видел. Вернее они есть — но мои доводы, ИМХО, перевешивают. Разумеется я буду рад услышать про киллер-фичу, которую будет сложно либо лениво реализовывать у себя, и я перейду на стороннюю утилиту.
По поводу Windows — думаю тут больше религиозная точка спора, чем факты ) И дабы сгладить ситуацию скажу — что сам сервер также скомпилирован и под linux и стоит на ubuntu server. И там тоже тестировался. linkin.link висит на на ubuntu server. Если посмотреть шапку ответов web отладчиком — то там можно увидеть строку Server:Occamus /nix
Просто баг проявился под виндой — и под виндой его искали. Потому как бага не должно быть нигде. Web cервер предназначен для работы и по виндой.
По по воду атак- сценариев я могу придумать множество. Просто в статье обсуждался самый простой способ. Те же соединения можно по разному открывать. Например недавно читал что в ngnix нету защиты от медленных соединений. Или наоборот только подвезли такую защиту? Не помню уже. Короче можно качать данные со скорость байт в секунду. Этот сценарий я могу в своём велосипеде реализовать за минуты.
Например в тестируемом сервере такая защита стоит.
В сервере есть динамический массив клиентов. И время жизни клиентов зависит от текущего их количества. Параметр настраивается. При приближении к этому числу время уменьшается. При достижении предела — время жизни сокета — один ответ. Это своеобразная защита от множественных мёртвых подключений.
Пока писался сервер. А ещё полностью собственный TLS стек — насмотрелся вдоль и поперёк. Месяц не вылезал с Wireshark пока туже современную криптографию на эллиптических кривых делал. TLS — это такой сборщик дикого легаси, что ни один RFC — нормально не пояснялось как та же функция PFR работает.
Но я всегда готов к новым знаниям.
Разумеется наверняка есть много полезных утилит для тестирования. Но их надо искать, качать, изучать и настраивать для работы.
И что же делают эти утилиты. Ну скорее всего они делают http запросы. Мне было намного проще делать http запросы в своём велосипеде. Подобного рода программы на C# пишутся за минут 10-20.
Конечно мои доводы могут быть совершенно неверны. Но я по крайней мере привожу их. За использования сторонних утилит — я доводов пока не видел. Вернее они есть — но мои доводы, ИМХО, перевешивают. Разумеется я буду рад услышать про киллер-фичу, которую будет сложно либо лениво реализовывать у себя, и я перейду на стороннюю утилиту.
По поводу Windows — думаю тут больше религиозная точка спора, чем факты ) И дабы сгладить ситуацию скажу — что сам сервер также скомпилирован и под linux и стоит на ubuntu server. И там тоже тестировался. linkin.link висит на на ubuntu server. Если посмотреть шапку ответов web отладчиком — то там можно увидеть строку Server:Occamus /nix
Просто баг проявился под виндой — и под виндой его искали. Потому как бага не должно быть нигде. Web cервер предназначен для работы и по виндой.
По по воду атак- сценариев я могу придумать множество. Просто в статье обсуждался самый простой способ. Те же соединения можно по разному открывать. Например недавно читал что в ngnix нету защиты от медленных соединений. Или наоборот только подвезли такую защиту? Не помню уже. Короче можно качать данные со скорость байт в секунду. Этот сценарий я могу в своём велосипеде реализовать за минуты.
Например в тестируемом сервере такая защита стоит.
И есть несколько вариантов http флуда: забивать его сокетами
В сервере есть динамический массив клиентов. И время жизни клиентов зависит от текущего их количества. Параметр настраивается. При приближении к этому числу время уменьшается. При достижении предела — время жизни сокета — один ответ. Это своеобразная защита от множественных мёртвых подключений.
Советую присмотреться к софта ntopng чтобы понимать как работают подключения, и ведёт себя трафик.
Пока писался сервер. А ещё полностью собственный TLS стек — насмотрелся вдоль и поперёк. Месяц не вылезал с Wireshark пока туже современную криптографию на эллиптических кривых делал. TLS — это такой сборщик дикого легаси, что ни один RFC — нормально не пояснялось как та же функция PFR работает.
Но я всегда готов к новым знаниям.
Просто баг проявился под виндой — и под виндой его искали. Потому как бага не должно быть нигде. Web cервер предназначен для работы и по виндой.
Но под linux тоже этот баг был зашит в код, получается. А в linux было бы намного проще продиагностировать сетевой стек.
Вообще, не очень понимаю, зачем в принципе запускать сервер на Windows, тем более на десктопной версии. Но прочитал с интересном, узнал даже что-то новое, хоть эти вещи из мира Win мне не актуальны, статью плюсанул, хоть и мало картинок :)
Тестируя нагрузки на веб-приложения ( последней была CRM система ). Случилось это полгода назад когда вернулся на своё место работы в офис (у компании 2 отдела CRM и ещё один SaaS).
Под наблюдением нескольких программистов — на их глазах просто падает все что стоит. В соседнем офисе в котором был call-центр — полностью затих.
В качестве балансировки нагрузки у них выступал nginx (он так же мешал делать ≥2 запросов в сек.) проксировал десяток размещенных node.js
Проводил испытания с нескольких выделенных железяк размещенных в EU.
Железо моё стояло под Linux (Debain), то что я использовал были: RavenStorm, hping3 (использовал до 90% ресурсов моих серверов для флуда).
Так же стоит не опускать Apache JMeter, это пожалуй будет отличное решение для тестов своих приложений.
ntopng можно наблюдать любую картину связанную с трафиком на Linux сервере.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я решил протестировать нагрузочную способность web сервера