Рубрика «Блог компании Нордавинд» - 4

Пишем сервер, который не падает под нагрузкойОт переводчика: Это пятая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona.


Как написать приложение Node.js, которое будет продолжать работать даже под невозможной нагрузкой? В этой статье показана методика и библиотека node-toobusy, её воплощающая, суть которой наиболее кратко может быть передана этим фрагментом кода:

var toobusy = require('toobusy');
 
app.use(function(req, res, next) {
  if (toobusy()) res.send(503, "I'm busy right now, sorry.");
  else next();
});

В чём заключается проблема?

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

Это может быть и злонамеренный всплеск трафика, например от DoS-атаки. Первый шаг к борьбе с такими атаками — написание сервера, который не падает.
Читать полностью »

Храним сессии на клиенте, чтобы упростить масштабирование приложения (3 я из 12 статей о Node.js от команды Mozilla Identity)От переводчика: Это третья статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Эта статья посвящена применяемому в Persona способу хранения данных сессии на клиенте.


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

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

Масштабирование сайта с хранением состояния

Если необходимо масштабировать такой сайт, есть три варианта:

  1. Реплицировать данные сессии между всеми серверами.
  2. Использовать центральное хранилище, к которому будут обращаться все серверы.
  3. Закрепить за каждым пользователем определённый сервер.

У всех этих подходов есть недостатки:

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

Тем не менее, поразмыслив немного, можно придумать и четвёртый способ: хранить все данные сессии на клиенте.
Читать полностью »

Нагружаем Node под завязку (2 я из 12 статей о Node.js от команды Mozilla Identity)От переводчика: Это вторая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Эта статья написана по мотивам выступления Ллойда Хилайеля на конференции Node Philly 2012 в Филадельфии.

Перевод первой статьи, "Охотимся за утечками памяти в Node.js", был опубликован в пятницу.


Процесс Node.js выполняется на единственном ядре процессора, так что построение масштабируемого сервера на Node требует особой заботы. Благодаря возможности писать нативные расширения и продуманному набору API для управления процессами, есть несколько разных способов заставить Node выполнять код параллельно. Мы рассмотрим их в этой статье.

Кроме того, мы представим модуль compute-cluster — маленькую библиотеку, которая облегчает управление коллекцией процессов для выполнения распределённых вычислений.

Постановка задачи

Для Persona нам было необходимо создать сервер, который справился бы с обработкой множества запросов со смешанными характеристиками. Мы выбрали для этой цели Node.js. Нам надо было обрабатывать два основных типа запросов: «интерактивные», которые не требовали сложных вычислений и должны были выполняться быстро, чтобы интерфейс приложения был отзывчивым, и «пакетные», которые отнимали примерно пол-секунды процессорного времени и могли быть ненадолго отложены без ущерба для удобства пользователя.

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

  • Насыщение. Наше решение должно было использовать все доступные ядра процессора.
  • Отзывчивость. Пользовательский интерфейс должен оставаться отзывчивым. Всегда.
  • Отказоустойчивость. Когда нагрузка зашкаливает, мы должны нормально обслужить столько клиентов, сколько сможем, а остальным показать сообщение об ошибке.
  • Простота. Решение должно легко и постепенно интегрироваться в уже работающий сервер.

Вооружившись этими требованиями, мы можем осмысленно сравнивать разные подходы.
Читать полностью »

Охотимся за утечками памяти в Node.js (1 я из 12 статей о Node.js от команды Mozilla Identity)От переводчика: Это первая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Как клиентская, так и серверная часть Persona написаны на JavaScript. В ходе работы команда проекта создала несколько инструментов на все случаи жизни — от локализации до отладки, управления зависимостями и многого другого. В этой серии статей разработчики Mozilla делятся с сообществом своим опытом и этими инструментами, которые пригодятся любому, кто пишет высоконагруженный сервис на Node.js.

Первая статья цикла посвящена распространённой проблеме Node.js — утечкам памяти, особенностям утечек в высоконагруженных проектах и библиотеке node-memwatch, которая помогает найти и устранить такие утечки в Node.


Зачем заморачиваться?

Вы можете спросить, зачем вообще отслеживать утечки памяти? Неужели нет более важных дел? Почему бы просто не перезапускать процесс время от времени, или просто добавить памяти на сервер? Есть три причины, по которым устранять утечки всё-таки важно:

  1. Возможно, вы не сильно переживаете об утечках памяти, но этого нельзя сказать о V8 (движок JavaScript на котором работает Node). Чем больше памяти занято, тем активнее работает сборщик мусора, замедляя ваше приложение. Так что в Node утечки напрямую вредят производительности.
  2. Утечки могут привести к другим проблемам. Протекающий код может блокировать ограниченные ресурсы. У вас могут закончиться файловые дескрипторы или вы вдруг не сможете открыть ещё одно соединение с БД. Такие проблемы могут возникнуть задолго до того, как кончится память, но обрушат ваше приложение ничуть не хуже.
  3. Рано или поздно ваше приложение упадёт. И это наверняка случится во время наплыва посетителей. Вас все засмеют и будут писать про вас гадости на Hacker News.

Читать полностью »

Проблемы с потоками. Эдвард А. Ли

Аннотация

Потоки являются прямой адаптацией доминирующей сейчас последовательной модели вычислений к параллельным системам. Языки программирования не требуют (или требуют совсем немного) изменений в синтаксисе, чтобы поддерживать потоки, а операционные системы и архитектуры непрерывно развиваются, чтобы повысить эффективность их использования. Многие технологи (инженеры) стремятся интенсивно использовать многопоточность в программном обеспечении и ожидают получить значительное (предсказанное) увеличение производительности. В этой работе я доказываю, что это не очень хорошая идея. Хотя использование потоков кажется небольшим шагом от последовательных вычислений, фактически, это огромный шаг. Использование потоков разрушает такие неотъемлемые свойства последовательных вычислений как: понятность, предсказуемость и определенность (детерминированность). Потоки, как модель вычислений, являются очень недетерминированными, а работа программ также становится неопределенной. Хотя многие исследованные техники улучшают модель вычислений за счет более эффективного сокращения неопределенности, я доказываю, что они не решают проблему полностью. Вместо того, чтобы сокращать неопределенность, мы должны строить модель вычислений исходя из полного детерминизма во взаимодействии программных компонентов. Неопределенность должна явно и аккуратно вводиться туда, где есть в этом необходимость, вместо того, чтобы удаляться там, где нет необходимости. Я доказываю преимущество разработки параллельных языков координации компонентов. Я верю, что такие языки будут гораздо более надежны, а программы будут более распараллеленные.
Читать полностью »

Open Reflex: зеркальный фотоаппарат, напечатанный на 3D принтере

250 грамм пластика ABS для 3D-печати, несколько винтов и гаек, маленькое зеркальце, магниты, кусочки листового пластика, черный герметик, а также 3D-принтер и режущий плоттер, стеклорез, отвёртки и наждачная бумага — вот практически полный набор материалов и инструментов, с помощью которых можно соорудить 35-миллиметровый плёночный зеркальный фотоаппарат Open Reflex.

Чертежи деталей и подробная инструкция по сборке опубликованы на сайте instructables под лицензией Creative Commons — фотоаппарат на 100% Open Source. По словам автора проекта, французского дизайнера и хакера Лео Мариуса, на печать и сборку аппарата уходит около 15 часов. Общая стоимость материалов для создания фотоаппарата — порядка 30 долларов.
Читать полностью »

image
Команда разработчиков из Делфтского технического университета создала самый маленький в мире автопилот. Он предназначен для микрокоптеров или вертолётов и имеет размеры всего 2х2 сантиметра. Вес платы составляет 2,8 грамма. Управляет работой автопилота 72-мегагерцовый микроконтроллер ARM Cortex M3 MCU c 16 кБ оперативной памяти и 512 кБ флэш-памяти. Несмотря на крошечные размеры, на борту есть серьёзный набор навигационного оборудования — акcелерометр, гироскоп, магнитометр, барометр и GPS.
Читать полностью »

Количество информации, доступной для обработки и анализа с помощью компьютеров, растёт, как снежный ком. Данные с камер видеонаблюдения, GPS-трекеров, сенсоров мобильных телефонов, записи финансовых транзакций, история посещений страниц в интернете оказывают всё большее влияние на принятие решений. И чем больше этих данных, тем больше приходится полагаться на их автоматическую интерпретацию. Неизбежное следствие этого — появление систем «компьютерного правосудия», которые без участия человека выявляют нарушения законов и правил. Штрафы за превышение скорости, выписываемые автоматически на основании данных с видеокамер и радаров или система анализа контента на Youtube, которая ищет нарушения копирайта — это уже повседневная реальность.

Группа американских учёных, объединяющая юристов, лингвистов и программистов, провела интересный эксперимент в этой сфере. В ходе эксперимента 52 студента-программиста должны были составить программу, которая анализировала бы данные с GPS-трекера, установленного в автомобиле и выписывала штрафы за нарушение скоростного режима в соответствии с правилами дорожного движения штата Нью-Йорк. Это оказалось очень непростой задачей — даже в самых законопослушных государствах законы никогда не выполняются буквально и на все 100%. Часть нарушений остаются незамеченными, часть слишком незначительна, чтобы правоохранители обратили на них внимание. Компьютеры же ничего не забывают и ничего не упускают. Бездумное применение правил и алгоритмов приводит к излишне жестким наказаниям и нелепым ошибкам вроде блокирования видео с шумом ветра за нарушение копирайта.
Читать полностью »

Даны два числа — a и b (Возведение в степень (задача), Возведение в степень (задача), а и b не равны одновременно 0).
Необходимо вывести последнюю цифру десятичной записи числа Возведение в степень (задача).
Читать полностью »

Условие задачи такое же, как и в предыдущей, но Вы можете использовать только язык программирования Brainf**k. Вывод программы должен содержать ровно 1 символ — ответ на вопрос («Y» или «N»).

Решение:
Будем теперь реализовывать проверку, является ли число n степенью двойки, на языке Brainf*ck. Первый этап – ввод числа. Так как ограничение довольно большое (Остановится ли? Часть II (Задача)), то хранить это число придется поразрядно.
>> ,+[>+++++++[-<------->]+>>,+]<<-<[+]
Отступим перед вводом две ячейки – они нам понадобятся в дальнейшем (вместо этого могли бы использовать две ячейки с отрицательными адресами, но в интерпретаторе bff-1.0.3.1 есть ошибка: они не заполняются нулями).
После каждой введенной цифры будем записывать специальную метку и оставлять пустую ячейку:
Остановится ли? Часть II (Задача)
Метки впоследствии помогут нам точно определять границы числа. В качестве них используем единицу. Также, так как при вводе считывается код символа, а не сама цифра, для удобства вычтем код символа '0' (48).
В последнем «фиктивном» разряде будем накапливать остаток (сначала оставим ячейку пустой).
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js