Load для гиков

Согласен. И был против такого подхода. Но таково было решение руководства.

Load для гиков

К плотности логотипов, имен, продуктов и вообще сущностей в современном мире. Давно придумывали незанятый логин в популярных сервисах?

Если это намек на связь со Сбером - то да, связь есть. Я плачу ЖКХ через Сбер каждый месяц :)

Простое должно быть простым: «Легкий» Load Testing

Трафик сценарии - отличная штука, согласен.

Про сотни тысяч сессий - вопрос сложнее:

• Сессия это 1 конкурентное соединение со своим "потоком выполнения запросов" или несколько?

• Мы говорим об очереди запросов без пауз или с ними?

Простое должно быть простым: «Легкий» Load Testing

Понятно, спасибо, что поделились опытом!

Простое должно быть простым: «Легкий» Load Testing

Не уверен, что подключение чего-то со стороны всегда хорошо для LT.

То что входит в сам инструмент - хоть как то проверяется на адекватность сгенерированных метрик\отчетов и т.д. Чего нельзя сказать о произвольных либах со стороны, как бы удобны они не были. Взять как минимум пулы коннекшенов в подключаемых либах. Что о них знает локуст или любой другой инструмент? И, как результат, как можно корректно учитывать неизвестное поведение библиотек в отчетах?

Все же LT это не "обычная библиотека". Это измерительный инструмент.

Чего не хватает из штатного, что понадобилось подключать?

Простое должно быть простым: «Легкий» Load Testing

Если не затруднит, приведите пример раскрывающий простоту locust: скрипт на locust vs скрипт на k6.

Простое должно быть простым: «Легкий» Load Testing

Подробно его не рассматривал, но после беглого знакомства, он показался немного похожим на k6. Рискую ошибиться, но похоже синтаксис несколько избыточен.

Похоже, есть докер образ, значит можно просто взять и запустить. Вопросов нет, молодцы. Но почему в топике про инсталляцию этого варианта нет - загадка. Чтобы не было слишком просто? Хотя это опять про пальцы :)

Они рекламируют "Миллионы юзеров" на главной странице. Но в справке тут же сокрушаются про ограничения питона на использование ядер. Что заставляет вас запускать несколько процессов и т.д. Лукавство детектед.

Дальше пишут "Практически нет ограничений на количество пользователей", но добавляют "если они достаточно медленные". Это было бы вполне корректно, если бы не громкая фраза про "миллионы".

Остальное нужно изучать подробнее. К сожалению, пока нет возможности этим заняться.

Простое должно быть простым: «Легкий» Load Testing

Отчасти с вами согласен.

Но каждый не высосанный палец из подобной незначительной проблемы, убеждает соответствующих разработчиков в том, что это вообще не проблема и все больше побуждает их оставлять подобные шероховатости в своих продуктах.

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

Думаю, что перевес однозначно на стороне пользователей.

Простое должно быть простым: Палки в разметку

Странно, но пока за Grid голосов нет. Вообще.

Спор в комментариях был ради спора?

Простое должно быть простым: Палки в разметку

Вижу два посыла в вашем ответе:

1. Grid мощнее: Я не против грида в принципе. При необходимости можно использовать его. Что считаю неудобным - централизованная "карта" сразу всей разметки в нем. Но это холиварный вопрос, понимаю.

2. Grid привычнее: А вот здесь очень интересно. В свое время Grid был "непривычной новинкой" и т.д. Попробуйте отнестись к этой статье, не как к руководству к действию, а как обозначению проблемы и некоторым идеям, которые можно использовать как угодно.

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

Простое должно быть простым: Палки в разметку

Вариант @kotan-11 понят мной именно так, как вы его описываете. Только как раз ваша интерпретация предложенного мной подхода неверна (возможно из-за моих недостаточных литературных способностей).

Я предлагаю централизованную карту разметки распределить по функциональным блокам, расположенным по месту. Компоненты, размещаемые в этих блоках действительно не знают о соседях. Но блоки - знают. И только они определяют положение дочерних компонентов. В примерах из статьи, "компоненты" вырождены в простой текст и стиль блока. Также, при необходимости, можно в одном блоке на любом уровне вложенности разместить любое количество любых компонентов\блоков, которые не будут знать о своем местоположении ничего, но тем не менее выстроятся нужным образом. И, меняя свойства контейнера, можно перестраивать расположение дочерних компонентов, которые ничего по прежнему не знают друг о друге.

Во пример "компонентов" не знающих о соседях и не определяющих своего положения, но выстраивающихся так, как это задает их контейнер. Здесь, меняя свойства контейнера (col, gap, xAlign), можно изменять положение дочерних блоков.

<Box col gap expand>
    <Box gap hAlign = {Align.Start}>
        <div className = 'bar'>Component</div>
        <div className = 'bar'>Component</div>
        <div className = 'bar'>Component</div>
    </Box>

    <Box gap>
        <div className = 'action'>Component</div>
        <div className = 'action'>Component</div>
        <div className = 'action'>Component</div>
        <div className = 'action'>Component</div>
    </Box>

    <Box gap hAlign = {Align.End}>
        <div className = 'panel'>Component</div>
        <div className = 'panel'>Component</div>
    </Box>
</Box>

Вот пример динамически перестраиваемой разметки с компонентом Box (попробуйте изменять ширину окна браузера) :

https://geekload.io/downloads

А вообще мы, как это обычно бывает, "соскользнули" с главной темы.

Суть вообще не в противостоянии Grid vs Flex или "карта" vs "по месту". Речь про короткий внятный элегантный синтаксис разметки, логику которого не нужно вспоминать. Причем, что важно, именно во взаимодействии нескольких аспектов (flex\вложенность + overflow) или любых других.

Простое должно быть простым: Палки в разметку

Напишу здесь мой любимый принцип полностью, он и будет ответом: "Простое должно быть простым, а сложное - возможным".

Простое должно быть простым: Палки в разметку

Боюсь вы не прочитали статью полностью, либо мне не удалось донести свою мысль правильно. Если даже для простых ситуаций, необходимо "богатство синтаксиса", то это считаю недостатком.

Непонятен тезис про количество div+grid. Думаю, привязываться нужно не к количеству элементов ввода, а к количеству функциональных зон. При этом не вижу никакого криминала в том, чтобы обернуть каждую зону одним div (если мы говорим о чистом html\css). В рамка одной функциональной зоны, лишних div не будет.

Также, вы слишком буквально понимаете слово "сложность". Речь о избыточном синтаксисе и т.д. Проблем осознать приведенные синтаксические конструкции нет.

Простое должно быть простым: Палки в разметку

Про 2D тоже понятно. Но я исхожу из того, что 2D = 1D + 1D. И каждое измерение\уровень блоков живет своей жизнью и может быть перемещено без изменения остального кода.

Простое должно быть простым: Палки в разметку

Да, я об этом тоже дописал в конце статьи.

В данном случае, этот стиль только пример множества других стилей и ситуаций, которые на мой взгляд нарушают принцип "Простое должно быть простым".

Простое должно быть простым: Палки в разметку

Заметьте, вы сводите решение к частному случаю, в котором возможно "упростить grid", но беда частных случаев в том, что их нужно помнить. В статье же, я пытался показать универсальный способ построения разметки. В котором для достижения результата делается одно и то же, независимо от уровня вложенности блоков и т.д.

Т.е. например Карандаш - он всегда рисует, независимо от того круг или квадрат. А когда нужно нарисовать треугольник, вы смело берете карандаш и рисуете, не вспоминая, в каком окружении его нужно нарисовать и т.д.

Мой пример использования grid был сделан намеренно общим, без "оптимизаций для частного случая", так как они сложнее в запоминании и т.д.

Но, разумеется, удобнее использовать фасад (вроде показанного Box), который "сделает все красиво" и будет столь же простым, как и оптимизированная частная реализация, вроде показанной вами.

И первая строка слегка выбивается из понятия "просто" :)

Простое должно быть простым: Палки в разметку

Логика проста для человека, который регулярно занимается разметкой.

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

И я не спорю, с вашим объяснением особенностей overflow :)

Простое должно быть простым: Палки в разметку

Спасибо за пояснение логики, которая от ясности не становится простой.

Мне как пользователю не понятно, почему просто указания "сделай это прокручиваемой областью" недостаточно.

Еще раз: об этом как раз и статья: простое должно быть простым. Если нужно, для достижения этого можно и нужно реализовать единожды некий фасад над "магией" или "ясной но избыточной логикой".

Простое должно быть простым: Палки в разметку

Спасибо за идею. Ответил дополнением в конце статьи.

Простое должно быть простым: Палки в разметку

Отвечу вам и kotan-11 в самой статье в виде дополнения. Вижу некое недопонимание.