Pull to refresh

Comments 52

Достаточно интересно.
Бенчмарки будут? :)
1200 запросов в сек — хватит?
600 тоже отлично.
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
догодаться

Это просто невыносимо! :)
там в гите тоже приколы

must to configure
can to use
can to increase
есть желание помочь проекту — двери всегда открыты
кинь мыло, я добавлю тебя в гит, напишешь хороший README
«параметры коннекции» доставили. слово «соединение» забыли, да?
А можете привести пример как выполнить 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()?

Спасибо
Извините за ошибки — я с телефона
каких инъекций?
приведи мне пример хоть одной инъекции в HS?
Изучил HS, вопрос отпал, спасибо!
Программист на Nginx )))

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