MT
Size: a a a
2020 June 16
IK
а вообще чатик по нгинксу
то шо гауно я ж не спорю. я спрашиваю как сделать, чтобы было не гауно)
AN
utm метка какая-нибудь.
Реферер внутри метрики.
Масса вариантов.
Реферер внутри метрики.
Масса вариантов.
A
utm метка какая-нибудь.
Реферер внутри метрики.
Масса вариантов.
Реферер внутри метрики.
Масса вариантов.
внутри метрики это по типу перешел без реферера, но на обоих сайтах метрика, которая всё поняла сама?
AN
Да.
Метрика может получать реферер с обоих сайтов, и проматчить переход.
Либо вообще ставить в куку на себя id - уникальную или возрастающую
Метрика может получать реферер с обоих сайтов, и проматчить переход.
Либо вообще ставить в куку на себя id - уникальную или возрастающую
TC
Всем привет))
Прочитал сообщение "чатик про нгинксу", решили сам написать..
На сервак приходит post запрос, где в форм дате лежит текст, тысячи 3 символов...
а nginx на пыху отдает пустой POST....
Может кто знает в чем дело может быть, и куда теряются эти данные
Прочитал сообщение "чатик про нгинксу", решили сам написать..
На сервак приходит post запрос, где в форм дате лежит текст, тысячи 3 символов...
а nginx на пыху отдает пустой POST....
Может кто знает в чем дело может быть, и куда теряются эти данные
AB
Подскажите, пожалуйста, тут подсказали что в проде лучше делать restart nginx, а не reload мол могут быть глюки. Какие могут быть проблемы с релоадом?
TC
а в логах чишо
в постдата тоже пусто...
MT
в постдата тоже пусто...
А в еррор логе?
AN
Подскажите, пожалуйста, тут подсказали что в проде лучше делать restart nginx, а не reload мол могут быть глюки. Какие могут быть проблемы с релоадом?
reload ждет закрытия коннектов к воркерам. В некоторых краевых случаях клиент может не отпускать коннект очень долго - и по факту работать со старой конфигурацией, когда все остальные уже живут с новой.
AN
Отдельно - может быть проблемой, если конфиг поменялся, в релоад отправили - клиенты с условно-бесконечным keepalive все еще висят, а тут приехал очередной апдейт конфига, и релоад запущен еще раз.
AB
Отдельно - может быть проблемой, если конфиг поменялся, в релоад отправили - клиенты с условно-бесконечным keepalive все еще висят, а тут приехал очередной апдейт конфига, и релоад запущен еще раз.
а что в этом случае будет? как-то можно понять применился конфиг полностью или ещё ждет кого-то?
W
Всем привет))
Прочитал сообщение "чатик про нгинксу", решили сам написать..
На сервак приходит post запрос, где в форм дате лежит текст, тысячи 3 символов...
а nginx на пыху отдает пустой POST....
Может кто знает в чем дело может быть, и куда теряются эти данные
Прочитал сообщение "чатик про нгинксу", решили сам написать..
На сервак приходит post запрос, где в форм дате лежит текст, тысячи 3 символов...
а nginx на пыху отдает пустой POST....
Может кто знает в чем дело может быть, и куда теряются эти данные
body_size таймауты, слишком мало инфы, чтоб что то сказать
AN
Что будет - я не знаю, увы. Надо экспериментировать.
Если воркеров в статусте shutting down нет - значит, применилось все.
Если воркеров в статусте shutting down нет - значит, применилось все.
TC
body_size таймауты, слишком мало инфы, чтоб что то сказать
Какую инфу давать?)
Прокси пас на пыху, вот и все
Боди сайз 1000мб
Прокси пас на пыху, вот и все
Боди сайз 1000мб
Y
а что в этом случае будет? как-то можно понять применился конфиг полностью или ещё ждет кого-то?
из практики, на очень highload при использовании websocket три релоада подряд хватало на сжирание всей ОЗУ на сервере со всеми вытекающими.
S
Привет! Можете подсказать? Существует ли возможность сделать следующее:
1. Nginx мониторит запросы
2. Видит запрос особый, который указан н-р в conf файле.
3. Ожидает завершения выполнения этого запроса и выполняет новый запрос, который также указан где-то в conf.
То есть не переадресация, а некий новый запрос после выполнения запроса первого
1. Nginx мониторит запросы
2. Видит запрос особый, который указан н-р в conf файле.
3. Ожидает завершения выполнения этого запроса и выполняет новый запрос, который также указан где-то в conf.
То есть не переадресация, а некий новый запрос после выполнения запроса первого