MT
Size: a a a
2020 June 11
SZ
сек, ща попробую
SZ
Получил следующею ошибку:
nginx: [emerg] "proxy_pass" cannot have URI part in location given by regular expression, or inside named location, or inside "if" statement, or inside "limit_except"
nginx: [emerg] "proxy_pass" cannot have URI part in location given by regular expression, or inside named location, or inside "if" statement, or inside "limit_except"
Y
скажите, а сколько nginx может обрабатывать запросов в секунду для множества( десятки тысяч ) небольших json респонсов, все они кэшируются?
вопрос вот откуда: текущая архитектура предполагает, что хтмл клиент будет делать поисковой запрос к серверу, а сервер отвечать длинным( 100+ ) списком айдишников объектов. После этого клиент каждый из этих документов отдельно запрашивает по айди. А nginx кэширует все эти документы. Архитектор говорит, что не смотря на то, что у браузера есть ограничение в 6 одновременных запросов к серверу и нам нужен поллинг каждые 3 секунды, так как все объекты небольшие, это нормально делать по 100 запросов к серверу каждые 3 секунды. Мол кэш nginx легко такое держит для сотен клиентов. Верно ли я понимаю, что все нормально с таким решением или есть хитрые подводные камни?
вопрос вот откуда: текущая архитектура предполагает, что хтмл клиент будет делать поисковой запрос к серверу, а сервер отвечать длинным( 100+ ) списком айдишников объектов. После этого клиент каждый из этих документов отдельно запрашивает по айди. А nginx кэширует все эти документы. Архитектор говорит, что не смотря на то, что у браузера есть ограничение в 6 одновременных запросов к серверу и нам нужен поллинг каждые 3 секунды, так как все объекты небольшие, это нормально делать по 100 запросов к серверу каждые 3 секунды. Мол кэш nginx легко такое держит для сотен клиентов. Верно ли я понимаю, что все нормально с таким решением или есть хитрые подводные камни?
AN
На более-менее среднем железе нет никаких проблем отдать порядка полумиллиона закэшированных файлов.
AD
скажите, а сколько nginx может обрабатывать запросов в секунду для множества( десятки тысяч ) небольших json респонсов, все они кэшируются?
вопрос вот откуда: текущая архитектура предполагает, что хтмл клиент будет делать поисковой запрос к серверу, а сервер отвечать длинным( 100+ ) списком айдишников объектов. После этого клиент каждый из этих документов отдельно запрашивает по айди. А nginx кэширует все эти документы. Архитектор говорит, что не смотря на то, что у браузера есть ограничение в 6 одновременных запросов к серверу и нам нужен поллинг каждые 3 секунды, так как все объекты небольшие, это нормально делать по 100 запросов к серверу каждые 3 секунды. Мол кэш nginx легко такое держит для сотен клиентов. Верно ли я понимаю, что все нормально с таким решением или есть хитрые подводные камни?
вопрос вот откуда: текущая архитектура предполагает, что хтмл клиент будет делать поисковой запрос к серверу, а сервер отвечать длинным( 100+ ) списком айдишников объектов. После этого клиент каждый из этих документов отдельно запрашивает по айди. А nginx кэширует все эти документы. Архитектор говорит, что не смотря на то, что у браузера есть ограничение в 6 одновременных запросов к серверу и нам нужен поллинг каждые 3 секунды, так как все объекты небольшие, это нормально делать по 100 запросов к серверу каждые 3 секунды. Мол кэш nginx легко такое держит для сотен клиентов. Верно ли я понимаю, что все нормально с таким решением или есть хитрые подводные камни?
расскажите архитектору что HTTP/2 давно уже на дворе
Y
Мне немного непонятно, имеются у варианта описанного выше проблемы или так и нужно правильно делать? Просто мне всегда казалось, что лучше взять и все данные передать за один запрос. Если ответ получается слишком велик, можно его разбить. Также есть вопрос будет ли выше нагрузка на сеть, учитывая, что много клиентов постоянно кучей запросов, пусть и супер-легковесных спамят постоянно?
AN
Мне немного непонятно, имеются у варианта описанного выше проблемы или так и нужно правильно делать? Просто мне всегда казалось, что лучше взять и все данные передать за один запрос. Если ответ получается слишком велик, можно его разбить. Также есть вопрос будет ли выше нагрузка на сеть, учитывая, что много клиентов постоянно кучей запросов, пусть и супер-легковесных спамят постоянно?
Однозначного ответа нет.
Сильно зависит от того, как устроены потоки данных.
Когда-то правильно паковать все в один запрос/ответ.
Когда-то - строго наоборот
Сильно зависит от того, как устроены потоки данных.
Когда-то правильно паковать все в один запрос/ответ.
Когда-то - строго наоборот
AN
Где почитать - не скажу, ибо не знаю.
А зависит - ну например если каждый блок данных дальше на клиенте как-то парсится - независимо - то чем быстрее в сторону клиента чанки вылетят, тем быстрее рендер закончится. Имеет смысл плевать поштучно, по готовности.
Если же данные в чанках зависимые - то выдавать одной кучей разумнее
А зависит - ну например если каждый блок данных дальше на клиенте как-то парсится - независимо - то чем быстрее в сторону клиента чанки вылетят, тем быстрее рендер закончится. Имеет смысл плевать поштучно, по готовности.
Если же данные в чанках зависимые - то выдавать одной кучей разумнее
И
Коллеги, помогите чем смогите
И
И
такое происходит при обновлении страницы
И
И
такое при первом залогиниваании и гулянию по вкладкам сайта
И
но при f5 белый лист лог в image.png
И
как описать location чтобы при f5 оно тоже шло на прокси и брало данные из конкретного пути
И
я так понял что нужно идти за данными POST ом