Не думаю что там что-то сверхъестественное. Я через NAT запустил (долго делать биндинг локального адреса на C#, а я голосую за то на чём написал), вон те 52k rps занимают примерно 50Mbps. Было бы не лень, у меня есть свободных 3Gbps полосы где-то, но это придётся руками сокеты открывать, а тут со сбором статистики и логированием кода на 70 строк получилось, потому что HttpClient взял и всё =)
На мой взгляд, основная проблема с S3 и прочими подобными системами это цена egress-трафика.
Даже с контрактными условиями под NDA (я его, к счастью, не подписывал, хотя и предлагали), которые составляют около 60% при 400+ТБ egress в месяц, это слишком дорого. Просто (относительно конструирования своего хранилища), да, но дорого.
Есть конечно промежуточное решение — пара/тройка кэширующих серверов в локальном ДЦ, но тут эффективность кэширования сильно зависит от типа сайта. У нас 1:8-1:10, но у того же Avito может быть совершенно другое соотношение.
А режим UAC «Always notify» не помогает? Ну то есть я понимаю, что если уже есть elevated-процесс, то там никаких подтверждений не будет, но этот процесс же ещё надо запустить, и в случае с «Always notify» оно без подтверждения не запускается.
P.S. Я знаю что по умолчанию он не такой, и это большой недостаток =)
Lepton всё-таки не производит файлы, пригодные для непосредственного использования, только для хранения, поэтому его отсутствие мне кажется естественным, а вот Guetzli (о котором уже написали ниже) очень хотелось бы увидеть.
Заодно напишу про денормализацию в рамках MongoDB. Большинство примеров и туториалов фокусируются на неизменяемых данных относительно небольшого размера. В реальности, если поместить даже несколько сотен комментариев к посту в один документ, "денормализовав" туда никнеймы пользователей и прочие элементы, то вас ждёт жестокое разочарование, потому что под нагрузкой это будет безбожно тормозить при материализации изменений, потому что MongoDB оперирует документами, а не полями (особенно грустно с массивами).
Основой же бонус, который я вижу, это отказ от join и логики на стороне БД. Есть исключения, конечно, но разделение read models и write model обычно полезнее, чем попытка сделать вид, что одни и те же данные используются всеми клиентами одинаково. В некоторых БД есть materialized views, но и это может быть не самым оптимальным решением при нетривиальной фильтрации.
Предпочту MongoDB Postgres-у any day с административной и интеграционной точки зрения.
Postgres шагает в нужную сторону, но пока там не будет автоматического надёжного failover и поддержки streaming replication хотя бы с меньшей версии к большей, я так и буду плакать, когда нужно обновить версию или перезагрузить подлежащую железку. Существующие же решения для организации кластера требуют тонкой настройки, иногда разваливаются и не совсем прозрачны для приложения.
Разумеется это всё про [near] zero-downtime, если этого не требуется, то как БД Postgres лучше почти со всех сторон.
А, ну и .NET-драйвер для Postgres просто ужасен (в плане производительности и дизайна обработки ошибок), правда.
Чисто декларативное описание это прекрасно, но недостаточно гибко и для введения новой функциональности требует обновления toolset. Msbuild же, при всей громоздкости синтаксиса уже сложился и имеет кучу инструментов, которые упрощают процесс сборки, в том числе сложной и автоматизированной. Когда msbuild не было для платформ, отличных от Windows, в новом инструменте был существенный смысл, но теперь уже нет.
Я уверен, что и project.json можно было развить до такого состояния, но с учётом описанного выше, мне кажется что возврат к msbuild более логичный шаг. К сожалению, Microsoft могли бы додуматься до этого раньше, сложившаяся ситуация с необходимостью миграции, конечно далека от идеала.
Существенное количество людей считает, что sRGB имеет гамму 2.2 (или 2.24). Это не так, степень там 2.4, но для имитации особенностей человеческого зрения, для тёмных цветов (low-light) используется линейная шкала. То есть на самом деле часть функции это просто линейная функция, а часть — степенная.
А поддержка lifecycle rules есть? Интересуют и на transition и на expiration.
Например "~10^9 объектов, ~500ТБ чистого места".
Даже с контрактными условиями под NDA (я его, к счастью, не подписывал, хотя и предлагали), которые составляют около 60% при 400+ТБ egress в месяц, это слишком дорого. Просто (относительно конструирования своего хранилища), да, но дорого.
Есть конечно промежуточное решение — пара/тройка кэширующих серверов в локальном ДЦ, но тут эффективность кэширования сильно зависит от типа сайта. У нас 1:8-1:10, но у того же Avito может быть совершенно другое соотношение.
Поздравляю, вы задали правильный вопрос :)
Теперь можно пойти почитать http://blog.ploeh.dk/2017/01/27/from-dependency-injection-to-dependency-rejection/ :)
P.S. Я знаю что по умолчанию он не такой, и это большой недостаток =)
Жаль что нет статьи за некомпетентность в Интернете :)
Заодно напишу про денормализацию в рамках MongoDB. Большинство примеров и туториалов фокусируются на неизменяемых данных относительно небольшого размера. В реальности, если поместить даже несколько сотен комментариев к посту в один документ, "денормализовав" туда никнеймы пользователей и прочие элементы, то вас ждёт жестокое разочарование, потому что под нагрузкой это будет безбожно тормозить при материализации изменений, потому что MongoDB оперирует документами, а не полями (особенно грустно с массивами).
Основой же бонус, который я вижу, это отказ от join и логики на стороне БД. Есть исключения, конечно, но разделение read models и write model обычно полезнее, чем попытка сделать вид, что одни и те же данные используются всеми клиентами одинаково. В некоторых БД есть materialized views, но и это может быть не самым оптимальным решением при нетривиальной фильтрации.
Предпочту MongoDB Postgres-у any day с административной и интеграционной точки зрения.
Postgres шагает в нужную сторону, но пока там не будет автоматического надёжного failover и поддержки streaming replication хотя бы с меньшей версии к большей, я так и буду плакать, когда нужно обновить версию или перезагрузить подлежащую железку. Существующие же решения для организации кластера требуют тонкой настройки, иногда разваливаются и не совсем прозрачны для приложения.
Разумеется это всё про [near] zero-downtime, если этого не требуется, то как БД Postgres лучше почти со всех сторон.
А, ну и .NET-драйвер для Postgres просто ужасен (в плане производительности и дизайна обработки ошибок), правда.
Пожалуйста, но если что, то это мои личные ощущения, у создателей набор причин может быть совсем другим :)
Чисто декларативное описание это прекрасно, но недостаточно гибко и для введения новой функциональности требует обновления toolset. Msbuild же, при всей громоздкости синтаксиса уже сложился и имеет кучу инструментов, которые упрощают процесс сборки, в том числе сложной и автоматизированной. Когда msbuild не было для платформ, отличных от Windows, в новом инструменте был существенный смысл, но теперь уже нет.
Я уверен, что и project.json можно было развить до такого состояния, но с учётом описанного выше, мне кажется что возврат к msbuild более логичный шаг. К сожалению, Microsoft могли бы додуматься до этого раньше, сложившаяся ситуация с необходимостью миграции, конечно далека от идеала.
Посматриваю свысока с удовольствием, ваш нематёрый неэнтерпрайзник :)
И, к счастью, избавляются от него :)
Ничего не мешает устать в офисе так же как и в шахте. Человек не состоит из одних мышц или одного мозга.