Comments 52
600 на десктопе при одном потоке
на продакшене (2х4) вполне возможно до 1200
имхо очень мало и не понятно на каком железе, у меня nginx+tornado(который работает с hs) делает примерно 1500 запросов/сек на Xeon 3050(2ггц), но и этого мало увы очень 8( при том что сам HS дает очень неплохие результаты
ИМХО, думаю на данный момент для автозаполнения полей это лучшее решение.
Не уверен.
Да, это клево, но программирование на конфиге джинкса вносит дополнительный слой логики, что не хорошо.
как сказать…

у меня php-фреймворк завязан на логике ngx конфига. Производительность за счет этого довольно-таки высокая. см статью habrahabr.ru/blogs/hi/109050/
Ага, читал.
Но чем проще тем лучше :)
Все равно спасибо — мало ли когда пригодится.
все зависит что разрабатываешь. Если визитки — то ни когда не пригодится. Если проекты с притензией посещаемости от 50К, то как выход…
Тоже спорно. При очень больших нагрузках у вас будет пул серверов за лоад балансером и какой фреймворк выбран окажется второстепенным вопросом; первостепенным будет возможность масштабирования данных в архитектуре приложения.
и все же есть разница 60 — 80 мс или 20-30 мс
ставим четыре сервера за балансером или два???
поправьте если я не прав, но
CREATE TABLE city

и
FROM cities


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

FROM city
«параметры коннекции» доставили. слово «соединение» забыли, да?
А можете привести пример как выполнить 2 запроса к базе? Имеются введу запросы, в которых параметры второго зависят от того, что вернёт первый. Например, надо получить список документов пользователя:
1. SELECT user_id по session_id из COOKIES
2. SELECT документов по user_id полученном в предыдущем запросе
на каждый запрос к БД свой запрос по HTTP
тут без кода на клиенте (js) не обойтись
Описанную ситуацию невозможно решить при помощи js кода на клиента, тут так или иначе надо на стороне сервера выполнять 2 последовательных запроса.

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

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

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

Вся работа с базой судя по всему происходит в блокирующем режиме?
работа с БД в блокирующем режиме,
но так же реализованы модули memcached & redis (см их исходники).
не вижу необходимости усложнения.
Насколько я знаю, «родной» ngx_http_memcached_module работает в асинхронном режиме с использованием upstream-функционала nginx'а.
А то, что всякие поделки работают в блокирующем режиме лишь означает, что их не стоит серьезно рассматривать как кандидатов в production серьезных проектов.
я думал, как сделать upstream — но не получается, из-за того что нужно формировать JSON, т.е. обработать каждую «запись» в цикле,
а не отдавать все напрямую по одному ключу, как это реализовано в модуле memcached или редис.

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

что касается неблокирующего в/в — то я этот вопрос проработаю, спасибо за идею. Спасибо что заглянули в исходники.
Я думаю, идеи можно почерпнуть из уже имеющихся модулей тут (например Postgres-модуль, хотя его исходники не смотрел).
если будет неблокирующий режим, то можно держать постоянное соединение с базой. Открываем на этапе запуска, закрываем при перезагрузки. Скорость обмена возрастет — это несомненно.
А отлов инъекций только регулярный выражением в location?
Или подставляемое значение в запрос проходит Фильтруется через какую-нибудь real_escape_string()?

Спасибо
Программист на Nginx )))

А вообще то, что запросы выполняются в блокирующем режиме это конечно эпик фейл…
УГ какое-то. Приложение потеряет целостность. Давайте тогда сразу всё перепишем в виде модуля к nginx…
Only those users with full accounts are able to leave comments. Log in, please.