Если убрать из названия слово биллинг — то ничего в статье не поменяется. Не вижу ничего специфического в описанном, на мой взгляд это список вещей которые должны являться базой для любого современного человека в IT в принципе.
Первую половину статьи можно вообще фактически как универсальное руководство по анализу использования ресурсов в linux давать.
А скорость с которой Clickhouse ворочает сотни гигабайт настолько высока, что пока ничего кроме самого запроса еще оптимизировать не было необходимости. Положил в закладки на случай, когда такая ситуация возникнет.
На выходных буквально настроил себе VSCode на работу с WSL через Remote — WSL. Теперь под домашним Windows работать в vscode используя git, ansible, terraform — также удобно как на рабочей linux машине. Все те же аддоны редактора работают, как и весь функционал linux утилит.
Определенно мне нравится новый вектор развития Microsoft.
Да он всего $10 стоит на каждые 10 человек, для серверной редакции, на год.Если с ценой самой Jira сравнить — это почти не деньги. Зато там тебе и фильтры всякие по проектам, крутилки удобные и т.д. А через год можно просто его не обновлять и пользоваться старой версией дальше (как многие с самой джирой делают).
Интересно, ждем продолжения.
Можете немного подробнее осветить получение ICP лицензии — понадобилось ли регистрировать бизнес в Китае, какой тип выбрали, и вообще какие шаги для этого необходимы?
В вашем примере есть гораздо более важный и тоже не очевидный из документации nginx нюанс — при proxy_next_upstream_tries 1 на второй бэкенд запросы не пойдут. За 1 считается уже попытка соединения с первым же сервером. Так что если вы хотите ограничить попытки например двумя серверами из четырех — ставьте proxy_next_upstream_tries 2. А proxy_next_upstream_tries 1 сработает по сути аналогично proxy_next_upstream off — запретит перебирать бэкенды и заставит отдать ответ от первого выбранного. Я проверял это поведение вживую.
Еще обязательно ставьте proxy_connect_timeout в значения не более 1 секунды. А параметры proxy_read_timeout и proxy_send_timeout считайте как общее время на весь запрос для клиента разделенное на количество попыток: proxy_next_upstream_timeout / proxy_next_upstream_tries. С округлением в меньшую сторону.
Из персонального опыта — люди не готовы ждать больше нескольких секунд, и уже после пяти секунд ожидания — некоторые просто закрывают сайт или приложение. Это видно по коду 499 в логах. Поэтому и proxy_next_upstream_timeout нет смысла делать больше тех же 10 секунд, а таймауты на бэкенд соответственно не должны превышать нескольких секунд. Лучше быстро попробовать несколько серверов и если кто-то живой — отдать ответ, а нет — вернуть клиенту ошибку. Чем ждать таймаута на его устройстве или пока терпение лопнет.
Выглядит интересно, но есть вероятность, что тому кто собирает ВКС самостоятельно — будет не хватать ассортимента товаров из каталога, а интеграторам такая вещь не нужна — они сами всё посчитают.
Но именно как для ваших клиентов, которые собирались покупать то что у вас есть — думаю зайдет. А это в принципе главное.
По-моему единственные кто топит за VDI — это интеграторы и вендоры платформ и виртуализации. Ну и несчастные счастливые жертвы клиенты пару лет пытаются убедить всех вокруг, а главное себя же — в невиданных преимуществах.
При этом если садишься считать — то для простых рабочих мест обычный ПК выходит сразу дешевле чем тонкий клиент + VDI, а для рабочих станций — покупка своего железа уже через год-второй окупается по сравнению с VDI. И это не вспоминая про такие минусы как повышенные требования к каналам связи.
По-моему единственным честным кейсом для VDI является повышенные требования безопасности, и когда покупатель понимает что будет очень дорого, но это единственный выход. Читай — банки, страховые компании и другие операторы данных, которые надо защищать любыми средствами и независимо от прайса.
Не очень понятно, почему вы являетесь пионерами, если сами подсмотрели такое решение у других. Из-за того что показания контролируете не вручную, а системой мониторинга?
И снова я вернулся к этой статье, благодаря поиску — искал почему у меня nginx с параметром proxy_next_upstream_tries 1; не переключает запросы на второй бэкенд. У меня возникли подозрения, что это попытка соединения с мертвым бэкендом учитывается, и из данной статьи я понял что так и есть. Из описания параметра в доке nginx это никак не выводится логически.
Второй раз прочитал с не меньшим интересом чем в первый, и снова(!!) почерпнул полезной инфы.
Вот это я понимаю качественный материал.
И опять же повторюсь, что это верно при одинаковом проценте. Если же на мелкий срок процент сильно меньше чем на большой — такие рассуждения работать не будут, и нужно считать выгодные условия для своей персональной ситуации.
Нет. О том и статья, что с аннуитетом нет разницы на какой срок у тебя кредит, а всё зависит от того сколько ты платишь в месяц. В вашем примере — взял со сроком на 25 и платежом 2000, а платишь по 4000 в месяц с перерасчетом срока — выплатишь за те же 5. Зато появляется пространство для маневра — не смог 4000, внес 3000 или 2000. Смог больше — внеси больше. А если перерасчет делать на платеж, то внося теже 4000 опять получаешь срок 5 лет, зато мин. платеж всё время уменьшается, еще расширяя маневренную область. А прописывая себе срок самостоятельно в 5 и платеж 4000 — вы уже не сможете при необходимости внести меньше, всегда ровно столько или больше. Т.е. более жесткие условия получаются.
WD-40 всё-таки не специализированное средство. В моей практике я и коллеги для любых резиновых роликов использовали Platenclene PCL100. Помогает очень хорошо, как с принтерами, так и с банкоматами (для разделительных колес в диспенсерах, роликов в кардридерах).
Все верно, сам пришел к таким же выводам — для подстраховки лучше брать кредит на максимально возможный срок (если это не сильно увеличивает годовой процент), а платить столько, сколько удобно (но естественно не ниже минимального).
Тогда и кредит гасится быстрее когда есть излишки — процентов заплатишь меньше, а когда отпуск или форс-мажор — можно спокойно заплатить минималку и взять остальные деньги.
Былинная история, боярин. Настолько натянуто за уши это всё звучит, что к вашему продукту тоже как-то после этого серьезно относится не выходит. Так и представил себе директора, которому продают Флакон с помощью сборника сочинений.
Это как Додо пицца, продает пиццу с помощью блога, книжек и рассказов про своё ИТ ноу-хау. А пицца то при это средненькая.
Если убрать из названия слово биллинг — то ничего в статье не поменяется. Не вижу ничего специфического в описанном, на мой взгляд это список вещей которые должны являться базой для любого современного человека в IT в принципе.
Спасибо что поделились ценным опытом, с интересом прочитал все три статьи, т.к. есть планы на работе по продвижению продукта в Китай.
Очень высокая концентрация полезного! Спасибо.
Первую половину статьи можно вообще фактически как универсальное руководство по анализу использования ресурсов в linux давать.
А скорость с которой Clickhouse ворочает сотни гигабайт настолько высока, что пока ничего кроме самого запроса еще оптимизировать не было необходимости. Положил в закладки на случай, когда такая ситуация возникнет.
На выходных буквально настроил себе VSCode на работу с WSL через Remote — WSL. Теперь под домашним Windows работать в vscode используя git, ansible, terraform — также удобно как на рабочей linux машине. Все те же аддоны редактора работают, как и весь функционал linux утилит.
Определенно мне нравится новый вектор развития Microsoft.
Да он всего $10 стоит на каждые 10 человек, для серверной редакции, на год.Если с ценой самой Jira сравнить — это почти не деньги. Зато там тебе и фильтры всякие по проектам, крутилки удобные и т.д. А через год можно просто его не обновлять и пользоваться старой версией дальше (как многие с самой джирой делают).
Интересно, ждем продолжения.
Можете немного подробнее осветить получение ICP лицензии — понадобилось ли регистрировать бизнес в Китае, какой тип выбрали, и вообще какие шаги для этого необходимы?
В вашем примере есть гораздо более важный и тоже не очевидный из документации nginx нюанс — при proxy_next_upstream_tries 1 на второй бэкенд запросы не пойдут. За 1 считается уже попытка соединения с первым же сервером. Так что если вы хотите ограничить попытки например двумя серверами из четырех — ставьте proxy_next_upstream_tries 2. А proxy_next_upstream_tries 1 сработает по сути аналогично proxy_next_upstream off — запретит перебирать бэкенды и заставит отдать ответ от первого выбранного. Я проверял это поведение вживую.
Еще обязательно ставьте proxy_connect_timeout в значения не более 1 секунды. А параметры proxy_read_timeout и proxy_send_timeout считайте как общее время на весь запрос для клиента разделенное на количество попыток: proxy_next_upstream_timeout / proxy_next_upstream_tries. С округлением в меньшую сторону.
Из персонального опыта — люди не готовы ждать больше нескольких секунд, и уже после пяти секунд ожидания — некоторые просто закрывают сайт или приложение. Это видно по коду 499 в логах. Поэтому и proxy_next_upstream_timeout нет смысла делать больше тех же 10 секунд, а таймауты на бэкенд соответственно не должны превышать нескольких секунд. Лучше быстро попробовать несколько серверов и если кто-то живой — отдать ответ, а нет — вернуть клиенту ошибку. Чем ждать таймаута на его устройстве или пока терпение лопнет.
И вот еще очень полезная статья на тему high availability балансировки — https://m.habr.com/ru/company/oleg-bunin/blog/423085/
При большом потоке запросов активные healthchecks будут проходить реже, чем пассивная проверка обычного трафика. А значит от них будет меньше пользы.
А можно поставить плагин "Timesheet Reports and Gadgets" — будет быстрее, удобнее, нагляднее.
Выглядит интересно, но есть вероятность, что тому кто собирает ВКС самостоятельно — будет не хватать ассортимента товаров из каталога, а интеграторам такая вещь не нужна — они сами всё посчитают.
Но именно как для ваших клиентов, которые собирались покупать то что у вас есть — думаю зайдет. А это в принципе главное.
В этом релизе почти нет каких-то прорывных изменений, а большинство того что есть — только для платных версий. На мажорную версию не очень тянет.
По-моему единственные кто топит за VDI — это интеграторы и вендоры платформ и виртуализации. Ну и
несчастныесчастливыежертвыклиенты пару лет пытаются убедить всех вокруг, а главное себя же — в невиданных преимуществах.При этом если садишься считать — то для простых рабочих мест обычный ПК выходит сразу дешевле чем тонкий клиент + VDI, а для рабочих станций — покупка своего железа уже через год-второй окупается по сравнению с VDI. И это не вспоминая про такие минусы как повышенные требования к каналам связи.
По-моему единственным честным кейсом для VDI является повышенные требования безопасности, и когда покупатель понимает что будет очень дорого, но это единственный выход. Читай — банки, страховые компании и другие операторы данных, которые надо защищать любыми средствами и независимо от прайса.
Не очень понятно, почему вы являетесь пионерами, если сами подсмотрели такое решение у других. Из-за того что показания контролируете не вручную, а системой мониторинга?
И снова я вернулся к этой статье, благодаря поиску — искал почему у меня nginx с параметром
proxy_next_upstream_tries 1;не переключает запросы на второй бэкенд. У меня возникли подозрения, что это попытка соединения с мертвым бэкендом учитывается, и из данной статьи я понял что так и есть. Из описания параметра в доке nginx это никак не выводится логически.Второй раз прочитал с не меньшим интересом чем в первый, и снова(!!) почерпнул полезной инфы.
Вот это я понимаю качественный материал.
И опять же повторюсь, что это верно при одинаковом проценте. Если же на мелкий срок процент сильно меньше чем на большой — такие рассуждения работать не будут, и нужно считать выгодные условия для своей персональной ситуации.
Нет. О том и статья, что с аннуитетом нет разницы на какой срок у тебя кредит, а всё зависит от того сколько ты платишь в месяц. В вашем примере — взял со сроком на 25 и платежом 2000, а платишь по 4000 в месяц с перерасчетом срока — выплатишь за те же 5. Зато появляется пространство для маневра — не смог 4000, внес 3000 или 2000. Смог больше — внеси больше. А если перерасчет делать на платеж, то внося теже 4000 опять получаешь срок 5 лет, зато мин. платеж всё время уменьшается, еще расширяя маневренную область. А прописывая себе срок самостоятельно в 5 и платеж 4000 — вы уже не сможете при необходимости внести меньше, всегда ровно столько или больше. Т.е. более жесткие условия получаются.
WD-40 всё-таки не специализированное средство. В моей практике я и коллеги для любых резиновых роликов использовали Platenclene PCL100. Помогает очень хорошо, как с принтерами, так и с банкоматами (для разделительных колес в диспенсерах, роликов в кардридерах).
Тогда и кредит гасится быстрее когда есть излишки — процентов заплатишь меньше, а когда отпуск или форс-мажор — можно спокойно заплатить минималку и взять остальные деньги.
Былинная история, боярин. Настолько натянуто за уши это всё звучит, что к вашему продукту тоже как-то после этого серьезно относится не выходит. Так и представил себе директора, которому продают Флакон с помощью сборника сочинений.
Это как Додо пицца, продает пиццу с помощью блога, книжек и рассказов про своё ИТ ноу-хау. А пицца то при это средненькая.
Столько воды, а ведь всего три пункта достаточно: