Хм, т.е. если у батарейки зарядить "-" до +100В, то на "+" будет 105, а если до -100В, то на "+" будет -95В. Так? А с другими источниками питания то же самое?
Да, знаю, что напряжение в двух любых точках схемы, если между ними нет сопротивления, должно быть одинаковым. Знаю, но не понимаю :) Взять 2 батарейки на 5В - теоретически же не обязательно же, чтобы у них обеих абсолютный потенциал был, к примеру, 0 на минусовом контакте, и +5 на плюсовом. Теоретически же может быть у одной +95 и +100, а у второй - -95 и -100. И в том и в том случае напряжение будет 5В. Но если соединить минус одной и минус другой - между ними разность потенциалов будет 195В! Т.е. между ними должен течь ток!
Не так выразился. Имел в виду разные источники питания, просто в дипломе было 2 трансформатора, после них диодные мосты, соединённые минусами. Да, на электротехнике учили, как это всё рассчитывать, но вот на пальцах, на уровне интуиции - так и не понял. Ведь нет гарантии, что потенциалы этих "минусов" одинаковы, т.е. вполне между ними может течь ток. А учитывая нулевое сопротивление - довольно значительный. Если в случае батареек - ещё так-сяк, т.к. они насытятся, потенциалы уровняются и ток будет течь только короткое время после соединения. То в случае трансформаторов - ЭДС там будет действовать постоянно, и, значит, постоянно будет течь ток между "минусами" с разными потенциалами.
Спасибо, обязательно почитаю. А то до сих пор, после института и десятка попыток читать разные книги по электронике не понимаю базовых вещей - вроде, почему можно соединять одинаковые полюса трансформаторов.
А храните где, если не секрет? У нас сейчас эластик, но уже не устраивает по производительности. Сейчас ищем другие решения и Loki хороший кандидат, но есть нюансы.
Добавлю и свой вопрос - а кто как логирует взаимодействия сервисов с внешними системами либо между собой. В общий поток событий или как-то отдельно? У нас сейчас это выполняется отдельной библиотекой, что не очень удобно - приходится поддерживать, по сути, 2 логгера. Но в общий поток такие вещи не уверен, что правильно писать - их оттуда сложно вычленить, плюс их объем может быть довольно приличным.
Прошу прощения, немного не в тему, но кто как решает вопрос логирования коммуникаций между сервисами? Внешние, либо внутри системы. Они же могут быть и многострочными, так что в файл уже не запишешь. Да и в принципе стандартные логгеры для этого не очень подходят, приходится придумывать велосипеды. Но вдруг есть решение изящнее.
Вчера поигрался с кодом - уже с pgx и diesel, но ещё без тюнинга. Получил такие результаты - rust - 35k rps, go - 42k rps.
Но, когда добавил замеры времени работы именно http хендлера, то в обоих случаях время выполнения было в пределах 120-205 мкс. Т.е., похоже, на скорость, в основном, влияет Axum, а не sqlx или парсинг jwt. А вот настройка diesel эту разницу компенсирует.
Я бы предложил наоборот - non-prepared statement. Поскольку они привязываются к соединению, а в случае пула соединений не факт, что следующий запрос будет использовать это же prepared statement.
Мне как раз сцена с Аналитиком (чего и для чего аналитиком, кстати?) - единственное, что понравилось в фильме. Не его рассуждения, а концепт, замедление времени. Всё остальное в фильме - плохо.
А не маловато 13 дюймов? Я пару лет назад переехал на десктоп с монитором 21, после этого ноутбуки для постоянной работы кажутся неудобными. Дело привычки, конечно, но всё же.
В целом с посылом статьи согласен. Но, из того с чем сталкивался, Rust, всё-таки, внёс новую парадигму. А именно концепцию владения. Я так понимаю, это побочный эффект от системы управления памятью, но она довольно сильно влияет на базовые принципы построения программы.
Буду благодарен )
Кое-что прояснилось, по крайней мере, появились мысли что дальше почитать.
Спасибо за ликбез! Кармы, к сожалению, на голосование не хватает.
Хм, т.е. если у батарейки зарядить "-" до +100В, то на "+" будет 105, а если до -100В, то на "+" будет -95В. Так?
А с другими источниками питания то же самое?
А что значит "изоляция на выходе"? В институте было про "гальваническую развязку", но толком не объяснили что это. Не оно?
Да, знаю, что напряжение в двух любых точках схемы, если между ними нет сопротивления, должно быть одинаковым. Знаю, но не понимаю :)
Взять 2 батарейки на 5В - теоретически же не обязательно же, чтобы у них обеих абсолютный потенциал был, к примеру, 0 на минусовом контакте, и +5 на плюсовом. Теоретически же может быть у одной +95 и +100, а у второй - -95 и -100. И в том и в том случае напряжение будет 5В. Но если соединить минус одной и минус другой - между ними разность потенциалов будет 195В! Т.е. между ними должен течь ток!
Согласен, глупость сказал. На бегу комментарий писал. Ниже объяснил, что имелось в виду.
Не так выразился. Имел в виду разные источники питания, просто в дипломе было 2 трансформатора, после них диодные мосты, соединённые минусами. Да, на электротехнике учили, как это всё рассчитывать, но вот на пальцах, на уровне интуиции - так и не понял. Ведь нет гарантии, что потенциалы этих "минусов" одинаковы, т.е. вполне между ними может течь ток. А учитывая нулевое сопротивление - довольно значительный. Если в случае батареек - ещё так-сяк, т.к. они насытятся, потенциалы уровняются и ток будет течь только короткое время после соединения. То в случае трансформаторов - ЭДС там будет действовать постоянно, и, значит, постоянно будет течь ток между "минусами" с разными потенциалами.
Спасибо, обязательно почитаю. А то до сих пор, после института и десятка попыток читать разные книги по электронике не понимаю базовых вещей - вроде, почему можно соединять одинаковые полюса трансформаторов.
Да, это в документации видел. Неудачно выразился - вопрос не в хранении, а в последующем изучении. Grafana не очень для этого приспособлена.
А храните где, если не секрет? У нас сейчас эластик, но уже не устраивает по производительности. Сейчас ищем другие решения и Loki хороший кандидат, но есть нюансы.
Добавлю и свой вопрос - а кто как логирует взаимодействия сервисов с внешними системами либо между собой. В общий поток событий или как-то отдельно? У нас сейчас это выполняется отдельной библиотекой, что не очень удобно - приходится поддерживать, по сути, 2 логгера. Но в общий поток такие вещи не уверен, что правильно писать - их оттуда сложно вычленить, плюс их объем может быть довольно приличным.
Прошу прощения, немного не в тему, но кто как решает вопрос логирования коммуникаций между сервисами? Внешние, либо внутри системы. Они же могут быть и многострочными, так что в файл уже не запишешь. Да и в принципе стандартные логгеры для этого не очень подходят, приходится придумывать велосипеды. Но вдруг есть решение изящнее.
Вчера поигрался с кодом - уже с pgx и diesel, но ещё без тюнинга. Получил такие результаты - rust - 35k rps, go - 42k rps.
Но, когда добавил замеры времени работы именно http хендлера, то в обоих случаях время выполнения было в пределах 120-205 мкс. Т.е., похоже, на скорость, в основном, влияет Axum, а не sqlx или парсинг jwt. А вот настройка diesel эту разницу компенсирует.
Я бы предложил наоборот - non-prepared statement. Поскольку они привязываются к соединению, а в случае пула соединений не факт, что следующий запрос будет использовать это же prepared statement.
Да, но для надёжности ему лучше бы private каталог выделить, чтобы вообще ничего постороннего не видел.
А firejail? Полегче, всё-таки, чем виртуалка. У меня именно так.
Левый мужик в царских шмотках и с царским лицом. А президенты сейчас разве не так указы подписывают?
Мне как раз сцена с Аналитиком (чего и для чего аналитиком, кстати?) - единственное, что понравилось в фильме. Не его рассуждения, а концепт, замедление времени. Всё остальное в фильме - плохо.
А не маловато 13 дюймов? Я пару лет назад переехал на десктоп с монитором 21, после этого ноутбуки для постоянной работы кажутся неудобными. Дело привычки, конечно, но всё же.
Прошу прощения за небольшой оффтоп.
В целом с посылом статьи согласен. Но, из того с чем сталкивался, Rust, всё-таки, внёс новую парадигму. А именно концепцию владения. Я так понимаю, это побочный эффект от системы управления памятью, но она довольно сильно влияет на базовые принципы построения программы.