JSON-API в NodeJS за веб-сервером Apache: лучшие практики для обработки кеширования и сжатия?

Я написал JSON-API на NodeJS для небольшого проекта, работающего за веб-сервером Apache. Теперь я бы хотел улучшить производительность, добавив кеширование и сжатие. По сути, вопрос в том, что делать в самом NodeJS, а с чем лучше справляется Apache:

а) Вызовы API имеют уникальные URL-адреса (например, / api / user-id / content), и я хочу кэшировать их не менее 60 секунд.

б) Я хочу, чтобы вывод обрабатывался как Gzip (если это понимает клиент). HTTP-модуль NodeJS обычно доставляет контент как «фрагментированный». Поскольку я пишу ответ только в одном месте, достаточно ли настроить заголовок Content-encoding, чтобы он служил единым целым, чтобы его можно было сжать и кэшировать?


node.js api apache gzip http-caching
person Frederic    schedule 10.07.2011    source источник

Ответы (3)


arrow_upward
2
arrow_downward

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

Простой кеш

б) Насколько велики ваши данные JSON? Вы должны сами сжимать его, и не забывайте, что это не блокирует. Вы можете его сжать в потоковом режиме и уже доставить. Я никогда не делал этого с node.

person aggsol    schedule 10.07.2011
comment
а) Спасибо, посмотрю ваш скрипт кеширования. б) JSON составляет всего несколько КБ. Я забыл, что Gzip тоже должен быть неблокирующим, поэтому я думаю, что буду использовать вместо него mod_deflate Apache. - person Frederic; 11.07.2011

arrow_upward
1
arrow_downward 

> I wrote a JSON-API in NodeJS for a small project, running behind an
> Apache webserver.

Я бы просто запустил API на другом порту, а не за apache (прокси ??). Если вы хотите использовать прокси, я бы посоветовал вам использовать NGINX. См. слайды Райана Даля, в которых обсуждаются Apache и NGINX (слайды 8+). NGINX также может выполнять сжатие / кеширование (быстро). Может быть, вам не стоит сжимать весь ваш JSON (размер? Несколько КБ?). Я рекомендую вам прочитать раздел Google Page Speed ​​"Минимальный размер полезной нагрузки" (хорошее чтение!), объясняя это, которое я также цитирую ниже:

Обратите внимание, что сжатие выгодно только для больших ресурсов. Из-за накладных расходов и задержек при сжатии и распаковке следует использовать gzip только файлы, размер которых превышает определенный порог; мы рекомендуем минимальный диапазон от 150 до 1000 байт. Gzip-архивирование файлов размером менее 150 байт может действительно увеличить их размер.

> Now I'd like to improve performance by adding caching and compression

Вы можете выполнять сжатие / кеширование через NGINX (+ memcached), который будет очень быстрым. Еще более предпочтительным был бы CDN (для статических файлов), оптимизированный для этой цели. Я не думаю, что вам следует выполнять какое-либо сжатие в node.js, хотя некоторые модули доступны через поиск NPM (ищите gzip), например, https://github.com/saikat/node-gzip

Для кеширования я бы посоветовал вам взглянуть на redis, который работает очень быстро. Это даже будет быстрее, чем большинство клиентских библиотек, потому что в node.js быстрая клиентская библиотека (node_redis) используется hiredis (C). Для этого также важно установить hiredis через npm:

npm install hiredis redis

Некоторые тесты с Hiredis

PING: 20000 ops 46189.38 ops/sec 1/4/1.082
SET: 20000 ops 41237.11 ops/sec 0/6/1.210
GET: 20000 ops 39682.54 ops/sec 1/7/1.257
INCR: 20000 ops 40080.16 ops/sec 0/8/1.242
LPUSH: 20000 ops 41152.26 ops/sec 0/3/1.212
LRANGE (10 elements): 20000 ops 36563.07 ops/sec 1/8/1.363
LRANGE (100 elements): 20000 ops 21834.06 ops/sec 0/9/2.287

> The API calls have unique URLs (e.g. /api/user-id/content) and I want
> to cache them for at least 60 seconds.

Вы можете легко добиться этого кеширования с помощью команды redis setex. Это будет очень быстро.

person Alfred    schedule 11.07.2011
comment
Мой хостер ограничивает диапазон общедоступных портов, и я должен проксировать запросы через установленный Apache, поэтому, к сожалению, nginx для меня не вариант. Но ваш совет был действительно полезным, и я учту его, когда дело доходит до более профессионального проекта (в данном случае это просто небольшой учебный проект для меня). Тем не менее, я немного углублюсь в Redis. Звучит очень многообещающе. - person Frederic; 12.07.2011
comment
@Frederic: Может, захочется посмотреть на другого хоста. У Amazon есть уровень бесплатного пользования. У Rackspace есть VPS от 10 долларов в месяц. У Linode есть даже лучшие (оцененные) за 20 долларов в месяц. В моей книге фильтрация портов - это серьезное запрещение для хостов. - person ; 17.07.2011

arrow_upward
0
arrow_downward

Хорошо, поскольку у моего API есть только очень-очень простое использование, я выберу небольшое хранилище ключей / значений в памяти в качестве базового кеша (на основе вдохновения, которое мне дал Simple Cache). Для этого небольшого эксперимента по развитию этого должно быть достаточно. Для производственного использования API я бы придерживался советов Альфреда.

Для сжатия я буду использовать Apache mod_deflate. Это надежно, и на данный момент мне не нужно асинхронное сжатие. Кроме того, вы можете изменить настройки сжатия, не меняя само приложение.

Спасибо вам обоим за вашу помощь!

person Frederic    schedule 16.07.2011