Pull to refresh
0
0
Send message

Был у меня опыт работы с одной системой. Она в синхронном режиме обслуживала HTTP-запросы. Так вот, наступает час X. По трафику всё в норме, по CPU всё в норме, количество запросов тоже не так чтобы большое. Растёт только количество потоков в пуле jetty, но они, при этом, ничем особо не заняты. А система встаёт колом.

Логичный вопрос от руководства: "как так?" ОК, садишься, поднимаешь логи, пишешь скрипт, который интегрирует время обслуживания каждого запроса по HTTP с заданным интервалом (например, 5 минут). Строишь график и наблюдаешь, как значения на полученных временных интервалах растут по экспоненте начиная с определённого количества запросов в минуту.

А причина, как выясняется позже, вполне банальная: jetty-пул обслуживает не только внешние запросы, но и внутренние RPC-запросы, из-за чего возникает так называемый "лавинный эффект", когда внешний запрос триггерит цепочку RPC-запросов и, в итоге, эта цепочка заворачивается в кольцо.

Учитывая то, что jetty-пул потоков не бесконечный, система встаёт в ожидание освобождения потока, а все потоки в пуле при этом находятся в ожидании ответа по RPC, т.е. возникает своеобразный логический дедлок по ограниченному ресурсу - потокам.

Ошибка в проектировании и реализации? Однозначно. Но обнаружить такое с обычным мониторингом RPS невозможно.

Так что пока вы не имеете хотя бы приближённого числа в часозанятиях, есть риск вот так же наколоться.

Опять эти мифические RPS для измерения нагрузки...

5 млн RPS с обслуживанием в 10 микросекунд на запрос и те же 5 млн RPS с обслуживанием по минуте на запрос - это совершенно разная нагрузка, отличающаяся на порядки.

Нагрузку мерят либо в часозанятиях, либо в эрлангах.

Статья весьма безграмотная, примеры и аналогии притянуты за уши.
Видимо, автор сам пороха не нюхал на ассемблере под обе сравниваемые архитектуры толком и не программировал. Всё отличие RISC от CISC можно пояснить двумя отдельными пунктами:


  1. Длина команды: у CISC она переменная, у RISC — постоянная. Это отчасти верно, но есть особенности, т.к. у тех же ARM и RISC-V есть возможность исполнять сокращённые в два раза по длине команды для увеличения плотности кода.
  2. Наличие отдельных выделенных команд пересылки данных между памятью и регистрами в RISC, в то время как в CISC команды могут в качестве операнда использовать ячейку памяти.

То, что в RISC какой-то убогий набор инструкций — уже давно миф и результат неправильного перевода самой аббревиатуры RISC на русский язык. В современных ARM и MIPS даже SIMD есть (который, к слову, местами попродвинутее SSE и AVX будет), который сейчас является одним из ключевых способов оптимизации производительности обработки данных.

Я в таких тонкостях (подгрузка) не смыслю, но, однозначно, такая реализация явно попахивает очередным костылём.

<source media="(orientation: portrait)" srcset="port-small-car-image.jpg 700w, port-medium-car-image.jpg 1200w, port-large-car-image.jpg 1600w" sizes="(min-width: 768px) 700px, (min-width: 1024px) 600px, 500px">

Вот тут у меня глаза вытекли. Сделать нормальное DOM-дерево? Нет, давайте запихаем списки в srcset и sizes. Отличное решение, нечего сказать. Как хочу, так и ворочу.

В самом лайвкодинге ничего плохого нет. Он ставит целью проверить соображалку разработчика и умение родить какой-то алгоритм.
Когда я проводил собеседования, то просил разработчка изобразить какой-нибудь простой алгоритм на целевом языке на доске. Сразу с оговорками, что всякие синтаксические ошибки если и будут — то не страшно. Из задач предлагалось обычно перевернуть строчку задом наперёд или поменять порядок бит в числе на обратный. Требовать парсер выражений писать бессмысленно. Так вот, далеко не все Senior'ы даже с такими задачами справлялись (что, в первую очередь, говорит о качестве рынка разработчиков в целом).

Но если к вам приходят чуваки и говорят работать строго в одной парадигме (TDD), то от них надо бежать сломя голову. И есть серьёзные сомнения, что с архитектурой их проекта тоже не всё в порядке, и там костыль на костыле, но зато тесты работают.

Извините меня за грубость, конечно, но это онанизм.
Это сроде малолеткам, которые только начали осваивать язык, и пытаются всячески выпендриться перед своими сверстниками, заявляя: "А смотрите, как Я МОГУ!"


  • Конечные автоматы?


  • Не, не слышали!


  • Плодим новые сущности без сильной надобности?


  • Ну и фиг с ним!


  • Код будет выполняться медленнее?


  • Да кого это заботит!


  • Отладка всего этого дела превращается в ад?


  • Да ты просто вот эту крутую IDE не осилил, кекеке!



Отвратительно до боли.

Ещё один конкретный пример того, что оптимизаторы SQL-запросов в СУБД промышленного уровня всё равно тупые. Сколько я намучался в своё время с оптимизатором Oracle, который очень своевольничал, — это не перечесть.
Иными словами: если вы не понимаете структуру ваших данных, то и работа с ними будет далеко неоптимальной.

>А с Linux… Постоянно сталкиваюсь с проблемами подключения
То есть то, что производители клепают дрова для своих поделий только под Win/Mac, не учитываем, ок. В остальном же, если Wifi на поддерживаемом чипе, проблем не возникнет. Уважающие себя производители принтеров также предоставляют драйверы для Linux. Конкретный пример — HP, Kyocera.

>Плюс слабый GUI в Linux
Не знаю, какие вообще могут быть претензии по GUI к системе, которая изначально разрабатывалась как CLI. Большую часть работы можно сделать из консоли, если это только не какая-нибудь графика/мультимедиа. KDE так вообще практически не вызывает нареканий. Разве что четвёртая версия в плане оформления получше пятой была (на мой взгляд). Запустить приложения, рассовать их по рабочим столам и пользоваться — что ещё нужно? Больше свистелок и перделок? Как говорится, вам шашечки или ехать?

Кстати говоря, после продолжительного промежутка времени непользования Win появилась возможность пощупать Win 7, Win 8.1 и Win 10. Вы вообще как этим пользуетесь??? Что там удобного-то?
>А какая разница где именно проблема?
Ну, то есть, когда проблема за Windows, вы предпочитаете терпеть и молчать. А когда, как вам кажется, проблема с Linux, вы сразу почему-то начинаете про «шаманство» какое-то. Какое-то непоследовательное и необъективное у вас отношение к делу.

>Нам ж ради удобства работы, а не ради оснований для аргументации это надо.
Если не говорить по какой-то дико проприетарный софт, под Linux всё, что нужно, есть для разработки, и даже более.

>Я вот как-то не готов сидеть на системе, с которой нужно бороться, только ради того, чтобы сказать «зато у меня круто кастомизированная вещь, да, я на её настройку потратил несколько дней, зато теперь я не как все»

Не знаю, где вы там боретесь. Один раз поставил, настроил и забыл на года. А учитывая то, что сейчас куча user-friendly дистрибутивов расплодилось, вся настройка сводится к подключению нужных репозиториев с ПО, его установке и минимальной настройке.

Совсем не хотите мучаться с настройкой в консоли — ставьте openSUSE и пользуйте YaST.

Ну так вы своим комментарием, как раз, подтверждаете, что проблема в системе, которая запускает сервер GDB — то есть, Windows.

Конкретные недостатки HTTP, применительно к версии 1.x:
— дикий оверхед по заголовкам и телу сообщения — неэффективное использование трафика;
— отуствие конвейеризации запросов: вы не можете по одному и тому же сокету отправить запросы 1 и 2 на сервер, а ответы получить в обратном порядке — сначала на 2, а потом на 1. Иными словами, сетевой сокет простаивает, когда мог бы заниматься полезной работой.
— На практике редко кто поддерживает персистентные соединения, отсюда имеем оверхед по времени на установление TCP-соединения (TCP handshake) и, если используется SSL, то ещё и на SSL handshake.

Да и, в принципе, всё тот же самый обмен сообщениями можно организовать напрямую через TCP-сокет, без привлечения протокола прикладного уровня, коим является HTTP.

Об rpc ещё писали в незнамо каких лохматых годах.


С самого начала создания первой сети, Святым Граалем сетевых вычислений было предоставления программных интерфейсов для доступа к удалённым сетевым ресурсам таким же образом, как к локальным. Сеть становится "прозрачной".
Один пример прозрачности сети — знаменитый RPC (удалённый вызов процедур, remote procedure call), система разработанная для того, чтобы вы могли вызывать процедуры (подпрограммы), выполняющиеся на другом компьютере, по сети точно так же, как если бы они выполнялись локально. На это угробили чёртову пропасть энергии.
Звучит логично, правильно?
Неправильно.
Заключение: В следующий раз, когда кто-то попытается продать вам программный продукт, который позволяет вам обращаться к сетевым ресурсам также как к локальным, убегайте как только можете в противоположном направлении.

RPC поверх HTTP — ещё большее зло, которое, в принципе, могло придумать человечество.
Но практика показывает, что плохие вещи почему-то набирают бОльшую популярность, чем хорошие.

Ещё одна статья уровня "Я нашёл библиотеку, которая делает всю работу за меня" вместо того, чтобы разобраться в реальных принципах работы с ASIO напрямую и на примерах их доходчиво здесь изложить. Заголовок не соответствует содержанию.

Information

Rating
Does not participate
Registered
Activity