Создаем простое веб приложение при помощи node.js

Мониторинг Node.js-приложения

Здравствуйте! Меня зовут Ренат Саматов, я возглавляю фронтенд-направление в линейке продуктов Витрина. Большая часть наших проектов рендерится на сервере. Сегодня мы побеседуем об одном из важнейших аспектов SSR-приложения: о мониторинге.
Даже в 2020-м мониторинг Node.js-приложения является непростой задачей. Node.js — среда выполнения JavaScript, однопоточного языка программирования с динамической типизацией. Интерпретатору и среде исполнения предоставлены широкие полномочия, что очень легко может привести к утечке памяти или высокой нагрузке на процессор. Node.js работает асинхронно (псевдопараллельно), однако если одна функция блокирует поток или очередь событий, производительность приложения начинает сильно проседать.
В этой статье я расскажу о том, как контролировать ваше Node.js-приложение и быть уверенным в том, что проблем с утечкой памяти, ресурсов процессора и блокировкой потока не возникает

Мы побеседуем об управлении производительностью приложения (Application Performance Management, APM) и метриках, на которые следует обращать внимание. Погнали!

Лёгкое программирование: канбан-доска для GitLab за один рабочий день

В жизни начинающего тимлида рано или поздно настаёт момент, когда он понимает, что его команде нужна канбан-доска. Она снимает беспокойство по поводу контроля процесса разработки и даёт уверенность в завтрашнем дне. Обычно эта проблема решается нижайшей просьбой к завхозу купить магнитную доску, набор разноцветных стикеров и пару-тройку маркеров для доски. Ну или использованием сервисов вроде Jira. Но в нашей команде один разработчик на удалёнке, а гитлаб в закрытом контуре (недоступен из интернетов по соображениям информационной безопасности), поэтому выбирать пришлось наиболее простое из двух возможных решений:
а) создание механической руки и контроллера к ней, который позволит удалённо переклеивать стикеры на доске, при этом, чтобы не усложнять решение, писать на стикерах нам придётся за нашего недосягаемого коллегу, что несправедливо;
б) реализация программной канбан-доски, которая собирала бы все задачи с нашего гитлаба.
Конечно, душа лежала к ламповой физической доске. Я даже начал размышлять об использовании DualShock 4 в качестве контроллера механической руки, но я сам себе обозначил дедлайн утром следующего дня, поэтому пришлось обойтись бездушным программным решением.

Размышления о стандартной библиотеке JavaScript. Core.js

К чему это я? Занятная штука — JavaScript. Основа современного web и на фронтэнде альтернатив как таковых не имеет.
JavaScript это, в том числе, и стандартная библиотека, о которой здесь и пойдёт речь. Под стандартной библиотекой я подразумеваю модули, конструкторы, методы, что должны присутствовать на любой платформе, будь то браузер или сервер, без лишних действий со стороны программиста, не включая API, специфичный для платформы. Даже если вы пишите не на JavaScript, а на языке в него компилируемом, скорее всего, вам придется иметь дело с его стандартной библиотекой.
Ванильная стандартная библиотека JavaScript, в целом, неплоха. Это не только стандартная библиотека по спецификации языка ECMA-262 актуальных версий — от 3 до черновика 6. Часть API вынесена в отдельные спецификации, например, API интернационализации ECMA-402. Многие возможности, без которых сложно представить JavaScript, например, , относятся к web-стандартам. Консоль не стандартизована вовсе — приходится полагаться на стандарт де-факто.
Вот только не такая уж она и стандартная — везде разная. Есть старые IE, в которых из коробки мы получаем стандартную библиотеку ES3 90-бородатого года даже без и консоли, и есть, например, Node.js, на которой многие уже вовсю используют возможности грядущего ES6.
Хочется иметь универсальную, действительно стандартную библиотеку, как на сервере, так и в любом браузере, максимально соответствующую современным стандартам, а также реализующую необходимый функционал, что (пока?) не стандартизован. Статья посвящена библиотеке core.js — реализация моих соображений по поводу стандартной библиотеки JavaScript. Кроме того, эта статья еще и шпаргалка по современной стандартизованной стандартной библиотеке JavaScript и заметки о её перспективах.

Как исправить ошибку в Node.js и нечаянно поднять производительность в 2 раза

Началось все с того, что я оптимизировал отдачу ошибки в сервере приложений Impress, работающем на Node.js. Как известно, у нодовского есть событие timeout, которое должно вызываться для каждого открытого сокета, если тот не закрылся за указанное время. Хочу уточнить, что не для каждого запроса т.е. не для каждого события request, функция которого имеет два аргумента (req, res), а именно для каждого сокета. Через один сокет может последовательно поступить много запросов в режиме . Если мы задаем это событие, через server.setTimeout(2 * 60 * 1000, function(socket) {…}) то должны сами уничтожать сокет socket.destroy(). Но если не установить свой обработчик, то http.Server имеет встроенный, который уничтожит сокет через 2 минуты автоматически. На этом самом таймауте можно отдать ошибку 408 и считать инцидент исчерпанным. Если бы не одно но… С удивлением я обнаружил, что событие timeout вызывается и для тех сокетов, которые подвисли и для уже получивших ответ и для закрытых клиентской стороной, вообще для всех, находящихся в режиме keep-alive. Это странное поведение оказалось достаточно сложным, и я расскажу об этом ниже. Можно было бы вставить одну проверку в событие timeout, но со своим идеализмом я не удержался и полез исправлять баг на уровень глубже. Оказалось, что в http.Server режим keep-alive реализован не то что не по RFC, а откровенно не дописан. Вместо отдельного timeout для соединения и отдельного keep-alive timeout, там все на одном таймауте, который реализован на быстрых псевдо-таймерах (enroll/unenroll), но задан по умолчанию в 2 минуты. Это было бы не так страшно, если бы браузеры хорошо работали с keep-alive и переиспользовали его эффективно или закрывали бы неиспользуемые соединения.

Основная концепция

Начиная продумывать архитектуру я задал себе вопрос: «Что делает сервер?». На самом высоком уровне абстракции сервер делает три вещи:

• получает запросы
• обрабатывает запросы
• отдает ответы

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

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

Гипертекстовый векторный Фидонет

22 ноября 2005 года Михаил Тулупов (2:5020/2015.39), обращаясь ко мне в эхоконференции Ru.Fidonet.Today по поводу моих замыслов гипертекстового Фидонета, так присоветовал:И действительно, принятый в Фидонете в ту пору обычай использовать псевдографику требовал заметно больше траффика под свои нужды, чем SVG. Вот почему с тех пор я считаю, что в идеале Фидонету необходимо быть не только гипертекстовым, но также и векторным — о чём я с тех пор сообщал сперва во блогозаписи «Два идеала прозреваемых, но покамест не достигнутых», а затем и в других местах.Что такое гипертекстовый векторный Фидонет? — в узком смысле это возможность перейти в Фидонете к векторному файлу по URLу (то есть по стандартному адресу) этого файла, для чего URL придётся либо встретить в виде гиперссылки (и жмякнуть её мышóю), либо вбить в строку адреса в фидобраузере вручную. Откроется векторная картинка, размер которой можно будет произвольно менять вместе с размерами того окошка браузера, в котором рисунок содержится — то есть совершенно так же, как и в Интернете:
Перед вами — анимированный ряд скриншотов сегодняшней сборки моего фидобраузера, которому я дал название «PhiDo» (а точнее — «φ道»); как видите, сегодня (совершив 245 коммитов со дня прошлогоднего начала разработки исходного кода PhiDo) мне удалось вплотную приблизиться к вышеозначенному идеалу.

Цикл событий

Цикл событий — это магия, которая происходит внутри Node.js. Это буквально бесконечный цикл и на самом деле один поток.

Libuv — C библиотека которая реализует этот паттерн и является частью ядра Node.js. Вы можете узнать больше о libuv здесь.

Цикл событий имеет 6 фаз, каждое исполнение всех 6 фаз называют tick-ом.

• timers: в этой фазе выполняются коллбэки, запланированные методами и ;
• pending callbacks: выполняются почти все коллбэки, за исключением событий , таймеров и ;
• idle, prepare: используется только для внутренних целей;
• poll: ответственен за получение новых событий ввода/вывода. Node.js может блокироваться на этом этапе;
• check: коллбэки, вызванные методом , выполняються на этом этапе;
• close callbacks: например, ;

Хорошо, есть только один поток, и этот поток и есть цикл событий, но тогда кто выполняет все операции ввода/вывода?

Обратите внимание!!!Когда циклу событий нужно выполнить операцию ввода/вывода он использует поток ОС с тредпула (thread pool), а когда задача выполнена, коллбэк ставится в очередь во время фазы pending callbacks

Разве это не круто?

Проблема CPU-ёмких задач

Node.js кажется идеальным! Вы можете создавать всё, что захотите.

Давайте напишем API для вычислений простых чисел.

Простое число — это целое (натуральное) число больше единицы и делимое только на 1 и на само себя.

Дано число N, API должен вычислять и возвращать первые N простых чисел в список (или массив).

primes.js

index.js

это реализация нужных вычислений: функция проверяет является ли число простым, а nthPrime возвращает N таких чисел.

Файл же отвечает за создание сервера и использует модуль для обработки каждого запроса на . Число N прокидывается через строку запроса в URL-адресе.

Что бы получить первых 20 простых чисел нам нужно сделать запрос на .

Предположим, к нам стучатся 3 клиента и пытаются получить доступ к нашему не блокирующемуся вводом/выводом API:

• Первый запрашивает 5 простых чисел каждую секунду.
• Второй запрашивает 1000 простых чисел каждую секунду
• Третий запрашивает 10 000 000 000 простых чисел, но…

Когда третий клиент шлёт запрос — главный поток блокируется и это главный признак проблемы CPU-ёмких задач. Когда главный поток занят исполнением «тяжёлой» задачи он становится недоступен для других задач.

Но как насчёт libuv? Если Вы помните, эта библиотека помогает Node.js исполнять операции ввода/вывода с помощью потоков ОС избегая блокировки главного потока и Вы абсолютно правы, это решение нашей проблемы, но для того, что бы это стало возможным, наш модуль должен быть написан на языке C++, что бы libuv могла с ним работать.

К счастью, начиная с v10.5 в Node.js добавлен нативный модуль Worker Threads.

Обнаружение лиц в Node.js с использованием Rust и WebAssembly

Перевод

В последней статье мы рассказывали, как вызывать функции Rust из Node.js. Сегодня мы расскажем, как написать приложение AIaaS (англ. Artificial Intelligence as a Service — «искусственный интеллект как услуга») на базе Node.js.

Большинство приложений с искусственным интеллектом сейчас разрабатываются на языке Python, а главным языком программирования для веб-разработки является JavaScript. Для того чтобы реализовать возможности ИИ в вебе, нужно обернуть алгоритмы ИИ в JavaScript, а именно в Node.js.

Однако ни Python, ни JavaScript сами по себе не подходят для разработки ИИ-приложений с большим объемом вычислений. Это высокоуровневые, медленные языки со сложной средой выполнения, в которых удобство использования достигается за счет снижения производительности. Для решения этой проблемы блоки интеллектуальных вычислений в Python оборачиваются в нативные C/C++-модули. Точно так же можно сделать и в Node.js, но мы нашли решение получше — WebAssembly.

Виртуальные машины WebAssembly поддерживают тесную интеграцию с Node.js и другими средами выполнения JavaScript-кода. Они отличаются высокой производительностью, безопасны с точки зрения доступа к памяти, изначально защищены и совместимы с разными операционными системами. В нашем подходе сочетаются лучшие возможности WebAssembly и нативного кода.

Мир на ладони или как мы с помощью чат-бота оптимизируем рабочие процессы сотрудников

Из песочницы

Когда численность сотрудников в НСПК стала измеряться сотнями, а количество корпоративных систем, в которых они работают десятками, то взаимодействие с ними стало не всегда удобным, временные затраты на доступ к ним с рабочей машины начали превышать непосредственное время самой работы в них. А что, если сотрудник находится не на своем рабочем месте, но, скажем, срочно необходимо оформить гостевой пропуск для партнера компании? И это лишь один кейс из множества.

Привет, меня зовут Иван Фисунов. Я расскажу, как мы в компании успешно решили и продолжаем решать, задачи по оптимизации рабочего процесса сотрудников, а также делаем рутинные процессы удобнее, проще и даже чуточку веселее, а следовательно и эффективнее.

Многопоточный сервер

Веб-приложения, написанные следуя клиент/серверной архитектуре, работают по следующей схеме — клиент запрашивает нужный ресурс у сервера и сервер отправляет ресурс в ответ. В этой схеме сервер, ответив на запрос, прерывает соединение.

Такая модель эффективна поскольку каждый запрос к серверу потребляет ресурсы (память, процессорное время и т.д.). Для того чтобы обрабатывать каждый последующий запрос от клиента, сервер должен завершить обработку предыдущего.

Значит ли это, что сервер может обрабатывать только один запрос за раз? Не совсем! Когда сервер получает новый запрос он создаёт отдельный поток для его обработки.

Поток, если простыми словами, это время и ресурсы, что CPU выделаят на выполнение небольшого блока инструкций. С учётом сказанного, сервер может обрабатывать несколько запросов одновременно, но только по одному на поток. Такая модель так же называться thread-per-request model.

Для обработки N запросов серверу нужно N потоков. Если сервер получает N+1 запросов, тогда он должен ждать пока один из потоков не станет доступным.

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

Один из способов избавиться от ограничений — добавить больше ресурсов (памяти, ядер процессора и т. д.) на сервер, но это не самое лучшее решение….

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

Блокирующий ввод/вывод

Ограниченное число потоков на сервере не единственная проблема. Возможно, Вам стало интересно почему один поток не может обрабатывать несколько запросов одновременно? всё из-за блокирующих операций ввода/вывода.

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

Пользователь стучится на http://yourstore.com/products и сервер рендерит HTML файл со всеми продуктами с базы данных в ответ. Совсем не сложно, да?

Но, что же происходит за кулисами?

• Когда пользователь стучится на особый метод или функция должна выполниться, что бы обработать запрос. Маленький кусочек кода (Ваш или фреймворка) анализирует URL-адрес запроса и ищет подходящий метод или функцию. Поток работает.
• Теперь нужный метод или функция выполняется, так как и в первом пункте — поток работает.
• Так как Вы хороший разработчик, Вы сохраняете все системные логи в файл, ну и конечно же, что бы быть уверенными, что роутер выполняет нужный метод/функцию — Вы так же логируете строку “Method X executing!!». Но всё это блокирующие операции ввода/вывода. Поток ждёт.
• Все логи сохранены и следующие строки функции выполняются. Поток работает снова.
• Время обращаться к базе данных и получать все продукты — простой запрос, вроде , выполняет свою работу, но угадайте что? Да-да, это блокирующая операция ввода/вывода. Поток ждёт.
• Вы получили массив или список всех продуктов, но убедитесь, что Вы всё это залогировали. Поток ждёт.
• Теперь у Вас есть все продукты и пришло время рендерить шаблон для будущей страницы, но перед этим Вам нужно их прочитать. Поток ждёт.
• Движок рендеринга делает свою работу и шлёт ответ клиенту. Поток работает снова.
• Поток свободен, словно птица в небесах.

На сколько медленны операции ввода/вывода? Ну это зависит от конкретной. Давайте обратимся к таблице:

Операции сети и чтения с диска слишком медленные. Представьте сколько запросов или обращений к внешним API ваша система могла бы обработать за это время.

Подбивая итоги: операции ввода/вывода заставляют поток ждать и тратить ресурсы впустую.

ПОДГОТОВКА

Чтобы начать работу с Node.js, нужно, как минимум, установить Node.js.

Процедура несложная и не отнимет много времени. Используйте один из вариантов установки, предлагаемых на  Node.js.

Вместе с Node.js автоматически устанавливается менеджер пакетов npm.

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

В нашем примере мы будем использовать систему управления базами данных (СУБД) MongoDB. Так же как и в случае с Node.js, на  продукта есть подробная документация и инструкция по установке.

Для создания простого приложения нам понадобятся

• фреймворк для создания каркаса приложения (Express);
• драйвер для системы управления базами данных MongoDB;
• инструмент (пере-) запуска веб-сервера (nodemon).

Примечание:

Благодаря сервисной программе nodemon, сервер будет автоматически перезапускаться при каждом изменении кода.

Первое приложение на Node.js

Последнее обновление: 14.11.2018

Напишем первое простейшее приложение для NodeJS. Для создания приложений можно использовать практически все стандартные конструкции языка JavaScript.
Исключением является работа с DOM, так как приложение будет запускаться на сервере, а не в браузере, поэтому DOM и такие объекты как или
в данном случае нам будут недоступны.

Для этого вначале создадим для приложения каталог на жестком диске. К примеру, я создал каталог
C:\node\helloapp. В этом каталоге создадим файл app.js.

Определим в файле app.js следующий код:

const http = require("http");
http.createServer(function(request,response){
	
	response.end("Hello NodeJS!");
	
}).listen(3000, "127.0.0.1",function(){
	console.log("Сервер начал прослушивание запросов на порту 3000");
});

Вкратце разберем этот код.

На первой строке мы получаем модуль http, который необходим для создания сервера. Это встроенный модуль, и для его загрузки необходимо применить функцию :

const http = require("http");

Далее с помощью метода создается новый сервер для прослушивания входящих подключений и обработки запросов. В качестве параметра
этот метод принимает функцию, которая имеет два параметра. Первый параметр request хранит всю информацию о запросе, а второй параметр response используется
для отправки ответа. В данном случае ответ представляет простую строку «Hello NodeJS!» и отправляется с помощью метода .

Но метод только создает сервер. Чтобы сервер начал прослушивать входящие подключения у него надо вызвать метод :

.listen(3000, "127.0.0.1",function(){
	console.log("Сервер начал прослушивание запросов на порту 3000");
});

Этот метод принимает три параметра. Первый параметр указывает на локальный порт, по которому запускается сервер. Второй параметр указывает
на локальный адрес. То есть в данном случае сервер будет запускаться по адресу 127.0.0.1 или localhost на порту 3000.

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

Теперь запустим сервер. Для этого откроем терминал (в OS X или Linux) или командную строку (в Windows). С помощью команды cd
перейдем к каталогу приложения:

cd C:\node\helloapp

Затем вызовем следующую команду:

node app.js

Она запускает сервер:

Далее откроем браузер и введем в адресную стоку адрес http://localhost:3000/:

И нам отобразится то сообщение, которое было послано в методе .

НазадВперед

Чем хорош Node.js

Если вы начи­на­ли изу­чать про­грам­ми­ро­ва­ние, вам будет понят­на кон­цеп­ция после­до­ва­тель­но­го испол­не­ния про­грам­мы. Сна­ча­ла испол­ня­ет­ся пер­вая строч­ка, потом вто­рая, потом тре­тья и так далее. Может быть, где-то про­грам­ма прыг­нет вперёд-назад, где-то заколь­цу­ет­ся, но в целом она испол­ня­ет­ся линейно.

У JS есть фиш­ка — он уме­ет испол­нять код парал­лель­но (услов­но гово­ря). Про­грам­ми­сты назы­ва­ют это обра­бот­кой собы­тий. Про­грам­ме мож­но ска­зать: «Если когда-нибудь про­изой­дёт вот это — выпол­ни­те вон ту функ­цию, она зна­ет, что делать». Таких собы­тий мож­но преду­смот­реть мно­го — полу­ча­ет­ся, про­цес­сы как буд­то парал­лель­ны. Про­грам­ма может про­сто сидеть и ждать, когда что-то произойдёт.

Боль­ше того, про­цес­сы асин­хрон­ны: про­грам­ма может что-то запро­сить в самом нача­ле рабо­ты — напри­мер, спро­сить что-то у базы дан­ных. И пока база дан­ных чешет­ся, про­грам­ма на Node.js будет зани­мать­ся даль­ше сво­и­ми дела­ми. А как при­дёт ответ — возь­мёт его и обработает.

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

Имен­но такое рав­но­мер­ное рас­пре­де­ле­ние все­го в цик­ле собы­тий и даёт Node.js пре­иму­ще­ство при созда­нии сер­вер­ных приложений.

Шаг 2. Ручное развертывание приложения

В процессе развертывания DevOps Services автоматически выполняет поиск файла manifest.yml. Если выйти из папки проекта верхнего уровня, содержащей файл manifest.yml, а затем нажать кнопку DEPLOY, то вы получите сообщение об ошибке, указывающее на то, что файл manifest.yml не найден. Так что перед началом развертывания лучше выбрать manifest.yml.

Для выполнения этого шага нужно войти в Bluemix.

В процессе развертывания в Bluemix служба DevOps Services использует файл manifest.yml, содержащий все настройки проекта; в этот файл не нужно вносить никаких изменений. Строка manifest.yml предписывает процессу развертывания использовать среду выполнения Bluemix Node.js. Значение , , создает уникальный URL-адрес приложения, гарантируя, что при развертывании не будет конфликтов с другими приложениями.

DevOps Services предоставляет ручные, так и автоматические способы развертывания приложений в Bluemix. Мы будем использовать ручной процесс развертывания.

1. В IDE DevOps Services выберите файл manifest.yml и нажмите кнопку DEPLOY.

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

3. Нажмите на эту ссылку и найдите раздел Manual Deployment.

4. Дождитесь обновления информации о ручном развертывании. Жирная зеленая точка указывает на то, что развертывание прошло успешно.

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

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

Understanding node.js

Node.js обычно вызывал у людей, которым я о нём рассказывал, две различные реакции. В основном они воспринимали его «как есть», однако многие были сбиты с толку.
Если вы относитесь ко второй группе, я попробую объяснить, что же такое Node.js:

• Это инструмент командной строки. Вы скачиваете архив, компилируете и устанавливаете его.
• Это позволит вам выполнять программы на JavaScript, набрав ‘node my_app.js’ в терминале.
• JavaScript выполняется движком V8 (тем самым, благодаря которому так быстро работает Google Chrome).
• Node.js предоставляет API для доступа к сети и файловой системе из JavaScript.

Перфоманс фронтенда как современное искусство: графики, код, кулстори

Всем привет. В предыдущих статьях мы говорили о базовых вещах оптимизации: раз и два. Сегодня я предлагаю с разбега окунуться в одну часть из тех задач, которыми занимается команда архитектуры фронтенда в hh.ru.

Я работаю в команде архитектуры. Мы не только перекладываем файлики из одной папки в другую, но и занимаемся кучей других вещей:

• Перфоманс приложения
• Инфраструктура: сборка, тесты, пайплайны, раскатка на продакшене, инструменты для разработчика (например бабель-плагины, кастомные eslint правила)
• Дизайн-система (UIKit)
• Переезд на новые технологии

Если покопаться, можно найти много интересного.

Поэтому, давайте поговорим о перфомансе. Команда фронтенд архитектуры ответственна как за клиентскую часть, так и серверную (SSR).

Я предлагаю посмотреть на метрики и разобраться, как мы реагируем на различные триггеры. Статья будет разбита на 2 составляющие. Серверную и клиентскую. Графики, код и кулстори прилагаются.

Телепортация тонн данных в PostgreSQL

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

Intro

Напомню некоторые вводные:

• мы строим сервис, который получает информацию из логов серверов PostgreSQL
• собирая логи, мы хотим что-то с ними делать (парсить, анализировать, запрашивать дополнительную информацию) в режиме онлайн
• все собранное и «наанализированное» надо куда-то сохранить

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