Должен ли я подключаться напрямую к сокету CouchDB и передавать HTTP-запросы или использовать node.js в качестве прокси? - PullRequest
Новая
       6

Должен ли я подключаться напрямую к сокету CouchDB и передавать HTTP-запросы или использовать node.js в качестве прокси?

14 голосов
/ 01 сентября 2010

Во-первых, вот мой оригинальный вопрос, который породил все это .

Я использую Appcelerator Titanium для разработки приложения для iPhone (в конечном итоге и для Android).Я подключаюсь к порту CouchDB напрямую, используя объект Titanium * Titanium.Network.TCPSocket .Я считаю он использует класс Apple SDK CFSocket / NSStream.

После подключения я просто пишу:

'GET /mydb/_changes?filter=app/myfilter&feed=continuous&gameid=4&heartbeat=30000 HTTP/1.1\r\n\r\n'

прямо в сокет,Он сохраняет его открытым "навсегда" и возвращает данные JSON всякий раз, когда БД обновляется и соответствует фильтру и запросу на изменение.Круто.

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

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

1 Ответ

13 голосов
/ 01 сентября 2010

Это снова я.: -)

CouchDB наследует обработку супер-параллелизма от языка Erlang, на котором он был написан. Erlang использует легкие процессы и передачу сообщений между этими процессами для достижения превосходной производительности при высокой одновременной нагрузке.Он также использует все ядра процессора.

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

Оба должны легко обрабатывать десятки тысяч соединений, ноЯ ожидаю, что CouchDB будет обрабатывать параллелизм лучше (и с меньшими усилиями с вашей стороны), чем Node.И имейте в виду, что Node добавляет некоторую задержку, если вы поместите его перед CouchDB.Это может быть заметно только в том случае, если они у вас на разных компьютерах.

Запись напрямую в Couch через TCPSocket - это нормально, если вы пишете правильно сформированный HTTP-запрос, соответствующий спецификации.(Вы не передаете ложный запрос ... это настоящий HTTP-запрос, который вы отправляете, как и любой другой.)

Примечание: HTTP 1.1 требует, чтобы вы включили заголовок Host в запрос, поэтомувам нужно исправить свой код, чтобы отразить это ИЛИ просто использовать HTTP 1.0, который не требует простоты.(Мне любопытно, почему вы не используете Titanium.Network.HTTPClient. Выдает ли он тело запроса только после того, как запрос завершен или что-то в этом роде?)

В любом случае, CouchDB может полностью обрабатывать прямые соединения и -если вы не приложите много усилий к своему прокси-серверу Node - это, вероятно, даст пользователям лучший опыт, когда у вас есть 100 000 человек, играющих в игру одновременно.

РЕДАКТИРОВАТЬ: Если вы используете Node, напишите реальный HTTPпрокси.Это будет работать намного быстрее, чем при использовании предоставленного вами модуля, и будет проще в реализации.(Вместо того, чтобы определять свой собственный API, который затем отправляет запросы в Couch, вы можете просто передать определенные запросы в CouchDB и заблокировать другие, скажем, по соображениям безопасности.

Также посмотрите, как работает «мультиузел»: http://www.sitepen.com/blog/2010/07/14/multi-node-concurrent-nodejs-http-server/

...