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

akalend Mar 26 2011 at 11:08

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

zizop Mar 21 2011 at 20:59

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

Azy Mar 21 2011 at 21:21

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

akalend Mar 21 2011 at 21:23

как сказать…

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

Azy Mar 21 2011 at 21:27

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

akalend Mar 21 2011 at 21:58

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

AndrewStephanoff Mar 21 2011 at 23:23

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

akalend Mar 22 2011 at 07:21

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

akalend Mar 21 2011 at 21:21

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

baltazorbest Mar 21 2011 at 22:33

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

CREATE TABLE city

FROM cities

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

FROM city

o_O_Tync Mar 21 2011 at 22:39

догодаться

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

AndrewStephanoff Mar 21 2011 at 23:47

а как вам

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

neanton Mar 22 2011 at 01:49

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

must to configure

can to use

can to increase

akalend Mar 22 2011 at 07:59

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

akalend Mar 22 2011 at 08:00

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

majesty Mar 22 2011 at 02:43

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

akalend Mar 22 2011 at 07:11

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

liaren Mar 22 2011 at 05:49

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

akalend Mar 22 2011 at 07:25

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

liaren Mar 22 2011 at 07:29

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

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

akalend Mar 22 2011 at 07:45

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

akalend Mar 22 2011 at 08:01

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

liaren Mar 22 2011 at 08:05

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

akalend Mar 22 2011 at 10:50

спасибо

akalend Mar 22 2011 at 11:05

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

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

Demetros Mar 22 2011 at 06:21

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

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

akalend Mar 22 2011 at 07:14

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

akalend Mar 22 2011 at 07:17

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

Demetros Mar 22 2011 at 07:31

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

akalend Mar 22 2011 at 07:46

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

akalend Mar 22 2011 at 07:55

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

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

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

Demetros Mar 22 2011 at 08:15

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

akalend Mar 22 2011 at 10:50

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

akalend Mar 22 2011 at 15:04

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

akalend Mar 22 2011 at 07:58

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

Demetros Mar 22 2011 at 08:21

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

akalend Mar 22 2011 at 10:52

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

Horzerus Mar 22 2011 at 06:34

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

Спасибо