Comments 52
Достаточно интересно.
Бенчмарки будут? :)
Бенчмарки будут? :)
+1
1200 запросов в сек — хватит?
0
ошибся — всего 600
0
600 тоже отлично.
0
600 на десктопе при одном потоке
на продакшене (2х4) вполне возможно до 1200
на продакшене (2х4) вполне возможно до 1200
0
имхо очень мало и не понятно на каком железе, у меня nginx+tornado(который работает с hs) делает примерно 1500 запросов/сек на Xeon 3050(2ггц), но и этого мало увы очень 8( при том что сам HS дает очень неплохие результаты
0
ИМХО, думаю на данный момент для автозаполнения полей это лучшее решение.
0
Не уверен.
Да, это клево, но программирование на конфиге джинкса вносит дополнительный слой логики, что не хорошо.
Да, это клево, но программирование на конфиге джинкса вносит дополнительный слой логики, что не хорошо.
+2
как сказать…
у меня php-фреймворк завязан на логике ngx конфига. Производительность за счет этого довольно-таки высокая. см статью habrahabr.ru/blogs/hi/109050/
у меня php-фреймворк завязан на логике ngx конфига. Производительность за счет этого довольно-таки высокая. см статью habrahabr.ru/blogs/hi/109050/
0
Ага, читал.
Но чем проще тем лучше :)
Все равно спасибо — мало ли когда пригодится.
Но чем проще тем лучше :)
Все равно спасибо — мало ли когда пригодится.
0
все зависит что разрабатываешь. Если визитки — то ни когда не пригодится. Если проекты с притензией посещаемости от 50К, то как выход…
0
Тоже спорно. При очень больших нагрузках у вас будет пул серверов за лоад балансером и какой фреймворк выбран окажется второстепенным вопросом; первостепенным будет возможность масштабирования данных в архитектуре приложения.
+3
и все же есть разница 60 — 80 мс или 20-30 мс
ставим четыре сервера за балансером или два???
ставим четыре сервера за балансером или два???
+1
для этого и реализовывалось :)
0
поправьте если я не прав, но
и
как то не сходятся, правильно будет
CREATE TABLE city
и
FROM cities
как то не сходятся, правильно будет
FROM city
0
догодаться
Это просто невыносимо! :)
+1
«параметры коннекции» доставили. слово «соединение» забыли, да?
0
А можете привести пример как выполнить 2 запроса к базе? Имеются введу запросы, в которых параметры второго зависят от того, что вернёт первый. Например, надо получить список документов пользователя:
1. SELECT user_id по session_id из COOKIES
2. SELECT документов по user_id полученном в предыдущем запросе
1. SELECT user_id по session_id из COOKIES
2. SELECT документов по user_id полученном в предыдущем запросе
0
на каждый запрос к БД свой запрос по HTTP
тут без кода на клиенте (js) не обойтись
тут без кода на клиенте (js) не обойтись
0
Описанную ситуацию невозможно решить при помощи js кода на клиента, тут так или иначе надо на стороне сервера выполнять 2 последовательных запроса.
Очень жаль, что нет поддержки такого функционала. Это вносит серьёзные ограничения в плане использования модуля. Может всё-таки возможно как-то добавить эту функциональность? Был бы вам очень благодарен!
Очень жаль, что нет поддержки такого функционала. Это вносит серьёзные ограничения в плане использования модуля. Может всё-таки возможно как-то добавить эту функциональность? Был бы вам очень благодарен!
0
возможно но надо подумать как
0
но есть более первоочередные задачи по проекту
0
Я по этому поводу создал issue на GitHub: github.com/akalend/ngx_http_handlersocket_json_module/issues/1
0
Я правильно понимаю, что нет постоянных соединений с базой и на каждый запрос от клиента устанавливается соединение с базой, затем непосредственно выполняется запрос, затем соединение с базой закрывается? Не вижу в коде закрытия соединения…
Вся работа с базой судя по всему происходит в блокирующем режиме?
Вся работа с базой судя по всему происходит в блокирующем режиме?
0
да, на каждый запрос свое соединение, так надежней.
0
работа с БД в блокирующем режиме,
но так же реализованы модули memcached & redis (см их исходники).
не вижу необходимости усложнения.
но так же реализованы модули memcached & redis (см их исходники).
не вижу необходимости усложнения.
0
Насколько я знаю, «родной» ngx_http_memcached_module работает в асинхронном режиме с использованием upstream-функционала nginx'а.
А то, что всякие поделки работают в блокирующем режиме лишь означает, что их не стоит серьезно рассматривать как кандидатов в production серьезных проектов.
А то, что всякие поделки работают в блокирующем режиме лишь означает, что их не стоит серьезно рассматривать как кандидатов в production серьезных проектов.
+2
на сяет редиса и мемкеша ступил — там сделано через апстрим
0
я думал, как сделать upstream — но не получается, из-за того что нужно формировать JSON, т.е. обработать каждую «запись» в цикле,
а не отдавать все напрямую по одному ключу, как это реализовано в модуле memcached или редис.
год назад я пытался написать модуль redis_json_module (забирать не по GET а по POP) как upstream, но у меня так и не вышло. Возможно обработать лишь одну итерацию и невозможно сформировать рекордсет. А может я что-то делал не так, нет хороших учителей.
что касается неблокирующего в/в — то я этот вопрос проработаю, спасибо за идею. Спасибо что заглянули в исходники.
а не отдавать все напрямую по одному ключу, как это реализовано в модуле memcached или редис.
год назад я пытался написать модуль redis_json_module (забирать не по GET а по POP) как upstream, но у меня так и не вышло. Возможно обработать лишь одну итерацию и невозможно сформировать рекордсет. А может я что-то делал не так, нет хороших учителей.
что касается неблокирующего в/в — то я этот вопрос проработаю, спасибо за идею. Спасибо что заглянули в исходники.
+1
если будет неблокирующий режим, то можно держать постоянное соединение с базой. Открываем на этапе запуска, закрываем при перезагрузки. Скорость обмена возрастет — это несомненно.
0
Возможно, лучшим вариантом будет использование модуля HttpUpstreamKeepaliveModule
0
А отлов инъекций только регулярный выражением в location?
Или подставляемое значение в запрос проходит Фильтруется через какую-нибудь real_escape_string()?
Спасибо
Или подставляемое значение в запрос проходит Фильтруется через какую-нибудь real_escape_string()?
Спасибо
0
Программист на Nginx )))
А вообще то, что запросы выполняются в блокирующем режиме это конечно эпик фейл…
А вообще то, что запросы выполняются в блокирующем режиме это конечно эпик фейл…
0
УГ какое-то. Приложение потеряет целостность. Давайте тогда сразу всё перепишем в виде модуля к nginx…
0
Sign up to leave a comment.
http_handlersocket_json_module