Nik
Народ, если мне нужен SortedSet или просто очередь внутри приложении, есть чтонить стандартное? (пока пытаюсь понять, что происходит внутри container/heap)
Daniel
очередь? это не канал ли буферизованный?
a set - нету, надо колхозить свою имплементацию на map
Nik
вот я тоже думаю сбоку в сторону буферезированного коанала. думаю, не напорюсь ли я на блокировку подороге
Nik
Колходжить над map - плохо, потому что оно будет медленно
Nik
(вообще не понимаю, почему есть только HashMap, а остальное лесом выкинули)
Daniel
naim
Коллеги, подскажите платный онлайн курс для advanced уровня админов по тематике DevOps/GO . Спасибо
Nik
это кто сказал?
ну например, у меня сортедмап, с интами. и я хочу флашнуть все что младше определенного числа. На хешмапе - это куча фуллсканов
Zver
вот я тоже думаю сбоку в сторону буферезированного коанала. думаю, не напорюсь ли я на блокировку подороге
Если буфер заполнится, то пихальщик в канал остановится.
Daniel
Если буфер заполнится, то пихальщик в канал остановится.
если у нас буфер достаточно большой, и переполнился - это повод для паники, вообще-то
Daniel
ну например, у меня сортедмап, с интами. и я хочу флашнуть все что младше определенного числа. На хешмапе - это куча фуллсканов
один ровно, для получения ключей.
Nik
один ровно, для получения ключей.
Фулсканом вытащить все ключи, отсортировать, и потом килять пловину?
Nik
это чуть лучше чем. ясебе представлял
Nik
но все равно страшно
Aleksey
Нужно это дело забенчмаркать
Уже проходили:
https://github.com/Supme/gonder/blob/master/api/recipients.go#L541
Тут список в тыщ 50 строк с параметрами, без подготовки запросов грузит минут 20, с подготовкой секунд 15
Мерль
Daniel
Уже проходили:
https://github.com/Supme/gonder/blob/master/api/recipients.go#L541
Тут список в тыщ 50 строк с параметрами, без подготовки запросов грузит минут 20, с подготовкой секунд 15
чет я в это не верю. prepare такого смешного запроса не может занимать 1985 секунд
Daniel
а! я неоднократно пробовал показывать. не понимают-с. дикари-с.
Aleksey
Vladimir
а! я неоднократно пробовал показывать. не понимают-с. дикари-с.
Ну вроде понял. К тому же я вроде бы не далек от истины в своих спекуляциях
Aleksey
чет я в это не верю. prepare такого смешного запроса не может занимать 1985 секунд
Там два запроса, один выполняется по количеству строк, второй количество строк умноженное на количество параметров
Aleksey
я бы глянул на код без prepare для начала
https://github.com/Supme/gonder/commit/74c333a1e3373bc254a557248b965a1ff5898e61#diff-26c6a333209552b6b6f6cef1dc42fe8e
Aleksey
Первая версия
Michael
В het/http есть функция плавного завершения https://golang.org/pkg/net/http/#Server.Shutdown . Как бы предполагается, что мы хотим закончить обслуживать все имеющиеся соединения и только потом выйти. Но вот вопрос: как при этом запустить другой процесс, который бы принимал новые соединения?
Есть ли либы, позволяющие запускаться на том же порту новому процессу, а старому ещё долго (часы) продолжать обслуживать старые соединения?
Илья
так у вас транзакции не было
Илья
😮
Anonymous
В het/http есть функция плавного завершения https://golang.org/pkg/net/http/#Server.Shutdown . Как бы предполагается, что мы хотим закончить обслуживать все имеющиеся соединения и только потом выйти. Но вот вопрос: как при этом запустить другой процесс, который бы принимал новые соединения?
Есть ли либы, позволяющие запускаться на том же порту новому процессу, а старому ещё долго (часы) продолжать обслуживать старые соединения?
Ну, или смотреть в сторону master/slave архитектуры
Michael
Ну, или смотреть в сторону master/slave архитектуры
А как это решит проблему невозможности слушать на том же порту?
Aleksey
чет я в это не верю. prepare такого смешного запроса не может занимать 1985 секунд
Тут дело такое: простое query это тоже подготовка запроса и потом запуск с переданными параметрами. База при подготовке запроса интерпритирует его себе, готовит план выполнения, потом мы просто передаём данные э этому
Andrey
В het/http есть функция плавного завершения https://golang.org/pkg/net/http/#Server.Shutdown . Как бы предполагается, что мы хотим закончить обслуживать все имеющиеся соединения и только потом выйти. Но вот вопрос: как при этом запустить другой процесс, который бы принимал новые соединения?
Есть ли либы, позволяющие запускаться на том же порту новому процессу, а старому ещё долго (часы) продолжать обслуживать старые соединения?
предполагается, что у вас веб сервисы за лоадбалансером. Процедура такая
1) Поднимаете новый сервис, ЛБ начинает передавать трафик на него и продолжает передавать на старый
2) Отдаёте команду shutdown старому, он перестаёт принимать новые соединения и ЛБ шлёт трафик только на новый
3) старый до обрабатывает старые соединения и завершается
Andrey
> Есть ли либы, позволяющие запускаться на том же порту новому процессу, а старому ещё долго (часы) продолжать обслуживать старые соединения?
такого нет
Илья
В het/http есть функция плавного завершения https://golang.org/pkg/net/http/#Server.Shutdown . Как бы предполагается, что мы хотим закончить обслуживать все имеющиеся соединения и только потом выйти. Но вот вопрос: как при этом запустить другой процесс, который бы принимал новые соединения?
Есть ли либы, позволяющие запускаться на том же порту новому процессу, а старому ещё долго (часы) продолжать обслуживать старые соединения?
см https://github.com/gobwas/graceful, Сергей там навернул передачу дексрипторов при graceful рестарте
Andrey
см https://github.com/gobwas/graceful, Сергей там навернул передачу дексрипторов при graceful рестарте
там и tcp порты можно передавать?
Michael
см https://github.com/gobwas/graceful, Сергей там навернул передачу дексрипторов при graceful рестарте
Спасибо, это то что надо. А то я сделал свой аналог https://github.com/rcrowley/goagain/ , но оно не пашет. И хрен знает почему.
Michael
там сокеты по их дескриптору передаются наверное.
Daniel
а вот скажите - как вы собираетесь graceful утилизировать в век keepalive
Daniel
так не закроется же соединение никогда
Michael
Вообще-то они закрываются.
Daniel
откуда ты знаешь?
Michael
проверял 😊
Daniel
я вот не проверял, но письма от страдальцев, у которых на reload nginx висит часами, читал
Michael
часами != никогда.
Daniel
по мне, так часами === никогда
Andrey
за время жизни вселенной точно закроется
Michael
при релоаде nginx-у SIGHUP посылается и всё. так что управление возвращается в консоль, если что.
Daniel
спасибо, кэп
Daniel
но от этого только хуже
Michael
В реальности это юзеры, которые активно использую сайт. Как уйдут, так соединение и закроется.
Sergei
Daniel
Michael
ну прибивай воркеров через час.
Daniel
почему не сразу?
Michael
сразу плохо: может прилететь пол страницы юзеру.
Daniel
и так может, только ты еще час ждал
Michael
спор из области, что курить вредно, но я же курю и жив.
Daniel
не, я не спорю
Daniel
я вопрос задаю
Daniel
и пока ответы все какие-то невнятные :)
Igor
http://nginx.org/en/docs/ngx_core_module.html#worker_shutdown_timeout
Daniel
еще раз - почему не прибить воркера сразу? зачем ждать?
Michael
ответ: чтобы юзер, качающий 100500 мегабайтный файл мог не нажимать на его перезакачку в браузере.
Michael
а недогруженный css или js или картинка делают сайт некрасивым.
Michael
и браузер не пытается из докачать, кстати.
Daniel
ответ: чтобы юзер, качающий 100500 мегабайтный файл мог не нажимать на его перезакачку в браузере.
но нет же способа оборвать соединение ровно тогда, когда он его докачает.
Daniel
раньше он сам бы соединение закрыл по окончании
Daniel
но сегодня-то - нет, не закроет
Michael
браузер закроет соединени.