Там была скорее проблема быстрого хаотичного роста "потому что так сложилось". И на самом деле, не все так плохо. Это был первый этап, который закрывал текущую проблему и давал время на полноценный рефакторинг.
Несколько забегая вперед - оптимизировали, унифицировали и сумели убрать большую часть серверов при итоговом росте надежности. Так что это скорее история о том, что не всегда нужно брать и выбрасывать сразу.
С финансовой точки зрения, вопрос не в том, чтобы прибыли хватило, а в многократной разнице совокупной стоимости владения. Конкретные цифры я озвучить не могу, но сторонний CDN может быть существенно дороже хорошо оптимизированных bare-metal решений. Конечно, все это зависит от конкретного случая. В первую очередь свои сервера намного выгоднее при равномерной средней нагруженности.
Всякое бывает. Часто это довольно старые проекты, которые внезапно обнаружили, что им нужно обслуживать тяжёлые нагрузки, и сделали как смогли. Да, многие решения могут выглядеть несколько необычно. Но они работают и приносят доход.
Поэтому, приходится все аккуратно и последовательно все оптимизировать.
Простите за такой кликбейт в формулировках. По сути, было необходимо обеспечить равномерность нагрузки на серверы с очень разными характеристиками, чтобы полностью утилизировать мощность.
Если часть уже откажет, а часть останется функциональными, то это не спасет в этой архитектуре. Вся группа уже будет нерабочей. Но да, в условиях идеальной балансировки они действительно синхронно падают при DDoS. Конечно, не в этом была основная цель, просто забавное наблюдение и критерий хорошей балансировки.
Мы всегда придерживаемся идеи, что заказчик не просто так долгое время что-то строил. Вначале быстро решаем то, что болит прямо сейчас, а потом уже итеративно движемся оптимальному варианту.
На том этапе развития проблема была в том, что если сервер лег, то из нагрузки он автоматически не выводится. Пользователи страдали. Мы это реализовывали на более поздних этапах рефакторинга инфраструктуры.
Тут проблема была в том, что ресурсы были несбалансированы между собой. Есть мощные и дохлые узлы. Если просто разделить трафик в равных пропорциях, часть узлов уже ляжет под нагрузкой, а часть будет нагружена наполовину от своих возможностей. Но вот задача правильной балансировки была трудновыполнима из-за того, что не было нормальной модели и нормализованного мониторинга нагрузки.
А многим другим пластикам охлаждение и вовсе не критично Оно всем критично. Да, с некоторыми видами ненаполненных нейлонов или POM дуть нужно осторожно. Но для типовых PETG, ABS и HIPS нужен хороший и мощный обдув. Иначе нормальной детали не получится - все нависания украдут.
PLA я выше вообще не рассматривал в силу его относительной бесполезности. Проще заменить на HIPS и ABS в большинстве случаев.
Ветка началась с проблем с соплями от PETG и его сушкой. При жарком помещении в 30° разница при сушке будет составлять 35-40°. Этого достаточно для удаления молекулярно связанной воды за 8-12 часов. Да, даже во влажном помещении.
Вся вода, которая останется в филаменте будет вскипать в горячей зоне и выталкивать жидкий филамент. Именно поэтому самое важное - это сушка.
Зачем, конечно, direct экструдер, чтобы получить корректные ретракты без дёрганья растяжимой пружины в полуметровом боудене.
Ну и, конечно, правильно настроенный Pressure advance, который учитывает гидродинамику расплава на торможении и ускорении.
В финале калибровка ретрактов на башнях. Для PETG это обычно порядка 0.6-0.8 мм. В итоге идеально чистые поверхности без соплей и нитей. Физику расплава не обманешь в любом случае.
https://t.me/trinidad_creature/68
Держи бета-релиз)
Без проблем. Для резьбы я сделал люфт в 0.1 мм с каждой стороны.
Постараюсь сегодня отдать)
Там была скорее проблема быстрого хаотичного роста "потому что так сложилось". И на самом деле, не все так плохо. Это был первый этап, который закрывал текущую проблему и давал время на полноценный рефакторинг.
Несколько забегая вперед - оптимизировали, унифицировали и сумели убрать большую часть серверов при итоговом росте надежности. Так что это скорее история о том, что не всегда нужно брать и выбрасывать сразу.
С финансовой точки зрения, вопрос не в том, чтобы прибыли хватило, а в многократной разнице совокупной стоимости владения. Конкретные цифры я озвучить не могу, но сторонний CDN может быть существенно дороже хорошо оптимизированных bare-metal решений. Конечно, все это зависит от конкретного случая. В первую очередь свои сервера намного выгоднее при равномерной средней нагруженности.
Без проблем, напиши мне в @meklon в telegram. Прямо сейчас у нас нет найма новых сотрудников.
Всякое бывает. Часто это довольно старые проекты, которые внезапно обнаружили, что им нужно обслуживать тяжёлые нагрузки, и сделали как смогли. Да, многие решения могут выглядеть несколько необычно. Но они работают и приносят доход.
Поэтому, приходится все аккуратно и последовательно все оптимизировать.
У них часто интересные задачи , требующие необычных решений.
О, спасибо. Очень пригодится, как раз сейчас оптимизируем вместе с их разработчиками.
Я сейчас не про torrent, а в принципе про IPv6 трафик. А так согласен, это выглядит очень перспективно
Простите за такой кликбейт в формулировках. По сути, было необходимо обеспечить равномерность нагрузки на серверы с очень разными характеристиками, чтобы полностью утилизировать мощность.
Если часть уже откажет, а часть останется функциональными, то это не спасет в этой архитектуре. Вся группа уже будет нерабочей. Но да, в условиях идеальной балансировки они действительно синхронно падают при DDoS. Конечно, не в этом была основная цель, просто забавное наблюдение и критерий хорошей балансировки.
Возможно, IPv6 в итоге изменит ситуацию. Мы видели большие объемы трафика через него а ЮВА.
Там зоопарк) одновременно были варианты:
Канал безлимитный по общему трафику, но ограничен по ширине. Обычно это узлы по 1-2.5 гигабита.
Канал органичен по ширине, в стоимость входит пакет трафика, потом за дополнительные деньги.
Канал без формального лимита по ширине канала, пакета трафика нет, тарифицируются гигабайты.
Финансовую оптимизацию мы позднее делали, там вообще весело было. До полноценного мониторинга было сложно посчитать вообще что и сколько стоит.
Насчёт того, что мертвый сервер не должен отдаваться клиентам - я согласен. Но там были особенности, которые не давали это сделать.
Мы всегда придерживаемся идеи, что заказчик не просто так долгое время что-то строил. Вначале быстро решаем то, что болит прямо сейчас, а потом уже итеративно движемся оптимальному варианту.
На том этапе развития проблема была в том, что если сервер лег, то из нагрузки он автоматически не выводится. Пользователи страдали. Мы это реализовывали на более поздних этапах рефакторинга инфраструктуры.
Тут проблема была в том, что ресурсы были несбалансированы между собой. Есть мощные и дохлые узлы. Если просто разделить трафик в равных пропорциях, часть узлов уже ляжет под нагрузкой, а часть будет нагружена наполовину от своих возможностей.
Но вот задача правильной балансировки была трудновыполнима из-за того, что не было нормальной модели и нормализованного мониторинга нагрузки.
Спасибо. Прям интересно было бы прицепить акселерометр и осторожно снять картину резонансов с фанерой)
А оно имеет смысл в сравнении со свободными аналогами? Как мне кажется, корректнее в первую очередь их допиливать и использовать.
А многим другим пластикам охлаждение и вовсе не критичноОно всем критично. Да, с некоторыми видами ненаполненных нейлонов или POM дуть нужно осторожно. Но для типовых PETG, ABS и HIPS нужен хороший и мощный обдув. Иначе нормальной детали не получится - все нависания украдут.
Я не сравнивал с голым Marlin'ом. Более того, для включения baby step мне приходилось его пересобирать на Ender 3)
PLA я выше вообще не рассматривал в силу его относительной бесполезности. Проще заменить на HIPS и ABS в большинстве случаев.
Ветка началась с проблем с соплями от PETG и его сушкой. При жарком помещении в 30° разница при сушке будет составлять 35-40°. Этого достаточно для удаления молекулярно связанной воды за 8-12 часов. Да, даже во влажном помещении.
Вся вода, которая останется в филаменте будет вскипать в горячей зоне и выталкивать жидкий филамент. Именно поэтому самое важное - это сушка.
Зачем, конечно, direct экструдер, чтобы получить корректные ретракты без дёрганья растяжимой пружины в полуметровом боудене.
Ну и, конечно, правильно настроенный Pressure advance, который учитывает гидродинамику расплава на торможении и ускорении.
В финале калибровка ретрактов на башнях. Для PETG это обычно порядка 0.6-0.8 мм. В итоге идеально чистые поверхности без соплей и нитей. Физику расплава не обманешь в любом случае.