кстати о дико-быстрорастущих а ля ноды, у них тоже сть umbrella, так вот они пошли по своему пути, потом опомнились и стали потихоньку переделывать все как у erlang, как говориться поспешишь...

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

Для этого делают rolling update сервисов оркестратором. И это независимо от технологии, на которой базируется сервис

Для этого делают rolling update сервисов оркестратором. И это независимо от технологии, на которой базируется сервис

Это сложно.

Для этого делают rolling update сервисов оркестратором. И это независимо от технологии, на которой базируется сервис

при persistent connection все равно разорвется соединение

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

если у вас процесс держит открытым сокет все время у вас явно не php

не самый лучший язык для этого совсем

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

В вебе давно перешли к той самой эрланговской модели let it crash и вместо пестования процесса готовят ему горячую замену целиком

Ну, как бы, не PHP ? Я его вообще не вижу )

Ну, как бы, не PHP ? Я его вообще не вижу )

хозяин барин, если самому интересно - то мне кажется вы легко освоите golang

он похож на кресты чем то

не на кресты

на С

простите

В вебе давно перешли к той самой эрланговской модели let it crash и вместо пестования процесса готовят ему горячую замену целиком

Когда и кто пришёл - не ясно. Есть задача - обновлять сервис, не мешая клиентам. Мы не хотим раздражать людей жёлтыми табличками с надписями "sorry, maintenance, we use let it crash".

golang сильно хайпят, это пугает

Когда и кто пришёл - не ясно. Есть задача - обновлять сервис, не мешая клиентам. Мы не хотим раздражать людей жёлтыми табличками с надписями "sorry, maintenance, we use let it crash".

если у вас классический response model то у вас такой плашки не будет

Вы в каком-то другом вебе живете, в котором люди еще не поняли, что крашится абсолютно все, а соединения рвутся и сами по себе. И потому делают всякие resilient-штуки, которые нацелены на восстановление, а не пестование.

просто тот кто сделает запрос после обновления уже попадет на новую версию

а тот кто не сделает - сидит на старой

Вы в каком-то другом вебе живете, в котором люди еще не поняли, что крашится абсолютно все, а соединения рвутся и сами по себе. И потому делают всякие resilient-штуки, которые нацелены на восстановление, а не пестование.

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

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

просто тот кто сделает запрос после обновления уже попадет на новую версию

Это всё понятно. Теперь представим 32 серверных процесса. Их все надо обновить по очереди.

32 одинаковых серверных процесса, которые делают одно и то же? На одном сервере?

Что проще, обновить 32 процесса с помощью оркестраторов или просто заменить на горячую несколько функций?

32 одинаковых серверных процесса, которые делают одно и то же? На одном сервере?

Привет, многопоточность.

Это всё понятно. Теперь представим 32 серверных процесса. Их все надо обновить по очереди.

вы упорно не хотите сообщить что это за сервисы, если это просто http, то они штатно обновятся по модели описанной выше

Привет, многопоточность.

Так процесса или потока?

Так процесса или потока?

Привет конкурентность.

Вы предъявляете некоторые претензии к современному устройству мира, но отказываетесь отвечать на уточняющие вопросы.

традиции А/Б тестирования говорят, что возможно нужно будет заменить 16 процессов на новые, 16 оставить старыми, а потом решить, на кого какие из 16 поменять

вы упорно не хотите сообщить что это за сервисы, если это просто http, то они штатно обновятся по модели описанной выше

Это просто http. 32 однопоточных процесса, которые делают одно и то же. Каким образом Вы прелагаете обновить такой сервис, к которому уже подключены 100000 пользователей?

Там, где есть горячая замена, это делается элементарно.

обновить так же, как если бы сервер упал

Это просто http. 32 однопоточных процесса, которые делают одно и то же. Каким образом Вы прелагаете обновить такой сервис, к которому уже подключены 100000 пользователей?

так http базируется на модели запрос - ответ, зачем в моменте отдачи ответа обновлять сервис?

обновить так же, как если бы сервер упал

Но тогда пользователи могут обидеться.

Это просто http. 32 однопоточных процесса, которые делают одно и то же. Каким образом Вы прелагаете обновить такой сервис, к которому уже подключены 100000 пользователей?

2018, отказ от пхп, но 32 однопоточных процесса

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

Тупо дать клиенту сигнал, что надо переподключиться и после этого потушить процесс, нет?

Выводим процесс из-под балансировщика, говорим, что он уходит, шлем клиентам сообщения, обрываемся по таймауту, нет?

И да, это в разы проще делать оркестратором

Тупо дать клиенту сигнал, что надо переподключиться и после этого потушить процесс, нет?

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

@SMUGFACE будет жить. Поприветствуем!

Всем привет. Вопрос: как грамотно добавить в таблицу колонку, в которой будут какие-то вычисленные значения на основе ячеек из строк?

пример: таблица id, a, b, добавить в неё колонку, в которой значение будет равно a+b

как-то так

пример: таблица id, a, b, добавить в неё колонку, в которой значение будет равно a+b

вам возможно сюда нужно https://t.me/sqlcom

Там для новичков?

SELECT id,a,b,a+b AS val

FROM и т д

сами допишете)

2018, отказ от пхп, но 32 однопоточных процесса

Ну, как бы, да. 2018, отказ от PHP, 32 однопоточных процесса и вот это всё. Вы за нас не переживайте, если будет надо, мы сделаем 8 процессов по 4 потока без оглядки на внешних экспертов.

Всем привет. Вопрос: как грамотно добавить в таблицу колонку, в которой будут какие-то вычисленные значения на основе ячеек из строк?

тут вопрос, зачем это делать: - можно прямо на селекте - можно прожечь в таблицу и обновлять триггером - можно сделать view и читать из него

Ну, как бы, да. 2018, отказ от PHP, 32 однопоточных процесса и вот это всё. Вы за нас не переживайте, если будет надо, мы сделаем 8 процессов по 4 потока без оглядки на внешних экспертов.

может быть, все-таки один?

может быть, все-таки один?

Мы подумаем. Это же не PHP, тут вариантов много.

может быть, все-таки один?

в Python, например, есть GIL, из-за которого лучше количество процессов = количество ядер

с GIL надо уметь работать)

в Python, например, есть GIL, из-за которого лучше количество процессов = количество ядер

ну мы тут про высокие технологии, которые умеют в memory model

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

Ещё раз, мы не хотим рубить клиентов. Давайте заменим long-polling ajax по http на websockets. Клиенты мониторят нечто в реальном времени. Как обновить код серверного процесса с помощью докера или кубернетеса без прерывания работы пула серверных процессов?

тут вопрос, зачем это делать: - можно прямо на селекте - можно прожечь в таблицу и обновлять триггером - можно сделать view и читать из него

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

вам возможно сюда нужно https://t.me/sqlcom

а здесь чат о чём?

postgres

Ещё раз, мы не хотим рубить клиентов. Давайте заменим long-polling ajax по http на websockets. Клиенты мониторят нечто в реальном времени. Как обновить код серверного процесса с помощью докера или кубернетеса без прерывания работы пула серверных процессов?

Всегда можно предусмотреть завершение коннекта по инициативе сервера с сохранением состояния клиентов и возможностью клиентам переподключиться. Потом есть завершение по исчерпанию активных коннектов. Ну не вечно же коннекты по вебсокетам будут висеть

Ещё раз, мы не хотим рубить клиентов. Давайте заменим long-polling ajax по http на websockets. Клиенты мониторят нечто в реальном времени. Как обновить код серверного процесса с помощью докера или кубернетеса без прерывания работы пула серверных процессов?

rainbow deploy

деплоишь новую версию приложения, на которую направляются только новые подключения

Всегда можно предусмотреть завершение коннекта по инициативе сервера с сохранением состояния клиентов и возможностью клиентам переподключиться. Потом есть завершение по исчерпанию активных коннектов. Ну не вечно же коннекты по вебсокетам будут висеть

Совершенно верно. Это можно предусмотреть коде сервера приложений. Ну а в языках, где предусмотрена горячая замена кода, ничего предусматревать не надо. Теоретически, конечно ?

ERROR: S client not available

rainbow deploy

Давайте представим. Пусть есть пул из N процессов, и есть M клиентов => На каждый процесс приходится по M/N активных соединений, т.е. сокетов. Нам надо все эти сокеты перенести на новый пул без разрыва соединений. Вы какой технологией предлагаете пользоваться?

Нам не надо переносить их без разрыва соединений

Нам не надо переносить их без разрыва соединений

Но нам то надо.

Вы ноду таким образом на обслуживание вытащить не сможете

Давайте представим. Пусть есть пул из N процессов, и есть M клиентов => На каждый процесс приходится по M/N активных соединений, т.е. сокетов. Нам надо все эти сокеты перенести на новый пул без разрыва соединений. Вы какой технологией предлагаете пользоваться?

1) деплоим новый пул 2) направляем новые подключения только на новый пул, старые не гасим 3) когда старые естественно отваливаются и освобождают старые инстансы, гасим их по мере освобождения

1) деплоим новый пул 2) направляем новые подключения только на новый пул, старые не гасим 3) когда старые естественно отваливаются и освобождают старые инстансы, гасим их по мере освобождения

Всё бы хорошо, если бы не 3). Преставим, что клиенты сидят и смотрят за перемещениями объектов в рельном времени. Получается, что нам надо их принудительно переподключить, а это время. Клиенты за это время могут что-то пропустить. Нет, если было бы допустимо, чтобы несколько секунд клиент сидел и смотрел в модальное окно с песочными часами вместо мониторинга - тогда да, отключаем и подключаем заново.

хмм

перемещения объектов в реальном времени

Всё бы хорошо, если бы не 3). Преставим, что клиенты сидят и смотрят за перемещениями объектов в рельном времени. Получается, что нам надо их принудительно переподключить, а это время. Клиенты за это время могут что-то пропустить. Нет, если было бы допустимо, чтобы несколько секунд клиент сидел и смотрел в модальное окно с песочными часами вместо мониторинга - тогда да, отключаем и подключаем заново.

нет, мы не переподключаем, просто они смотрят по старым правилам

а вообще я не знаю такой ситуации, в которой человек раз в день не может на 5 секунд повтыкать на песочные часы:)

нет, мы не переподключаем, просто они смотрят по старым правилам

Тогда можно вообще ничего не менять? Пусть так и смотрят по старым правилам ?

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

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

Всё бы хорошо, если бы не 3). Преставим, что клиенты сидят и смотрят за перемещениями объектов в рельном времени. Получается, что нам надо их принудительно переподключить, а это время. Клиенты за это время могут что-то пропустить. Нет, если было бы допустимо, чтобы несколько секунд клиент сидел и смотрел в модальное окно с песочными часами вместо мониторинга - тогда да, отключаем и подключаем заново.

Столько волшебных условий жизнь создала для необходимости хот свапа

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

Не совсем так, конечно. Переконнект тоже имеет свои накладные расходы. В любом случае, организовать переподключения, предварительно развёртывая новую версию сервера, технически намного более сложнее и более уродливо, чем простая и изящная замена кода процесса без его перезапуска.

Столько волшебных условий жизнь создала для необходимости хот свапа

Ага.

простая и изящная замена

ладно, прекращаю ерничать

Ну да, выглядит не очень ?

микросервисы и тонкий гейтвей, не требующий перезапуска, тоже вариант

Т.е. все состояния соединений на балансировщике?

Как говорит Страуструп: "как это часто бывает, проблема решается посредством косвенного доступа".

Т.е. все состояния соединений на балансировщике?

ну как бы давайте сразу так - если у вас stateful сервер то PHP не ваш вариант, тогда берем Java(вот уж где штук для хотсвапа достаточно) и пишем это все

но конечно количество магии у вас стремится к бесконечности, столько условий, для систем зависящих от коннекта

я такое тока на биржевых ботах видел

и мы писали на питоне, норм было ☺

правда с хотсвапом не морочились

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

ну как бы давайте сразу так - если у вас stateful сервер то PHP не ваш вариант, тогда берем Java(вот уж где штук для хотсвапа достаточно) и пишем это все

Это всё понятно. Мы можем задействовать и dlopen(3) в C++, и будет всё тоже работать. Я поинтересовался насчёт Erlang, потому что знаю что такое горячая замена кода в Common Lisp, и насколько проще с ней работать, чем с dlopen.

Это всё понятно. Мы можем задействовать и dlopen(3) в C++, и будет всё тоже работать. Я поинтересовался насчёт Erlang, потому что знаю что такое горячая замена кода в Common Lisp, и насколько проще с ней работать, чем с dlopen.

если важно прям hcs то наверное да, эрланг стоит пробовать

кстати, если говоррить о сравнении с java/c# - это корпоративная среда, свой сегмент и особенности, причем сейчас уже скорее нужно говорить не о java, а о clojure или haskell erlang - это уже больше opensource community

еще GameDev))