Alexander Perlamutrov
Возможно, он питонист (но точно не Маяковский).
Вы прямо образцовый работодатель. Большинство моих работодателей дико бесились, когда я им моментально в слэке не отвечал. Хотя я им много раз объяснял, что мне тяжело концентрироваться на больших задачах, когда я постоянно отвлекаюсь. Они соглашались, но потом опять забывали об этом и начинали мне предъявлять за долгие ответы. Доходило до смешного, что они торговались и просили ставить реакцию, что я прочитал, а отвечать позже.
Возможно, с сервера турбо-страницы и загружаются моментально, но на моём не самом старом mi9 эта турбо-страница дико тормозит при скролле. У меня уже рефлекс выработался искать и кликать ссылку на оригинальный сайт (чаще всего википедия).
Нет, я из настоящего. Разработчики намеренно отказались тащить раздачу статики в ядро. Раздавать статику можно через фильтр. https://github.com/envoyproxy/envoy/issues/378
Всё-таки современный веб уже не только про статический контент. Да, для раздачи статики можно по-прежнему использовать nginx, как швейцарский нож, или более специализированные на статике инструменты типа varnish или squid. Но в плане работы с бэкендами envoy умеет гораздо больше (grpc, http/2, http/3, jwt, динамическая конфигурация, сбор метрик и т.д.), чем nginx, который здесь в роли догоняющего.
Вы оба застряли в прошлом. Envoy - веб-сервер нового поколения. Nginx уже безнадёжно устарел, хотя для того, чтобы захостить домашнюю страничку — до сих пор самое простое решение.
Он так и сказал: "На Болт" %)
Вообще нигде.
У меня нет никакой регистрации вообще, ни постоянной, ни временной.
У меня нет прописки вообще, но я зарегистрировался в Москве, просто по месту жительства. ИП зарегистрировать в таких условиях нельзя было.
Его не просто полно, его уже тоже в России штампуют: https://style.rbc.ru/impressions/5bbb83729a79471838860b73.
Хотя всего лишь 10 лет назад я заказывал производство в Италии.
Для таких случаев нужна версия с динамо-машиной — покрутил двое суток педали и добрался домой %)
В истории с ботами (как и с любыми источниками уведомлений) самое главное — слать только нотификации, на которые реально нужно реагировать, и чтобы был ответственный за каждый тип нотификаций, который (которые) бы успевал "прожевать" весь объём событий. Иначе будет полный хаос, когда люди просто начнут игнорировать все эти сообщения от ботов.
Турецкая лира в русском языке женского рода, поэтому:
- если число оканчивается на 1, то "турецкая лира";
- если на 2-4 — "турецких лиры";
- если последняя цифра > 5 или 0 — "турецких лир";
- 11-14 — это исключения, которые всегда "турецких лир".
У Gitlab было очень много крупных пользователей и до покупки Github'а Microsoft'ом. У них было несколько ключевых преимуществ:
- возможность поднятия на своём железе как платной EE-версии, так и бесплатной CE;
- более полная экосистема за счёт Gitlab CI.
Например, в Mail.ru начали массово использовать Gitlab году в 2013-14.
4 для веб-сервиса - это безопасно, но не оптимально. Хотя, например, если у вас там есть эндпоинт для загрузки и кропа аватарок, то уже не так безопасно. Если у вас есть монолитное веб-приложение, где один запрос обрабатывается 1мс, а другой - 10с (например, генерация какого-нибудь дикого отчёта в админке с кучей запросов в бд) и блокирует воркер целиком, то платформа с неблокирующим IO очень подходит. И это точно не 1% серверных систем.
Вы уж определитесь, то у вас сервер занят на 1%, то он приляжет под нагрузкой ))
Если вы сделаете 1 ядро -> 1 воркер, то будет загружен на 1% на сервисах с хождением в бд и внешние апи. Если сделаете 1 ядро -> 100 воркеров, то приляжет. Хорошее количество воркеров где-то посередине, но вам нужно его найти экспериментально на вашей кодовой базе. И оно может меняться вместе с профилем нагрузки.
И? Нету никакого ограничения, что число параллельных запросов не может быть больше числа ядер, как вы утверждали.
В однопоточных блокирующих системах количество параллельно обрабатываемых запросов равно количеству процессов-воркеров. Если вы наплодите этих процессов сильно больше, чем у вас ядер на сервере, то он приляжет под нагрузкой, потому что процессы будут "драться" за процессор. Грубо говоря, сервер попытается одновременно обработать больше запросов, чем он физически способен. Вместо того, чтобы выстроить их в очередь перед сервером и попробовать обработать частями. Поэтому ограничение на количество воркеров нужно. И подбирать его нужно под вашу конкретную нагрузку, а не исходя из чьих-то формул. Например, для сервисов, которые занимаются только вычислениями, типа обработки видео, для лучшей производительности нужно иметь строго 1 процесс на ядро. Если же у вас веб-сервис, который ходит в бд или внешние api, то можно приподнять количество процессов выше количества ядер. Но это вам придётся всегда делать вручную. Мониторить нагрузку, править конфиги. Системы с неблокирующим IO получаются практически самобалансируемыми. Единственное, что для них нужно мониторить - это потребление CPU, если оно приближается к 100%, то нужно срочно добавлять новый сервер в ваш кластер.
Вот это уже больше похоже на правду. Но если вы хотите обрабатывать >1k RPS с _одного_ ядра, то не хватит.
Просто если задрать количество процессов, ориентируясь на объём памяти, как предлагается в первой статье, то эти процессы под нагрузкой начнут "драться" за процессорное время, будет огромное количество переключений контекста, и в итоге производительность процессора деградирует https://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B5%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%BA%D1%81%D1%82%D0%B0
Вот хороший сайт, с которого можно начать: https://nodejs.dev/
Если вы ищете крутой веб-фреймворк на Node.js, то посмотрите на Nest.js или Meteor.js. Я люблю простые вещи, потому что их проще поддерживать, поэтому мой выбор это Koa.js (современный аналог Express.js)
У меня на линуксе так же и для PHP нужно написать apt-get install php-mysqli. И я тоже не понимаю, в чём разница между mysqli и mysql, пока специально это не загуглю.
Слухи о мусорности npm, конечно, не на пустом месте появились, как и то, что js-разработчики оценивают либы по количеству звёздочек на гитхабе %) Но гугл и здесь помогает, nodejs mysql даёт релевантный ответ на первом месте.
Ну смотрите, у вас есть, например, PHP-FPM с ограниченным max_children, вы его выставили, например, в 8 по количеству ядер процессора (больше ставить опасно, если не понимаете почему, могу объяснить отдельно). К вам пришли 100 одновременных запросов. В рамках обработки каждого запроса в отправляете запрос к серверу баз данных, который выполняется, например, 100мс. Получается, что 8 процессов-воркеров ждут 100мс, обрабатывая 8 входящих запросов, а остальные 92 попадают в очередь. Все эти 100мс у вас загрузка сервера 0%. Если предположить, что парсинг запроса и сериализация ответа занимают 1мс, то получается, что у вас процессор реально был загружен только 1мс из 100, то есть ~1%.
И что за "проект" в Node.js, который нужно обязательно создать? %)
Процесс в простое, конечно же, не занимает ресурсов, но и не обрабатывает входящие запросы. В итоге на выходе вы получаете загруженный на 1% многопроцессорный сервер, который может обработать параллельных запросов не больше, чем у него ядер. Запросы накапливаются в очереди, время ответа растёт, часть запросов начинает отваливаться по таймауту.
Кэшом можно решить очень ограниченный спект задач, когда у вас данные меняются очень редко и строго централизованнно. В противном случае, инвалидация кэша усложнит вашу архитектуру гораздо сильнее.
Прелесть Node.js как раз в том, что не нужно усложнять архитектуру, не нужно изучать дополнительные фреймворки и библиотеки, разаработчики Node.js уже всё сделали за вас. Вы можете писать в "синхронном" стиле, просто добавляя слово await перед сетевыми запросами. Всё.
Статья описывает старое доброе распараллеливание обработки через форк процессов. Это то, как работает PHP-FPM. Использование неблокирующего IO - это немного другая парадигма. Физически вы по-прежнему остаётесь однопоточным, никаких параллельных действий не осуществляется. Просто все операции с сетью или файловой системой перестают быть блокирующими, позволяя вам вместо ожидания занимать CPU полезной работой. То есть это просто более качественный способ утилизации процессорного времени ваших серверов.
А запросы к серверу баз данных вы не считаете? В ваших сервисах вы большую часть времени ответа делаете вычисления или ждёте ответа от базы данных?
Ну и как, много проектов вы сделали на reactphp или swoole? А прелесть Node.js в том, что даже начинающий разработчик сделает свой сервис более производительным "из коробки". И для этого не нужно осваивать дополнительные фреймворки/библиотеки или изучать синтаксис го-рутин. Вот и вся разница.
Хорошо, не 200, а 5. Разница в подходах останется прежней.
Я имел в виду, что у питонистов без отступов код не работает вообще, поэтому они их даже в обычном тексте не забывают ставить. Сорян, что объясняю шутку %)