Javascript-форум (https://javascript.ru/forum/)
-   Node.JS (https://javascript.ru/forum/node-js-io-js/)
-   -   Сверхпроизводительные приложения на node.js (https://javascript.ru/forum/node-js-io-js/59215-sverkhproizvoditelnye-prilozheniya-na-node-js.html)

FINoM 01.11.2015 15:15

Сверхпроизводительные приложения на node.js
 
С месяца на месяц запущу один проект (не опен сорц, на этот раз) и меня интересует то, как можно построить сверхпроизводительное приложение на ноде, не боящееся хабраэффекта и других небольших DDOS-подобных эффектов. С нодой знаком на очень базовом уровне, поэтому прошу помочь разобраться в вопросе.

Доставка статики
Из того, что я вычитал в интернете, статику лучше раздавать средствами ngnix, минуя node.js. Верно? У меня тут два вопроса.
Первый: при запросе к статике идет обращение к жесткому диску или SSD. Т. е. каждый запрос вызывает самую медленную операцию ввода-вывода. Можно ли после запуска сервера загрузить статику в оперативную память, избегая постоянного дергания жесткого диска? Если это невозможно (или очень сложно) сделать средствами ngnix, хочется узнать, какой вариант лучше:
а) Отдавать статику ngnix-ом (с чтением с жесткого диска)
б) Отдавать статику средствами nodejs, но предварительно загрузив содержимое статики в память.
Второй: в проекте при изменении данных (когда один из пользователей добавляет контент), меняется содержимое индексной страницы. Это будет происходить примерно раз в час. Есть ли смысл при изменении данных генерировать новый HTML файл, а не рисовать его при каждом обращении?

REST API
Планируется так же сделать небольшое API, использующее Express и Mongo. Обращение к БД тоже трудозатратное мероприятие. При перезагрузке сервера планирую выгрузить все данные (их не много) из БД в оперативную память (в обычную переменную), при добавлении данных писать в БД и обновлять переменную, а при обращении к данным не дергать БД, а отдавать стрингифицированный, отфильтрованный JSON из переменной. Есть ли смысл это делать?

Заренее прошу прощения за, возможно, неправильное употребление терминов.

Safort 01.11.2015 15:51

FINoM,
Цитата:

Можно ли после запуска сервера загрузить статику в оперативную память, избегая постоянного дергания жесткого диска?
Да. А почему ты в этом сомневаешься?


Цитата:

Если это невозможно (или очень сложно) сделать средствами ngnix, хочется узнать, какой вариант лучше:
а) Отдавать статику ngnix-ом (с чтением с жесткого диска)
б) Отдавать статику средствами nodejs, но предварительно загрузив содержимое статики в память.
Хз, это надо тестить. Кто же знает, что у тебя там за нагрузка и данные.


Цитата:

Это будет происходить примерно раз в час. Есть ли смысл при изменении данных генерировать новый HTML файл, а не рисовать его при каждом обращении?
Думаю, да.

FINoM 01.11.2015 16:03

Цитата:

Сообщение от Safort
Да. А почему ты в этом сомневаешься?

Я понимаю, что это сделать можно. Меня интересует вопрос подводных камней.
Цитата:

Сообщение от Safort
Хз, это надо тестить. Кто же знает, что у тебя там за нагрузка и данные.

Это касается статики, всю динамику, я, конечно, буду пилить на ноде.
Цитата:

Сообщение от Safort
Думаю, да.

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

kobezzza 01.11.2015 18:39

Велосипедство детектед. Для статики возьми Amazon S3 и не парься, там всё уже за тебя настроили. Что качается кеширования БД - все современные СУБД и так это делают по дефолту, т.е. всё держат в памяти. А вообще, если твое приложение не масштабируется горизонтально (т.е. путём добавления новых серверов), то всё остальное не имеет смысла.

FINoM 01.11.2015 18:52

Цитата:

Сообщение от kobezzza
Что качается кеширования БД - все современные СУБД и так это делают по дефолту, т.е. всё держат в памяти.

Тем не менее, запрос к БД - это лишняя операция, которую можно избежать.
Цитата:

Сообщение от kobezzza
А вообще, если твое приложение не масштабируется горизонтально (т.е. путём добавления новых серверов), то всё остальное не имеет смысла.

Причем тут масштабирование? Я говорю о производительности на одном сервере.


Часовой пояс GMT +3, время: 12:18.