Фреймворк Qt один из самых популярных и применяемых при разработке кроссплатформенных настольных и мобильных приложений. Эта популярность не могла рано или поздно не привести к использованию Qt в системах специального и ответственного назначения. Достаточно давно существует возможность разработки на Qt для QNX Neutrino. Библиотека Qt поддерживает платформу QNX, а среда разработки Qt Creator обеспечивает взаимодействие с системами на QNX. Однако QNX, как система в том числе и для встраиваемых решений, имеет в своём составе технологии, которые не требуются, а потому и отсутствуют в системах общего назначения. Ключевая для ОСРВ QNX функциональность, на которой построена сама система и на которую нередко опираются пользовательские задачи это передача сообщений. Об особенностях применения механизма SRR (Send/Receive/Replay), как ещё называют передачу сообщений в QNX, и о разработке двух примеров Qt-приложений — клиента и сервера — я и хотел бы рассказать сегодня. В заметке не делается каких-то открытий, предлагается в общем-то известная информация. Тем не менее Qt это относительно новый фреймворк для разработчиков систем специального назначения, где исторически наблюдается некоторая инертность при внедрении новых технологий. Разработчики систем на QNX могут быть недостаточно знакомы с тонкостями Qt, а разработчики Qt-приложений зачастую могут не знать специфику QNX. Решение задачи использования в одном проекте и графических возможностей библиотеки Qt, и специфичных для QNX технологий может потребовать затраты усилий, особенно на первых этапах. Именно поэтому и появилась данная заметка, цель которой в одном месте собрать информацию, которая может понадобиться разработчикам при использовании Qt в QNX. Типовой пример использования SRR в QNX Поскольку о сообщениях QNX я уже писал раньше на Хабре, в том числе и о составных сообщениях, то будем считать, что теория в каком-то виде уже известна и можно переходить к практике. Поэтому привожу ниже исходный код приложения клиента: qnx_client.c//////////////////////////////////////////////////////////////////////////////// // qnx_client.c // // demonstrates using input/output vector (IOV) messaging // //////////////////////////////////////////////////////////////////////////////// #include <string.h> #include <unistd.h> #include <stdlib.h> #include <stdio.h> #include "../iov_server.h" int main(int argc, char* argv[]) { int coid; // Connection ID to server cksum_header_t hdr; // msg header will specify how many bytes of data will follow int incoming_checksum; // space for server's reply int status; // status return value iov_t siov[2]; // create a 2 part iov if ( 2 d\n"); exit(EXIT_FAILURE); } // locate the server coid = name_open(CKSUM_SERVER_NAME, 0); if ( -1 > Программа довольно тривиальная, я просто взял пример из курсов по QNX и немного его «причесал». Это консольное приложение, которое принимает на вход строку, пересылает её на сервер и выводит на экран ответ сервера — контрольную сумму переданной ранее строки. Обратите внимание, что в примере используются составные сообщения — макрос SETIOV() и функция MsgSendvs() вместо MsgSend() — что позволяет избежать лишнего копирования. Самое интересное здесь это использование функции name_open() для поиска сервера и установления соединения с ним. Теперь самое время посмотреть исходный код сервера: qnx_server.c//////////////////////////////////////////////////////////////////////////////// // qnx_server.c // // demonstrates using input/output vector (IOV) messaging // //////////////////////////////////////////////////////////////////////////////// #include <stdio.h> #include <stdlib.h> #include "../iov_server.h" typedef union { uint16_t msg_type; struct _pulse pulse; cksum_header_t cksum_hdr; } msg_buf_t; int calculate_checksum(char *text) { char *c; int cksum = 0; for ( c = text; *c; c++ ) cksum > Код сервера немного поинтереснее. Сервер принимает и обрабатывает сообщения от клиента. На самом деле в этом примере реализовано только одно сообщение — CKSUM_MSG_TYPE — подсчёт контрольной суммы переданных данных. Другое сообщение — _IO_CONNECT — посылается серверу, когда клиент вызывает функцию name_open(). Помимо сообщений сервер умеет обрабатывать служебные импульсы _PULSE_CODE_DISCONNECT и _PULSE_CODE_UNBLOCK. В этом простом примере обработка служебных сообщений в принципе не требуется. Алгоритм работы сервера достаточно прост. Сначала выполняется инициализация, в данном случае это объявление имени при помощи функции name_attach(), после чего клиенты могут найти сервер. Дальнейшая работа сервера представляет собой «вечный цикл». В самом начале цикла сервер блокируется на вызове MsgReceive() ожидая сообщений от клиента. По приходу сообщения или пульса ядро QNX разблокирует сервер, который начнёт обработку принятого сообщения. В примере используется объединение (union) msg_buf_t для получения сообщения. Это обычная практика для QNX, когда возможные типы сообщений (а сообщение обычно описываются структурой языка Си) объединяются в union. Наше полезное сообщение CKSUM_MSG_TYPE мы получаем при помощи MsgReceive() не целиком, принимается только заголовок, в котором указан размер данных. Данные дочитываются при помощи функции MsgRead(). Ответ клиенту отправляется при помощи функции MsgReply(), а в случае ошибки — MsgError(). Импульсы не требуют ответа. Для полноты картины привожу текст заголовочного файла. Этот заголовочный файл используется и сервером, и клиентом, и, как мы увидим дальше, Qt версии нашего сервера и клиента тоже используют этот файл. Он предназначен для подключения необходимых заголовочных файлов и объявления структуры заголовка сообщения CKSUM_MSG_TYPE. iov_server.h#ifndef _IOV_SERVER_H_ #define _IOV_SERVER_H_ #include <sys/dispatch.h> #include <sys/neutrino.h> #include <sys/iomsg.h> #include <errno.h> #define CKSUM_SERVER_NAME "cksum" #define CKSUM_MSG_TYPE (_IO_MAX + 2) typedef struct { uint16_t msg_type; unsigned data_size; } cksum_header_t; // checksum reply is an int #endif //_IOV_SERVER_H_ На скриншоте ниже представлен пример работы консольных версий сервера и клиента: Сначала запускается сервер, который ожидает сообщений от клиента. Потом запускается клиент, в качестве аргумента ему указывается строка «Hello, QNX!» Во время работы клиент и сервер выводят диагностические сообщения в консоль, по которым можно судить о работе программ. Программы работают как ожидалось, можно приступать к написанию графических вариантов на Qt. Сначала адаптируем клиентское приложение. Пример клиента на Qt Разрабатывать Qt приложения будем в Qt Creator. В этом случае сам процесс разработки приложений для QNX в общем не отличается от разработки приложений для других ОС. Ведь Qt это кроссплатформенный фреймворк. Требуется только создать комплект (Kit) для QNX в Qt Creator. Создаём новый проект приложения типа Qt Widgets Application. При этом Qt Creator подготовит все необходимые файлы, в том числе и форму для окна. Для клиента форму окна приводим к следующему виду: На форме размещены поле для ввода текста (text), который передаётся серверу, кнопки подключения (connect) и отключения (disconnect) от сервера, кнопка (calc) отправки сообщения серверу, поле ввода (cksum), которое используется для вывода контрольной суммы полученной от сервера, и область вывода диагностических сообщений (status). Осталось только написать код для работы с сервером и обработки логики графической формы. В результате получаем следующий класс MainWindow: mainwindow.h#ifndef MAINWINDOW_H #define MAINWINDOW_H #include <QMainWindow> #include "../iov_server.h" namespace Ui { class MainWindow; } class MainWindow : public QMainWindow { Q_OBJECT public: explicit MainWindow(QWidget *parent = 0); ~MainWindow(); public slots: void log(QString msg); void showCrc(QString crc); private slots: void qnxConnect(); void qnxDisconnect(); void calculate(); private: Ui::MainWindow *ui; int coid; // Connection ID to server }; #endif // MAINWINDOW_H mainwindow.cpp#include "mainwindow.h" #include "ui_mainwindow.h" #include <QDateTime> MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow) { ui->setupUi(this); coid = -1; connect(ui->connect, SIGNAL(clicked()), this, SLOT(qnxConnect())); connect(ui->disconnect, SIGNAL(clicked()), this, SLOT(qnxDisconnect())); connect(ui->calc, SIGNAL(clicked()), this, SLOT(calculate())); } MainWindow::~MainWindow() { delete ui; } void MainWindow::qnxConnect() { // check if we already connected if ( coid t connect to server: ")).append(strerror(errno))); return; } log(tr("Connected to server")); ui->connect->setEnabled(false); ui->disconnect->setEnabled(true); ui->calc->setEnabled(true); } void MainWindow::qnxDisconnect() { // check if we already disconnected if ( coid < 0 ) return; // disconnect from the server int status = name_close(coid); if ( status < 0 ) { log(QString(tr("Can't disconnect from server: ")).append(strerror(errno))); return; } log(tr("Disconnected from server")); coid = -1; ui->calc->setEnabled(false); ui->disconnect->setEnabled(false); ui->connect->setEnabled(true); } void MainWindow::calculate() { ui->disconnect->setEnabled(false); ui->calc->setEnabled(false); // get the data QString data = ui->text->toPlainText(); log(QString(tr("Sending the following text to checksum server: %1")).arg(data)); // build the header cksum_header_t hdr; // msg header will specify how many bytes of data will follow hdr.msg_type = CKSUM_MSG_TYPE; hdr.data_size = data.length() + 1; // setup the message as a two part iov, first the header then the data iov_t siov[2]; // create a 2 part iov SETIOV(&siov[0], &hdr, sizeof(hdr)); SETIOV(&siov[1], data.toAscii().data(), hdr.data_size); // and send the message off to the server int incoming_checksum; // space for server's reply int status = MsgSendvs(coid, siov, 2, &incoming_checksum, sizeof(incoming_checksum)); if ( status < 0 ) { log(QString(tr("Can't send message to server: ")).append(strerror(errno))); return; } log(QString(tr("MsgSend return status: %1")).arg(status)); showCrc(QString::number(incoming_checksum)); } void MainWindow::showCrc(QString crc) { ui->cksum->setText(crc); ui->disconnect->setEnabled(true); ui->calc->setEnabled(true); } void MainWindow::log(QString msg) { ui->status->append(msg.prepend(QDateTime::currentDateTime().toString("hh:mm:ss "))); } Файл main.cpp остался таким, каким его создал Qt Creator, поэтому приводить его содержимое не стану. Итак, посмотрим, что же мы тут понаделали. Сначала, как и в прошлом примере, запускаем сервер. Затем запускаем Qt версию клиента. Нажимаем кнопку Connect, обращаем внимание, что сервер получает уведомление о подключении клиента в виде сообщения _IO_CONNECT. Затем пишем текст «Hello, QNX!» и нажимаем кнопку Calc, что приводит к отправке сообщения на на сервер. Событие отправки также отображается на экране. Полученная от сервера контрольная сумма отображается в окне клиента. Пример работает, сообщения отправляются и принимаются, проблем не замечено. Но… Но я то знаю, что всё не должно так замечательно работать. Дело в том, что после вызова MsgSendvs() клиент блокируется как минимум до вызова сервером функции MsgReceive() (моет быть больше, если в системе есть более высокоприоритетные процессы). Для иллюстрации этой особенности в коде функции calculate_checksum() сервера добавлена задержка в виде вызова sleep(10). С такой задержкой в сервере клиент блокируется на 10 секунд, что приводит к заметному «замерзанию» графического окна сервера. В некоторых случаях, особенно когда сервер сразу отвечает клиенту (т.е. информация всегда доступна серверу, а не приходит извне), блокировка не является проблемой. В остальных случаях, пользователь может начать нервничать, когда у него «замерзает» графический интерфейс. Я бы не стал рисковать и выпускать программы, которые могут нервировать заказчиков. С «замёрзшим» интерфейсом клиент не сможет продолжить работу с приложением после отправки сообщения до получения ответа от сервера, а ведь в реальной жизни приложение может взаимодействовать с несколькими серверами и предоставлять другие функции управления. Нет, текущий вариант клиентского приложения нас не может устроить. Поэтому давайте посмотрим на правильную реализацию клиента. Правильный пример клиента на Qt Как же можно решить проблему с блокировкой клиента? Клиент не может не блокироваться на MsgSendvs(). Однако вполне допустимо выделить работу с сообщениями в отдельный поток. В этом случае один поток обслуживает графический интерфейс, другой — реализует механизм SRR. Для работы с потоками в Qt будем использовать класс QThread. Реализацию SRR вынесем в отдельный класс Sender. Связь между классами Sender (работа с сообщениями) и MainWindow (графический интерфейс) организуем через сигналы и слоты Qt. Посмотрим, как изменился класс MainWindow с учётом вышесказанного. Для наглядности старый код также оставлен, и добавлен макрос SENDER_THREAD, при объявлении которого работа с сообщениями выполняется в отдельном потоке Qt. mainwindow.h#ifndef MAINWINDOW_H #define MAINWINDOW_H #include <QMainWindow> #include "../iov_server.h" #define SENDER_THREAD #ifdef SENDER_THREAD #include <QThread> #endif namespace Ui { class MainWindow; } class MainWindow : public QMainWindow { Q_OBJECT public: explicit MainWindow(QWidget *parent = 0); ~MainWindow(); #ifdef SENDER_THREAD signals: void calcCrc(int coid, QString data); #endif public slots: void log(QString msg); void showCrc(QString crc); private slots: void qnxConnect(); void qnxDisconnect(); void calculate(); private: Ui::MainWindow *ui; int coid; // Connection ID to server #ifdef SENDER_THREAD QThread senderThread; #endif }; #endif // MAINWINDOW_H mainwindow.cpp#include "mainwindow.h" #include "ui_mainwindow.h" #ifdef SENDER_THREAD #include "sender.h" #endif #include <QDateTime> MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow) { ui->setupUi(this); coid = -1; connect(ui->connect, SIGNAL(clicked()), this, SLOT(qnxConnect())); connect(ui->disconnect, SIGNAL(clicked()), this, SLOT(qnxDisconnect())); connect(ui->calc, SIGNAL(clicked()), this, SLOT(calculate())); #ifdef SENDER_THREAD Sender *sender = new Sender; sender->moveToThread(&senderThread); connect(&senderThread, SIGNAL(finished()), sender, SLOT(deleteLater())); connect(this, SIGNAL(calcCrc(int, QString)), sender, SLOT(send(int, QString))); connect(sender, SIGNAL(result(QString)), this, SLOT(showCrc(QString))); connect(sender, SIGNAL(log(QString)), this, SLOT(log(QString))); senderThread.start(); #endif } MainWindow::~MainWindow() { #ifdef SENDER_THREAD senderThread.quit(); senderThread.wait(); #endif delete ui; } void MainWindow::qnxConnect() { // check if we already connected if ( coid t connect to server: ")).append(strerror(errno))); return; } log(tr("Connected to server")); ui->connect->setEnabled(false); ui->disconnect->setEnabled(true); ui->calc->setEnabled(true); } void MainWindow::qnxDisconnect() { // check if we already disconnected if ( coid < 0 ) return; // disconnect from the server int status = name_close(coid); if ( status < 0 ) { log(QString(tr("Can't disconnect from server: ")).append(strerror(errno))); return; } log(tr("Disconnected from server")); coid = -1; ui->calc->setEnabled(false); ui->disconnect->setEnabled(false); ui->connect->setEnabled(true); } void MainWindow::calculate() { ui->disconnect->setEnabled(false); ui->calc->setEnabled(false); // get the data QString data = ui->text->toPlainText(); #ifdef SENDER_THREAD emit calcCrc(coid, data); #else log(QString(tr("Sending the following text to checksum server: %1")).arg(data)); // build the header cksum_header_t hdr; // msg header will specify how many bytes of data will follow hdr.msg_type = CKSUM_MSG_TYPE; hdr.data_size = data.length() + 1; // setup the message as a two part iov, first the header then the data iov_t siov[2]; // create a 2 part iov SETIOV(&siov[0], &hdr, sizeof(hdr)); SETIOV(&siov[1], data.toAscii().data(), hdr.data_size); // and send the message off to the server int incoming_checksum; // space for server's reply int status = MsgSendvs(coid, siov, 2, &incoming_checksum, sizeof(incoming_checksum)); if ( status < 0 ) { log(QString(tr("Can't send message to server: ")).append(strerror(errno))); return; } log(QString(tr("MsgSend return status: %1")).arg(status)); showCrc(QString::number(incoming_checksum)); #endif } void MainWindow::showCrc(QString crc) { ui->cksum->setText(crc); ui->disconnect->setEnabled(true); ui->calc->setEnabled(true); } void MainWindow::log(QString msg) { ui->status->append(msg.prepend(QDateTime::currentDateTime().toString("hh:mm:ss "))); } В объявлении класса MainWindow появился сигнал calcCrc(), при помощи которого сообщаемся экземпляру класса Sender кому и какое сообщение требуется отправить. Большие изменения претерпела реализация класса MainWindow. В конструкторе появился блок кода, в котором создаётся экземпляр класса Sender и при помощи метода moveToThread() выделяется в отдельный поток. В деструкторе ожидаем завершение потока (методы quit() и wait() класса QThread). Весь код метода calculate() перенесён в класс Sender и заменён на генерацию сигнала calcCrc(). После доработки MainWindow, можно перейти к классу Sender. sender.h#ifndef SENDER_H #define SENDER_H #include <QObject> #include "../iov_server.h" class Sender : public QObject { Q_OBJECT public: Sender() {} virtual ~Sender() {} signals: void result(QString data); void log(QString err); public slots: void send(int coid, QString data); }; #endif // SENDER_H sender.cpp#include "sender.h" void Sender::send(int coid, QString data) { emit log(QString(tr("Sending the following text to checksum server: %1")).arg(data)); // build the header cksum_header_t hdr; // msg header will specify how many bytes of data will follow hdr.msg_type = CKSUM_MSG_TYPE; hdr.data_size = data.length() + 1; // setup the message as a two part iov, first the header then the data iov_t siov[2]; // create a 2 part iov SETIOV(&siov[0], &hdr, sizeof(hdr)); SETIOV(&siov[1], data.toAscii().data(), hdr.data_size); // and send the message off to the server int incoming_checksum; // space for server's reply int status = MsgSendvs(coid, siov, 2, &incoming_checksum, sizeof(incoming_checksum)); if ( status < 0 ) { emit log(QString(tr("Can't send message to server: ")).append(strerror(errno))); return; } emit log(QString(tr("MsgSend return status: %1")).arg(status)); emit result(QString::number(incoming_checksum)); } По сути это код, который был раньше в методе calculate() класса MainWindow. Вывод ошибок и результата в графическое окно приложения клиента реализован при помощи сигналов log() и result(). С такими доработками графический интерфейс клиента не «замерзает», т.е. пока экземпляр класса Sender блокируется на 10 секунд в отдельном потоке, мы можем управлять графическим окном. Правда в представленном примере управлять особо нечем, но возможность то есть. Пример сервера на Qt Поэксперементировав с клиентом будем сразу разрабатывать сервер правильно. Поскольку вызов MsgReceive() приводит к блокировке, то вынесем функциональность сервера в класс Server, который будет работать в отдельном потоке. Принципы те же, что и в клиенте. Форму главного окна по-честному «скомуниздим» у клиента — скопируем mainwindow.ui, откроем в редакторе, удалим ненужные кнопки и преобразуем класс QPlainTextEdit (объект text) в QTextBrowser (редактор это позволяет). Объявление и реализация класса MainWindow сервера приведены ниже: mainwindow.h#ifndef MAINWINDOW_H #define MAINWINDOW_H #include <QMainWindow> #include <QThread> #include "../iov_server.h" namespace Ui { class MainWindow; } class MainWindow : public QMainWindow { Q_OBJECT public: explicit MainWindow(QWidget *parent = 0); ~MainWindow(); signals: void startServer(name_attach_t* attach); public slots: void log(QString msg); void showCrc(QString crc); void showText(QString txt); void stopServer(void); private: Ui::MainWindow *ui; name_attach_t* attach; QThread serverThread; }; #endif // MAINWINDOW_H mainwindow.cpp#include "mainwindow.h" #include "ui_mainwindow.h" #include "server.h" #include <QDateTime> MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow) { ui->setupUi(this); Server *server = new Server; server->moveToThread(&serverThread); connect(&serverThread, SIGNAL(finished()), server, SLOT(deleteLater())); connect(this, SIGNAL(startServer(name_attach_t*)), server, SLOT(process(name_attach_t*))); connect(server, SIGNAL(result(QString)), this, SLOT(showCrc(QString))); connect(server, SIGNAL(text(QString)), this, SLOT(showText(QString))); connect(server, SIGNAL(log(QString)), this, SLOT(log(QString))); attach = name_attach(NULL, CKSUM_SERVER_NAME, 0); if ( NULL t attach name: %1")).arg(strerror(errno))); } else { serverThread.start(); emit startServer(attach); } } MainWindow::~MainWindow() { stopServer(); serverThread.quit(); serverThread.wait(); delete ui; } void MainWindow::showText(QString txt) { ui->text->setText(txt); } void MainWindow::showCrc(QString crc) { ui->cksum->setText(crc); } void MainWindow::log(QString msg) { ui->status->append(msg.prepend(QDateTime::currentDateTime().toString("hh:mm:ss "))); } void MainWindow::stopServer() { if ( NULL > Для работы сервера создаём имя в MainWindow используя функцию name_attach(). При помощи сигнала передаём структуру attach в поток сервера, тем самым запуская его. Для остановки сервера удаляем имя — функция name_detach(). В остальном очень похоже на то, что было сделано в клиенте. Посмотрим на код: server.h#ifndef SERVER_H #define SERVER_H #include <QObject> #include "../iov_server.h" typedef union { uint16_t msg_type; struct _pulse pulse; cksum_header_t cksum_hdr; } msg_buf_t; class Server : public QObject { Q_OBJECT public: Server() {} virtual ~Server() {} signals: void result(QString data); void text(QString text); void log(QString err); public slots: void process(name_attach_t* attach); private: int calculate_checksum(char *text); }; #endif // SERVER_H server.cpp#include "server.h" int Server::calculate_checksum(char *text) { int cksum = 0; for ( char *c = text; *c; c++ ) cksum > Класс Server реализует две функции консольного сервера (qnx_server), изменился только вывод сообщений (при помощи сигналов/слотов Qt) и регистрация имени выполняется в классе MainWindow. Работа графических вариантов клиента и сервера представлена на следующем скриншоте: Сервер получился без элементов управления. Нет ни кнопок, ни полей ввода. Графическое окно сервера служит только для контроля за его работой. Заключение Вот и подошла к концу эта заметка. Был рассмотрен код нескольких примеров, стало понятно, как правильно использовать механизм сообщений QNX в приложениях на Qt. Для тех же, кто захочет воспроизвести примеры я опубликовал их на Bitbucket. Предвидя возможные замечания по коду, прошу учесть, что это только примеры, которые иллюстрируют работу SRR в Qt. Кое-что в рабочей системе я бы сделал иначе, но чтобы не перегружать примеры, их код был упрощён, и на некоторые моменты я закрыл глаза. Тем не менее, если у кого-то из читателей появятся конкретные предложения по улучшению кода примеров или исправлению ошибок, то я их по возможности учту. Прошу по этим вопросам обращаться в личные сообщения.
Сетевые технологии Интернета вещей

Предисловие Не так давно проект, на котором я работаю в данный момент, начал использовать модульную систему ES2015. Я не буду заострять внимание на этой технологии JavaScript, т.к статья совсем не об этом, а о том как технология сподвигла меня к одной мысли. Как многие знают, ES2015 Modules представляют собой импортирование/экспортирование скриптов крайне схожее по синтаксису с python и многими другими языками программирования. Пример: // Helper.js export function includes(array, variable) { return array.indexOf(variable) Helper'; assets(includes([1,2,3], 2), true); Все, кто интересовался модулями JavaScript знают, что импортирование и экспортирование возможно только на верхнем уровне модуля (файла с кодом). Следующий грубый пример кода вызовет ошибки: // sendEmail.js export default function sendEmails(emails_list) { import sender from 'sender'; export sender; // сделать что-то } Exception: SyntaxError: import/export declarations may only appear at top level of a module В отличие от ES2015 Modules — в модульной системе node.js импортирование и экспортирование возможны на любом уровне вложенности. Аналогичный код на node.js не вызовет ошибку: // sendEmail.js module.exports = function sendEmails(emails_list) { const sender = require('sender'); exports.sender = sender; // сделать что-то } Преимущество такого способа в том, что модули необходимые в обработчике явно импортированы внутри и не засоряют пространство имен модуля (особенно актуально, если импортируемый модуль нужен только в одном обработчике). Так же появляется возможность отложенного экспортирования данных модуля. Основные минусы: Об отсутствии модуля вы узнаете только во время вызова соответствующего обработчика Путь к импортироемому модулю может измениться, что приведет к изменению в каждом месте импортирования (например, в вашем модуле, в различных обработчиках используется lodash/object/defaults и вы решили обновиться до 4.x версии, где подключать нужно lodash/defaults). Разбор полетов В большинстве задач для которых используется node.js — front-end или основной веб-сервер, и высокая нагрузка на node.js частое явление. Пропуская способность вашего сервера должны быть максимально возможная. Измерение пропускной способности Для измерения пропускной способности веб-сервера используется великолепная утилита от Apache — ab. Если вы еще с ней не знакомы, то настоятельно рекомендую это сделать. Код веб-сервера одинаков за исключением обработчиков. Тест запускался на node.js 6.0 с использованием модуля ifnode, сделанного на базе express Импортирование модулей непосредственно в обработчик Код: const app = require('ifnode')(); const RequireTestingController = app.Controller({ root: '/', map: { 'GET /not_imported': 'notImportedAction' } }); RequireTestingController.notImportedAction = function(request, response, next) { const data = { message: 'test internal and external require' }; const _defaults = require('lodash/object/defaults'); const _assign = require('lodash/object/assign'); const _clone = require('lodash/lang/clone'); response.ok({ _defaults: _defaults(data, { lodash: 'defaults' }), _assign: _assign(data, { lodash: 'assign' }), _clone: _clone(data) }); }; Результат: $ ab -n 15000 -c 30 -q "http://localhost:8080/not_imported" Server Hostname: localhost Server Port: 8080 Document Path: /not_imported Document Length: 233 bytes Concurrency Level: 30 Time taken for tests: 4.006 seconds Complete requests: 15000 Failed requests: 0 Total transferred: 6195000 bytes HTML transferred: 3495000 bytes Requests per second: 3744.32 [#/sec] (mean) Time per request: 8.012 [ms] (mean) Time per request: 0.267 [ms] (mean, across all concurrent requests) Transfer rate: 1510.16 [Kbytes/sec] received Percentage of the requests served within a certain time (ms) 50% 6 66% 7 75% 8 80% 8 90% 10 95% 15 98% 17 99% 20 100% 289 (longest request) Импортирование модулей в начале файла Код: const app = require('ifnode')(); const _defaults = require('lodash/object/defaults'); const _assign = require('lodash/object/assign'); const _clone = require('lodash/lang/clone'); const RequireTestingController = app.Controller({ root: '/', map: { 'GET /already_imported': 'alreadyImportedAction' } }); RequireTestingController.alreadyImportedAction = function(request, response, next) { const data = { message: 'test internal and external require' }; response.ok({ _defaults: _defaults(data, { lodash: 'defaults' }), _assign: _assign(data, { lodash: 'assign' }), _clone: _clone(data) }); }; Результат: $ ab -n 15000 -c 30 -q "http://localhost:8080/already_imported" Server Hostname: localhost Server Port: 8080 Document Path: /already_imported Document Length: 233 bytes Concurrency Level: 30 Time taken for tests: 3.241 seconds Complete requests: 15000 Failed requests: 0 Total transferred: 6195000 bytes HTML transferred: 3495000 bytes Requests per second: 4628.64 [#/sec] (mean) Time per request: 6.481 [ms] (mean) Time per request: 0.216 [ms] (mean, across all concurrent requests) Transfer rate: 1866.83 [Kbytes/sec] received Percentage of the requests served within a certain time (ms) 50% 5 66% 6 75% 6 80% 7 90% 8 95% 14 98% 17 99% 20 100% 38 (longest request) Анализ результатов Импортирование модулей в начале файла уменьшило время одного запроса на ~23%(!) (в сравнение с импортированием непосредственно в обработчик), что весьма существенно. Такая большая разница в результатах кроется в работе функции require. Перед импортированием, require обращается к алгоритму поиска абсолютного пути к запрашиваемому компоненту (алгоритм описан в документации node.js). Когда путь был найден, то require проверяет был ли закеширован модуль, и если нет — не делает ничего сверхестественного, кроме вызова обычного fs.readFileSync для .js и .json форматов, и недокументированного process.dlopen для загрузки C++ модулей. Note: пробовал "прогревать" кеш для случая с непосредственным импортированием модулей в обработчик (перед запуском утилиты ab, модули были уже закешированы) — производительность улучшалась на 1-2%. Выводы Если вы используете node.js, как сервер (нет разницы какой — TCP/UDP или HTTP(S)), то: Импортирование всех модулей необходимо делать в начале файла, чтобы избегать лишних синхронных операций связанных с загрузкой модулей (один из главных анти-паттернов использования node.js как асинхронного сервера). Вы можете не тратить ресурсы на вычисление абсолютного пути запрашиваемого модуля (это и есть основное место для потери производительности).

Многие из нас уже не раз писали разного рода магазины. Но большие e-commerce проекты в быстро растущей и развивающейся компании разрабатывать приходится нечасто. К таким решениям предъявляются дополнительные требования, такие как конфигурируемость, адаптивность к изменениям, возможности встраивания в другие системы и прочее. Для написания такого решения компания Netcracker использовала Liferay Portal фреймворк. В итоге получили достаточно преимуществ, но и без проблем не обошлось.
Подробнее под катом