Тест делал на личном хостинге в selectel с минимальной vds. Развернул там два контейнера. Картинку брал из соседнего контейнера. https://labeg.ru/content/images/portfolio/avilex/ncuo_10-1920w.jpg и ресайзил до 500 пикселей по ширине. Сетап был крайне простой, открывал картинку в браузере несколько раз без кеша и в нетворке замерял среднее время =)
ImageOpitimize - avif : 2.53s ImxProxy - avif : падало с кодом 503 и сообщением Timeout, но сейчас смотрю починили и теперь 2.57s
Для чистоты эксперимента в вашем тесте стоит указать ресайз отличный от исходного размера картинки =)
Ресурсоемкость замерял не совсем научным путем, но показательным. Фиолетовая рисочка ImgProxy, синяя ImageOptimize. В новой версии эта проблема так же решена =).
До пул реквестов ближайшее время, к сожалению, руки не дойдут. Микросервис у вас действительно интересный и возможно как ни будь попозже мы переключимся на него =)
imgproxy конвертирует в формат webp и avif в 2 раза дольше чем наш микросервис. Кроме того потребляется в 2 на webp и 4 на avif больше раз процессорных ресурсов. По оперативной памяти работают одинаково.
Не удалось найти опции для прохождения базовых авторизаций в закрытых контурах. А так же ограничений на источники данных, что бы предотвратить использование запущенного микросервиса для конвертации чужих картинок.
Как результат - imgproxy не удовлетворяет нашим потребностям.
Не так. Если картинка в 4 раза меньше, то у нее площадь в 16 раз меньше. Но там не линейная зависимость, поэтому ускоряется не в 16 раз, а в 8 примерно.
К своему стыду даже не знал что у nginx такая есть. Но наш вариант получился скорее по накатанной, был процесс оптимизаций на этапе сборки, он стал занимать много времени. Был налаженный процесс разработки фронтовых микросервисов. Мы решили объединить и получился такой результат =). К тому же наш микросервис поддерживает avif и можно пополнять необходимой логикой под наши потребности. Так же ждем выхода webp2 что бы сразу заюзать.
Немного не пойму математику `над мобильным приложением работали 4 разработчика из сторонней компании, а сегодня платформы поддерживают 60 штатных сотрудников` `конверсия в заказ выросла на 10%` т.е. при переходе с xamarin на более попсовые технологии стоимость разработки и поддержки выросла в 15 раз, а прибыль всего в 1.1 раза?
Полностью поддерживаю ваше мнение. Но встает вопрос - Ангуляр дает паттерн в организации и структуирования кода. Какого паттерна построения приложения придерживаться без ангуляра?
Настолько сильно что потом становится тяжело свести концы с концами, и понять какая цепочка экшенов отработала. Кроме того служебные расходы на перегенерацию стейта сильно превысят полезную нагрузку. Кроме того redux один не идет, к нему еще понадобится цепочка библиотек которые костыляют проблему синхронных экшенов и лишних перерисовок, всякие саги, реселекты и прочее. Вообще redux позиционирует себя как масштабируемое решение, но есть одно НО, относительно чего? А хорошо масштабируется оно относительно jquery скриптов, а относительно чистой архитектуры он наоборот создает проблему масштабирования.
А на самом деле хороший термин что бы отделить менеджера который в жизни ни строчки не написал, но при этом руководит разработкой, от успешного программиста который в тоже время успешный менеджер.
На моем опыте разработчики менеджеры делают гораздо более успешные продукты чем менеджеры проекта. А термин Product Engineer поможет таким людям самоопределиться и заняться своё место в продукте.
У меня выдалось время посмотреть конфиг. Теперь из коробки стартует с красивыми темой, обоями и ярлыками в быстром запуске.
Так же в свете плохих новостей о центосе, заменил базовый дистрибутив на fedora. Они бинарно совместимые, так что проблем с переходом не будет.
У них разные задачи:
Gulp это Таск Менедджер — служит для организации задач, сам по себе ничего не умеет, а всю работу делает через дополнения, например тот же роллап.
Rollup это Бандлер — служит для сборки кода в бандл.
Раньше всякие библиотеки были не очень дружелюбны к консольным инструментам и gulp хорошо решал свою задачу по настройке и запуску таких библиотек. Сейчас же почти любая библиотека затачивается под работу из консоли, поэтому gulp и перестал пользоваться популярностью.
Тоже когда то давно баловался google closure compiler и основная причина почему отказался от него это очень медленная скорость сборки, которая занимала несколько минут, в то время как browserify делал это за несколько секунд. Все таки -5% к размеру бандла не стоят +50% к времени разработки.
Но еще меня интересует почему Яндекс считает что поддерживать старые браузеры важнее чем поддерживать самые популярные браузеры? Я имею ввиду что TS может сам скомпилировать в ES2015, rollup/webpack собрать c treeshaking без babel трансформаций, terser минифицировать с учетом оптимизаций ES2015. И все это будет весить гораздо меньше транспилированного кода и работать в 3 раза быстрее на 80% самых популярных браузерах. А для старых сделать второй бандл на es5 с трансформами babel и полифилами.
Тест делал на личном хостинге в selectel с минимальной vds.
Развернул там два контейнера.
Картинку брал из соседнего контейнера. https://labeg.ru/content/images/portfolio/avilex/ncuo_10-1920w.jpg и ресайзил до 500 пикселей по ширине.
Сетап был крайне простой, открывал картинку в браузере несколько раз без кеша и в нетворке замерял среднее время =)
В итоге:
ImageOpitimize - webp : 152ms
ImxProxy - webp : 258ms
ImageOpitimize - avif : 2.53s
ImxProxy - avif : падало с кодом 503 и сообщением Timeout, но сейчас смотрю починили и теперь 2.57s
Для чистоты эксперимента в вашем тесте стоит указать ресайз отличный от исходного размера картинки =)
Ресурсоемкость замерял не совсем научным путем, но показательным.
Фиолетовая рисочка ImgProxy, синяя ImageOptimize. В новой версии эта проблема так же решена =).
До пул реквестов ближайшее время, к сожалению, руки не дойдут. Микросервис у вас действительно интересный и возможно как ни будь попозже мы переключимся на него =)
Выводы следующие:
imgproxy конвертирует в формат webp и avif в 2 раза дольше чем наш микросервис. Кроме того потребляется в 2 на webp и 4 на avif больше раз процессорных ресурсов. По оперативной памяти работают одинаково.
Не удалось найти опции для прохождения базовых авторизаций в закрытых контурах. А так же ограничений на источники данных, что бы предотвратить использование запущенного микросервиса для конвертации чужих картинок.
Как результат - imgproxy не удовлетворяет нашим потребностям.
Не так. Если картинка в 4 раза меньше, то у нее площадь в 16 раз меньше. Но там не линейная зависимость, поэтому ускоряется не в 16 раз, а в 8 примерно.
Спасибо! Поправил.
Если честно гугл мне его не показывал. Спасибо за наводку, изучим. Если удовлетворит нашим потребностям перенаправим клиентский компонент на него.
К своему стыду даже не знал что у nginx такая есть. Но наш вариант получился скорее по накатанной, был процесс оптимизаций на этапе сборки, он стал занимать много времени. Был налаженный процесс разработки фронтовых микросервисов. Мы решили объединить и получился такой результат =). К тому же наш микросервис поддерживает avif и можно пополнять необходимой логикой под наши потребности. Так же ждем выхода webp2 что бы сразу заюзать.
Немного не пойму математику
`над мобильным приложением работали 4 разработчика из сторонней компании, а сегодня платформы поддерживают 60 штатных сотрудников`
`конверсия в заказ выросла на 10%`
т.е. при переходе с xamarin на более попсовые технологии стоимость разработки и поддержки выросла в 15 раз, а прибыль всего в 1.1 раза?
Полностью поддерживаю ваше мнение. Но встает вопрос - Ангуляр дает паттерн в организации и структуирования кода. Какого паттерна построения приложения придерживаться без ангуляра?
Ответ Дяди Боба на эту статью. Надеюсь тоже переведёте.
habr.com/ru/post/496860
На моем опыте разработчики менеджеры делают гораздо более успешные продукты чем менеджеры проекта. А термин Product Engineer поможет таким людям самоопределиться и заняться своё место в продукте.
Так же в свете плохих новостей о центосе, заменил базовый дистрибутив на fedora. Они бинарно совместимые, так что проблем с переходом не будет.
Gulp это Таск Менедджер — служит для организации задач, сам по себе ничего не умеет, а всю работу делает через дополнения, например тот же роллап.
Rollup это Бандлер — служит для сборки кода в бандл.
Раньше всякие библиотеки были не очень дружелюбны к консольным инструментам и gulp хорошо решал свою задачу по настройке и запуску таких библиотек. Сейчас же почти любая библиотека затачивается под работу из консоли, поэтому gulp и перестал пользоваться популярностью.
Но еще меня интересует почему Яндекс считает что поддерживать старые браузеры важнее чем поддерживать самые популярные браузеры? Я имею ввиду что TS может сам скомпилировать в ES2015, rollup/webpack собрать c treeshaking без babel трансформаций, terser минифицировать с учетом оптимизаций ES2015. И все это будет весить гораздо меньше транспилированного кода и работать в 3 раза быстрее на 80% самых популярных браузерах. А для старых сделать второй бандл на es5 с трансформами babel и полифилами.