ударится разок током и поймет, все так делали

если его при этом не замкнет что не сможет освободиться

у меня и желания в розетку палец засунуть не было

если его при этом не замкнет что не сможет освободиться

кучу раз било током 220, вроде не умер

какие нить 12 вольт не смертельны, но не докажут что это опасно да.

мож он наоборот от тока кайфовать начнёт после таких процедур

кучу раз било током 220, вроде не умер

главное одной рукой с ним работать?

в детстве от бп денди било часто ?

в детстве от бп денди било часто ?

рофл

щас тоже иногда бьет когда неосторожно с проводкой работаю, но это редко бывает, раз в 5 лет наверное )

ты хотя бы с проводкой работаешь.

так не профессионально, розетку там поменять или выключатель света

Прежде технику безопасности надо объяснять в любом деле. А уже потом им заниматься. Почему ребенку не объяснили что розетки это смертельная опасность? Откуда ему знать если вы не расскажите.

мне рано объяснили закон Ома, и сопротивление тела?

опа, удалили спамера?

опа, удалили спамера?

Ну а смотреть на него что ли?

просто никогда не удаляли

Ну я просмотрел чяд за выхи. Там большинство ботов уже забанены.

Уважаемые погромисты, скажите пожалуйста, как решить 504 Gateway bad request? В nginx.conf в блоке http добавил блок server с временем (proxy...) не помогает, все равно время ожидания одна минута.

Уважаемые погромисты, скажите пожалуйста, как решить 504 Gateway bad request? В nginx.conf в блоке http добавил блок server с временем (proxy...) не помогает, все равно время ожидания одна минута.

проверить что бэкенд на который он стучится действительно работает

настроить nginx_debug и error_log path debug; и смотреть от и до почему не пашет

Уважаемые погромисты, скажите пожалуйста, как решить 504 Gateway bad request? В nginx.conf в блоке http добавил блок server с временем (proxy...) не помогает, все равно время ожидания одна минута.

это уже не с таймаутом связано судя по ошибке

Ошибся с bad request, а на самом деле timeout

Ошибся с bad request, а на самом деле timeout

так бэкенд нормально отвечает или нет?

так бэкенд нормально отвечает или нет?

Просто процессы работают долго, а у приложение как бы стоит ограничение на обратный ответ (1 минута)

Просто процессы работают долго, а у приложение как бы стоит ограничение на обратный ответ (1 минута)

дык уберите в очередь

и проверяйте статус в очереди

и проверяйте статус в очереди

??? Мне надо просто увеличить время ожидание

так поставь таймаут выше в nginx

или что там, puma

смотря кто вылетает

У меня nginx и puma

У меня nginx и puma

а по таймауту кто из них вылетает?

а по таймауту кто из них вылетает?

Как узнать?

Как узнать?

запросить бэкенд напрямую и посмотреть отдаст он данные или улетит в таймаут?

запросить бэкенд напрямую и посмотреть отдаст он данные или улетит в таймаут?

Отдаёт таймаут

Отдаёт таймаут

https://github.com/puma/puma/blob/master/examples/config.rb#L179 Первая ссылка в гугле :)

А если не отдаёт таймаут?

А если не отдаёт таймаут?

что?

хоспади, что такое puma знаешь? ) что такое nginx знаешь? )

как оно работает знаешь?

логика же простая, есть nginx который проксирует запрос на бэкенд. Смотришь кто вылатает по таймауту первый.

И настраиваешь

Спасибо. "Мы вам перезвоним"

они кстати оба по таймауту могут вылетать, настроишь один, а оказажется что теперь другой по своему вылетает.

Вот на локальном не вылетает ничего (в puma.rb нет речи о timeout), а на сервере да

ну и смотришь на сервере кто из них вылетает

ну и смотришь на сервере кто из них вылетает

А как быть если скрипт будет работать 30 мин, а увеличивать таймауты на большое время не хорошее дело?

Просто процессы работают долго, а у приложение как бы стоит ограничение на обратный ответ (1 минута)

дык уберите в очередь

и проверяйте статус в очереди

??? Мне надо просто увеличить время ожидание

хочешь сделать нормально - выноси в очередь

sidekiq например

sidekiq например

Это для тех задач, у кого нет ответа.

Это для тех задач, у кого нет ответа.

с чего бы это?

https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D0%BA%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D1%8F_HTTP 102, 202

делаешь в базе статус "в обработке" и пускай клиент периодически дергает статус задачи

если не в обработке то получит конкретные данные.

Sidekiq для отложенных задач, а не тех у которых нет ответа. Кроме того не зная твой кейс сложно что то адекватное посоветовать.

Кроме него есть еще delayed job (вроде) который не требует редиса и работает через базу

Правильно говоришь

поцоны, как тестят фикс вот такой ошибки: PG::QueryCanceled: ERROR: canceling statement due to statement timeout Запрос затаймаутился из-за слишком большого числа удаляемых штук

я знаю как пофиксить (через батчи), но как это тестить? убеждаться что удаляешь батчами?

или есть какие-то финты ушами

в идеале тест должен воспроизводить баг с прода, типа должен быть тест с большим числом этих штук

но наверное будет долго это исполняться

я знаю как пофиксить (через батчи), но как это тестить? убеждаться что удаляешь батчами?

потестить что оно удалилось. Если при этом будет exception то тест сломается так и так

вот тоже хз как батчи тестить

потестить что оно удалилось. Если при этом будет exception то тест сломается так и так

но типа создавать дохуя записей каждый раз в тестах ваще не оч

кстати в доках такое увидел Person.where("age > 21").in_batches do |relation| relation.delete_all sleep(10) # Throttle the delete queries end

Есть смысл в троттлинге?

базу не перегружать и дать поработать другим запросам?

понятно спс

это предложение

просто такой батч потенциально может подтормозить базу и мешать другим запросам

короче создал вопрос на стаковерфлоу: https://stackoverflow.com/questions/52481196/how-to-test-pgquerycanceled-due-to-timeout-error-in-a-rails-app

короче создал вопрос на стаковерфлоу: https://stackoverflow.com/questions/52481196/how-to-test-pgquerycanceled-due-to-timeout-error-in-a-rails-app

а зачем такое тестить?

проблема же в том, что данных много

ну баг на проде надо тестами покрывать по идее

ну да

ну так ты сейчас работу in_batches хочешь проверить?

ты тестируешь тогда поведение своей аппликухи при больших данных

ну я и не знаю как надо

I would argue that you are only using Rails' methods and therefore should not test them. Especially because none of the methods actually fixes or avoids the exception. in_batches only makes the exception less likely to occur.

ну в моём виденьи это должно быть что-то типа тяжелого теста, который запускается только когда все остальные отработают

ну так ты сейчас работу in_batches хочешь проверить?

нет, я хочу чтобы при делите больших данных не падал запрос

нет, я хочу чтобы при делите больших данных не падал запрос

почему не вынести такую операцию в очередь?

ну там sql запрос тупо по таймауту отлетает

я его разбил на меньшие с помощью in_batches

вот, но мне кажется надо все равно как-то протестить что больше не отлетает вся эта фигня по таймауту

вот

интересно, как это делают те, кто занимается хуйлоадом

на всякой scala и т.д.

интересно, как это делают те, кто занимается хуйлоадом

другим уровнем тестирования

нагрузочное тестирование, не через rspec

ааа

и это включено в ci?

хз как где настроено

но highload и не крутится на обычных ci я так думаю