Эффективное управление памятью на стороне сервера в API-интерфейсе express/node.js

Обзор

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

Однако мне все еще немного неудобно, так как это переводит на серверную среду JavaScript, такую как node.js, и более конкретно API, написанный на express.

Возьмите этот файл примера (позвоните ему server.js)

var npm_moduleA = require('npmA')({ someInitArg : 'blah' }),
    app = express.createServer();

app.get('/api/foo', function (req, res) {

    var result = npm_moduleA.doSomething();
    res.send(result);

});

app.get('/api/bar', function (req, res) {

    var npm_moduleB = require('npmB')({ someInitArg : 'blah' }),
        result = npm_moduleB.doSomethingElse();

    res.send(result);

});

Вопросы (при условии, что это сайт с высокой нагрузкой)

Что такое жизненный цикл npm_moduleA?. Он создается в момент запуска сервера, но когда (если он вообще делает GC против него) - я угадывая, что он никогда не тронут, потому что он в глобальной области?
В '/api/bar/', следует ли npm_moduleB удаляться после каждого запроса? Или это нужно оставить только в GC.
Является ли глобальное создание npm_moduleA значительно более эффективным, чем повторение экземпляра (и возможного удаления) npm_moduleB?

Ссылки

Ответ 1

Поскольку node.js не будет создавать и уничтожать контекст запуска для каждого вызова, так что оба npm_moduleA и npm_moduleB будут жить (в кеше), пока вы не убьете сервер.

Фактически независимо от того, где вы нуждаетесь в модуле, он просто получает указатель на точку входа модуля. во время выполнения ничего не происходит.

вот пример:

index.js

var t = require('./module.js');
t.value = 10;

function test() {
  var t2 = require('./module.js');
  console.log(t2.value);
}

test();

module.js

module.exports = {};

консольные выходы:

В этом случае просто поместите ваш require() s в глобальную область на один раз. do does not do требует в callbacks, потому что require() выполняет некоторую работу по разрешению имен файлов, и он не имеет никакого отличия от требования в глобальной области (в любом аспекте.)

Но если вы собираетесь экземпляр класса new SomeClass(), тогда, где вы это делаете, важно.