Два пива этому господину. По-моему, у большинства программистов есть какой-то сервер (завести за 100 руб/мес не проблема). Поставить туда WG и вуаля - у вас распределённая домашняя сеть. На личном ноуте настроил автозапуск WG, и когда уезжаю, но данные с ноута нужны, просто прошу жену включить его.
Помимо этого в сети крутится ещё пяток сервисов в этой же подсети чисто для личного использования.Ну и выставлять домашнюю инфраструктуру на белый IP в интернете я бы побоялся. А так цель выполнена была бы - доступ к HA из любой точки.
А зачем в проекте и gunicron, и uvicorn? Я понимаю, что у gunicorn есть возможность запуска async-бэкенда через uvicorn, но всегда считал этот механизм больше для какой-то обратной совместимости.
Вообще в 12factor рекомендуется масштабироваться именно контейнерами, а не процессами внутри. Но вы отбросили отказ от мультипроцессинга почти сразу. Можете подсказать на каких объёмах использование ресурсов становится нерациональным? Просто у меня буквально 16 воркеров, и не уверен, что в моём случае стоит усложнять внутреннюю реализацию, а не масштабироваться подами с одним процессом.
В любом случае спасибо за рисёрч - тема очень интересная.
А потом оглядываешься, а у тебя клстер k8s с 6 микросервисами, данных на 300Gb, фрезерный станок и пара десятков кило картона. Не то, чтобы это было необхоидмо для нумизматики, но если уж заниматься, то всерьёз.
Потому что docker будет следить за здоровьем процесса супервизора, а не вашего приложения, которое внутри ушло в вечный ребут. Такой контейнер будет здоровым, но бесполезным.
Ещё одна - особенность работы CFS. Когда количество потоков меньше лимитов, то могут быть ложные провалы хелсчеков. Например тому процессу, который обрабатывает хелсчек, просто не дали времени.
Собственно, вы правы. Изначально GraphQL был придуман в Facebook, чтобы меньше зависеть от бэкенда. Там же куча сервсов, а к каждому и не один запрос - вот и придумали гейтвей, на который можно было бы переложить эту сложность.
Лучше искать по слову каррирование.
Наконец-то я смогу нарисовать эту чёртову сову!!!
Вероятно, имелось ввиду для веб-проекта. SQLite всё же однопоточный на запись, что при нагрузке может стать проблемой.
С другой стороны в pet-проектах где пользователь только я - почему бы и нет.
Да и сайт без https...
Два пива этому господину. По-моему, у большинства программистов есть какой-то сервер (завести за 100 руб/мес не проблема). Поставить туда WG и вуаля - у вас распределённая домашняя сеть. На личном ноуте настроил автозапуск WG, и когда уезжаю, но данные с ноута нужны, просто прошу жену включить его.
Помимо этого в сети крутится ещё пяток сервисов в этой же подсети чисто для личного использования.Ну и выставлять домашнюю инфраструктуру на белый IP в интернете я бы побоялся. А так цель выполнена была бы - доступ к HA из любой точки.
О, и у меня DPD Краснодар и Красноярск перепутал.
В подобной статье я уже задавал этот вопрос. tl;dr зависит от нагрузки.
Точно, спасибо за исправление. Теперь нашёл автора в списке редакторов.
P.S. А статья про yaml действительно хороша!
Прошу прощения, а как собирались топ-10 переводов? Мой перевод как работает ChatGPT набрал 248 лайков, а первая у вас в рейтинге 214.
Так lxml тоже на C/C++ написан.
Судя по населению Краснодара, данные за 2021 год.
А зачем в проекте и gunicron, и uvicorn? Я понимаю, что у gunicorn есть возможность запуска async-бэкенда через uvicorn, но всегда считал этот механизм больше для какой-то обратной совместимости.
Не смотрели в сторону UltraDict ? Он под капотом использует multiprocessing.shared_memory, т.е. как раз общую память для разных процессов.
Вообще в 12factor рекомендуется масштабироваться именно контейнерами, а не процессами внутри. Но вы отбросили отказ от мультипроцессинга почти сразу. Можете подсказать на каких объёмах использование ресурсов становится нерациональным? Просто у меня буквально 16 воркеров, и не уверен, что в моём случае стоит усложнять внутреннюю реализацию, а не масштабироваться подами с одним процессом.
В любом случае спасибо за рисёрч - тема очень интересная.
А потом оглядываешься, а у тебя клстер k8s с 6 микросервисами, данных на 300Gb, фрезерный станок и пара десятков кило картона. Не то, чтобы это было необхоидмо для нумизматики, но если уж заниматься, то всерьёз.
Есть повод запастись и потом продавать коллекционерам.
Потому что docker будет следить за здоровьем процесса супервизора, а не вашего приложения, которое внутри ушло в вечный ребут. Такой контейнер будет здоровым, но бесполезным.
Ещё одна - особенность работы CFS. Когда количество потоков меньше лимитов, то могут быть ложные провалы хелсчеков. Например тому процессу, который обрабатывает хелсчек, просто не дали времени.
Каждый день к девяти мне надо идти в магистрат... Не скажу, что это подвиг, но вообще что-то героическое в этом есть...
Имя аккаунта говорящее. Вот только тут даже сторис самого Хабра особо не прижились.
Вот да. А ещё одновременно делать небольшие фиксы, раскидывая их по разным листам изменений (changelist).
Пример с молоком показательный, что все врут (c) В описании 950г, а цена 99.90 за кг, а итоговая не пересчиталась. Но покупатель же не заметит...
Собственно, вы правы. Изначально GraphQL был придуман в Facebook, чтобы меньше зависеть от бэкенда. Там же куча сервсов, а к каждому и не один запрос - вот и придумали гейтвей, на который можно было бы переложить эту сложность.