@akalend21 мар 2011 в 19:47

http_handlersocket_json_module

3 мин

1.8K

Nginx *

+32

Комментарии 52

@Azy 21 мар 2011 в 20:59

Достаточно интересно.
Бенчмарки будут? :)

@akalend 21 мар 2011 в 21:18

1200 запросов в сек — хватит?

@akalend 21 мар 2011 в 21:21

ошибся — всего 600

@Azy 21 мар 2011 в 21:21

600 тоже отлично.

@akalend 22 мар 2011 в 07:19

600 на десктопе при одном потоке
на продакшене (2х4) вполне возможно до 1200

@l0rda 22 мар 2011 в 07:25

имхо очень мало и не понятно на каком железе, у меня nginx+tornado(который работает с hs) делает примерно 1500 запросов/сек на Xeon 3050(2ггц), но и этого мало увы очень 8( при том что сам HS дает очень неплохие результаты

@akalend 26 мар 2011 в 11:08

тестировалось на слабом железе

@zizop 21 мар 2011 в 20:59

ИМХО, думаю на данный момент для автозаполнения полей это лучшее решение.

@Azy 21 мар 2011 в 21:21

Не уверен.
Да, это клево, но программирование на конфиге джинкса вносит дополнительный слой логики, что не хорошо.

@akalend 21 мар 2011 в 21:23

как сказать…

у меня php-фреймворк завязан на логике ngx конфига. Производительность за счет этого довольно-таки высокая. см статью habrahabr.ru/blogs/hi/109050/

@Azy 21 мар 2011 в 21:27

Ага, читал.
Но чем проще тем лучше :)
Все равно спасибо — мало ли когда пригодится.

@akalend 21 мар 2011 в 21:58

все зависит что разрабатываешь. Если визитки — то ни когда не пригодится. Если проекты с притензией посещаемости от 50К, то как выход…

@AndrewStephanoff 21 мар 2011 в 23:23

Тоже спорно. При очень больших нагрузках у вас будет пул серверов за лоад балансером и какой фреймворк выбран окажется второстепенным вопросом; первостепенным будет возможность масштабирования данных в архитектуре приложения.

@akalend 22 мар 2011 в 07:21

и все же есть разница 60 — 80 мс или 20-30 мс
ставим четыре сервера за балансером или два???

@akalend 21 мар 2011 в 21:21

для этого и реализовывалось :)

@baltazorbest 21 мар 2011 в 22:33

поправьте если я не прав, но

CREATE TABLE city

FROM cities

как то не сходятся, правильно будет

FROM city

@o_O_Tync 21 мар 2011 в 22:39

догодаться

Это просто невыносимо! :)

@AndrewStephanoff 21 мар 2011 в 23:47

а как вам

параметры коннекции

@neanton 22 мар 2011 в 01:49

там в гите тоже приколы

must to configure

can to use

can to increase

@akalend 22 мар 2011 в 07:59

есть желание помочь проекту — двери всегда открыты

@akalend 22 мар 2011 в 08:00

кинь мыло, я добавлю тебя в гит, напишешь хороший README

@majesty 22 мар 2011 в 02:43

«параметры коннекции» доставили. слово «соединение» забыли, да?

@akalend 22 мар 2011 в 07:11

поправлю — спасибо

@liaren 22 мар 2011 в 05:49

А можете привести пример как выполнить 2 запроса к базе? Имеются введу запросы, в которых параметры второго зависят от того, что вернёт первый. Например, надо получить список документов пользователя:
1. SELECT user_id по session_id из COOKIES
2. SELECT документов по user_id полученном в предыдущем запросе

@akalend 22 мар 2011 в 07:25

на каждый запрос к БД свой запрос по HTTP
тут без кода на клиенте (js) не обойтись

@liaren 22 мар 2011 в 07:29

Описанную ситуацию невозможно решить при помощи js кода на клиента, тут так или иначе надо на стороне сервера выполнять 2 последовательных запроса.

Очень жаль, что нет поддержки такого функционала. Это вносит серьёзные ограничения в плане использования модуля. Может всё-таки возможно как-то добавить эту функциональность? Был бы вам очень благодарен!

@akalend 22 мар 2011 в 07:45

возможно но надо подумать как

@akalend 22 мар 2011 в 08:01

но есть более первоочередные задачи по проекту

@liaren 22 мар 2011 в 08:05

Я по этому поводу создал issue на GitHub: github.com/akalend/ngx_http_handlersocket_json_module/issues/1

@akalend 22 мар 2011 в 10:50

спасибо

@akalend 22 мар 2011 в 11:05

там нужно иметь приблизительно такой конфиг:
hs_json_sub_fieldlist
hs_json_sub_table
hs_json_sub_index
hs_json_sub_op

При использовании subrequest — limit фвтоматически =1

@Demetros 22 мар 2011 в 06:21

Я правильно понимаю, что нет постоянных соединений с базой и на каждый запрос от клиента устанавливается соединение с базой, затем непосредственно выполняется запрос, затем соединение с базой закрывается? Не вижу в коде закрытия соединения…

Вся работа с базой судя по всему происходит в блокирующем режиме?

@akalend 22 мар 2011 в 07:14

да, на каждый запрос свое соединение, так надежней.

@akalend 22 мар 2011 в 07:17

работа с БД в блокирующем режиме,
но так же реализованы модули memcached & redis (см их исходники).
не вижу необходимости усложнения.

@Demetros 22 мар 2011 в 07:31

Насколько я знаю, «родной» ngx_http_memcached_module работает в асинхронном режиме с использованием upstream-функционала nginx'а.
А то, что всякие поделки работают в блокирующем режиме лишь означает, что их не стоит серьезно рассматривать как кандидатов в production серьезных проектов.

@akalend 22 мар 2011 в 07:46

на сяет редиса и мемкеша ступил — там сделано через апстрим

@akalend 22 мар 2011 в 07:55

я думал, как сделать upstream — но не получается, из-за того что нужно формировать JSON, т.е. обработать каждую «запись» в цикле,
а не отдавать все напрямую по одному ключу, как это реализовано в модуле memcached или редис.

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

что касается неблокирующего в/в — то я этот вопрос проработаю, спасибо за идею. Спасибо что заглянули в исходники.

@Demetros 22 мар 2011 в 08:15

Я думаю, идеи можно почерпнуть из уже имеющихся модулей тут (например Postgres-модуль, хотя его исходники не смотрел).

@akalend 22 мар 2011 в 10:50

посмотрю, спасибо

@akalend 22 мар 2011 в 15:04

глянул быстрым взглядом, кой что можно взять, спасибо

@akalend 22 мар 2011 в 07:58

если будет неблокирующий режим, то можно держать постоянное соединение с базой. Открываем на этапе запуска, закрываем при перезагрузки. Скорость обмена возрастет — это несомненно.

@Demetros 22 мар 2011 в 08:21

Возможно, лучшим вариантом будет использование модуля HttpUpstreamKeepaliveModule

@akalend 22 мар 2011 в 10:52

изучу, но чуть позже
я смотрел исходники этого модуля,

@Horzerus 22 мар 2011 в 06:34

А отлов инъекций только регулярный выражением в location?
Или подставляемое значение в запрос проходит Фильтруется через какую-нибудь real_escape_string()?

Спасибо