Комментарии 19
Это все хорошо и замечательно — но при использовании сторонних сервисов основные проблемы:
- Любое изменение АПИ внешнего поставщика — выводи из строя работу на сайте
- Все-же платно..
- Всегда есть версионность апи, но мы поступили по другому, один раз мы сменили API, но не могли никак сообщить об этом нескольким клиентам, кроме как подменять им картинки с сообщениями на английском языке. Но, мы пошли иным путем — редиректом. Т.е. старое апи осталось рабочим, а они сами зашли на сайт (обычно проверяешь изредка сервисы, с которыми сотрудничаешь, я например не могу налюбоваться на zilore) и сменили редирект на активную версию. В ASP.NET мы это вынесли в хелперы, сменить одно на другое, в случае необходимости — никаких проблем. Мы ведь пользуемся и сторонними сервисами тоже.
- Не могу ничего сказать, пока сервис абсолютно бесплатный, но рано или поздно мы будем вынуждены или ограничить поступление клиентов или вводить какие-то рамки. Но доступные аккаунты, полученные сейчас, будут работать по тем же правилам — бесплатно. Надо просто не злоупотреблять сервисом, не пытаться на нем выехать с посещаемостью уровня Ленты или Медузы какой, условно, но у них свои подрядчики и вряд-ли они посмотрят в нашу сторону:)
Меня лично, как пользователя, больше заботит доступность сервиса 24/7, а не работа раз от раза. Если происходят какие-то проблемы — знать о них. Если я хочу что-то сказать — чтобы меня услышали.
Скажите, а на вашем сервисе можно решить не менее актуальную задачу по сжатию изображений?
В частности имеется допустим много папок на нескольких доменах, с кучей изображений размером примерно под 10 Гб на каждом и нужно их сжать максимально, чтобы оптимизировались под проверку по Google Page Speed и GTmetirx.
Также следить за актуальностью и допустим раз в сутки увидеть новые файлы и аналогично сжать их.
Я знаю что есть подобные сервисы, но при текущих объёмах (и курсе доллара) суммы получаются какие-то очень внушительные.
В частности имеется допустим много папок на нескольких доменах, с кучей изображений размером примерно под 10 Гб на каждом и нужно их сжать максимально, чтобы оптимизировались под проверку по Google Page Speed и GTmetirx.
Также следить за актуальностью и допустим раз в сутки увидеть новые файлы и аналогично сжать их.
Я знаю что есть подобные сервисы, но при текущих объёмах (и курсе доллара) суммы получаются какие-то очень внушительные.
Нет, к сожалению пока нет такого параметра, как quality, но вопрос интересный. У вас они в разных форматов? У нас основной кейс это кэширование пережатых изображений, а вот просто компрессии нет. Плюс сами мы не можем узнать, появились у вас файлы или нет, т.е. запрос всегда идёт от клиентов, по сути — их браузеров. Первый запрос строит изображение, остальные его из кэша подтягивают, который с использованием ETag и Last-modified обновляется. Те сервисы, что я встречал и искал, все равно работали по запросу клиента. Но каждый из них имел тот или иной API, можно соответственно вызывать его скриптом, а не браузером. В любом случае писать что-то. Я не подскажу универсального рабочего решения к сожалению.
Интересуюсь ссылкой.
В принципе, у меня реализован собственный велосипед, между делом кроющий cloudinary :-) но всегда интересно посмотреть на чужое решение.
Тем более — на .NET и IIS (?!). Мы-то на go морочились, чтоб это пошустрее работало…
Насчет серверов — интересная тема: наш милтер картинок живет во франкфуртском ДЦ DO, оригиналы хранятся на AWS в германии же, и сколько мы ни пытались обработку/кэш перенести в РФ — ни черта не получилось. Тупо о-о-чень ме-е-едленно… В смысле, после прогрева кэша — все чудесно за счет меньшего пинга, но когда картинку надо выдрать из S3 для обработки — очень все плохо. Возникает ощущение, что наши компании, предоставляющие сервис VPS, экономят на аплинках в европу(?).
Ждем AWS или DO в России.
В принципе, у меня реализован собственный велосипед, между делом кроющий cloudinary :-) но всегда интересно посмотреть на чужое решение.
Тем более — на .NET и IIS (?!). Мы-то на go морочились, чтоб это пошустрее работало…
Насчет серверов — интересная тема: наш милтер картинок живет во франкфуртском ДЦ DO, оригиналы хранятся на AWS в германии же, и сколько мы ни пытались обработку/кэш перенести в РФ — ни черта не получилось. Тупо о-о-чень ме-е-едленно… В смысле, после прогрева кэша — все чудесно за счет меньшего пинга, но когда картинку надо выдрать из S3 для обработки — очень все плохо. Возникает ощущение, что наши компании, предоставляющие сервис VPS, экономят на аплинках в европу(?).
Ждем AWS или DO в России.
Да, на .NET и IIS. Нас не очень волнует первичная обработка, основной кейс работы заключается в том, что картинка создана, она лежит на Redis и отдается исключительно от туда, там же в фоне мониторинг и обновляется по мере необходимости. Ну и по верх этого панель прикручена, с графиками и небольшой статистикой, для понимания. Ссылка imagecdn.ru статья с главной ушла, надеюсь не сочтут за рекламу, уже больше суток прошло. У вас именно проблема в загрузке с AWS, тут надо искать каналы, которые позволят получить достойную скорость, возможно в каких-то ДЦ он и будет в России.
Спасибо, посмотрю.
Можете попробовать каналы у мэйла (mail.ru), они тут свой ДЦ для других открыли, публичный доступ и дают 3000р на тестирование. Там и хранилища есть, виртуалки можно развернуть, все по взрослому, но сам не пробовал. Зарегистрировался, но пока не использовал, вот хочу инстансы пары сервисов там запустить ради эксперимента.
Знач, так, отчитываюсь.
попробовать не удалось: не работает, множественные проблемы.
1. с главной ссылка на cp дает 404. при исправлении руками схемы на http прокатывает, можно регнуться. И даже добавить домен.
2. Но даже при этом условии отдает XML
картинку тестил вот такую:
У меня ее вертит как хошь с каменным лицом.
попробовать не удалось: не работает, множественные проблемы.
1. с главной ссылка на cp дает 404. при исправлении руками схемы на http прокатывает, можно регнуться. И даже добавить домен.
2. Но даже при этом условии отдает XML
<Error><Message>An error has occurred.</Message></Error>картинку тестил вот такую:
У меня ее вертит как хошь с каменным лицом.
Спасибо! Все просто, вы не подтвердили домен, в cp.imagecdn.ru в таблице доменов первая колонка, солнышко должно превратиться в галочку. Для этого нужно кликнуть на галочку, вернется файл, который нужно бросить в корень домена для подтверждения. Потому вам и возвращается ошибка. А вот с https спасибо, действительно, сертификата на панели нет, что более чем плохой тон, я этот вопрос решу на днях, а на корневом домене наверняка ссылка стоит вида \\:domainname, потому он и схватил https. Такая мелочь и так неприятно в результате.
П.С. Когда мы делали сервис, нам показалось что самое простое верифицировать его через файл на хосте, заморочки с DNS как-то сложнее, а файл с хэшем бросил и бросил себе, тем более после подтверждения его сразу можно удалить.
П.С. Когда мы делали сервис, нам показалось что самое простое верифицировать его через файл на хосте, заморочки с DNS как-то сложнее, а файл с хэшем бросил и бросил себе, тем более после подтверждения его сразу можно удалить.
Ну а я вот хотел попробовать картинку из инета. Это чужой домен, просто там картинка красивая и удобная. Но даже если бы я использовал большинство своих — у меня тупо нигде нет возможности быстро положить файл и отдать его из корня: везде сплошные прокси на апп сервера, nginx, в лучшем случае — статик генераторы с фиксированным деревом.
Или вот я бы мог использовать какой-нибудь свой S3, так там тоже в корень ничего не добавишь.
То есть, просто для того, чтобы потестить latency и качество обработки изображения мне надо:
1. продраться сквозь дебри регистрации на сайте
2. добавить домен, причем, несмотря на мой более чем 30летний опыт разработки, я не сумел сразу сделать этого правильно
3. зайти на VPS sshем, поменять конфиги вебсервера, уложить в специально созданный корень этот файл.
4. положить в корень этому домену картинку или настроить прокси
Не крутовато ли? Просто чтоб попробовать?
Ну уж сделали бы счетчик, что ли — 3 картинки (или 30) отдаем без регистрации… Да и все остальное, имхо, избыточно. Вот лично я даже по описаниям и прочему не увидел явного преимущества перед тем же Cloudinary, а если еще и просто попробовать настолько непросто… Или вы так, чисто теоретически хвастаетесь, а какое-либо использование не планируется?
Или вот я бы мог использовать какой-нибудь свой S3, так там тоже в корень ничего не добавишь.
То есть, просто для того, чтобы потестить latency и качество обработки изображения мне надо:
1. продраться сквозь дебри регистрации на сайте
2. добавить домен, причем, несмотря на мой более чем 30летний опыт разработки, я не сумел сразу сделать этого правильно
3. зайти на VPS sshем, поменять конфиги вебсервера, уложить в специально созданный корень этот файл.
4. положить в корень этому домену картинку или настроить прокси
Не крутовато ли? Просто чтоб попробовать?
Ну уж сделали бы счетчик, что ли — 3 картинки (или 30) отдаем без регистрации… Да и все остальное, имхо, избыточно. Вот лично я даже по описаниям и прочему не увидел явного преимущества перед тем же Cloudinary, а если еще и просто попробовать настолько непросто… Или вы так, чисто теоретически хвастаетесь, а какое-либо использование не планируется?
Нет, как раз для таких отзывов я и интересуюсь, думаем в какую сторону упростить. Для теста поддержка всегда может в ручном режиме подтвердить домен, вот сейчас у вас он заапрувлен мной. Но я подумаю лично, как сделать систему эту проще, чтобы без регистрации можно было пробовать, вы абсолютно правы. С Cloudinary ознакомлюсь, только тогда смогу сказать что-то по этому поводу.
Все, теперь сайт доступен по https с правильным сертификатом. Если активируете домен и попробуете — буду признателен.
А как вы обрабатываете? Первичная обработка, нет картинки в кэше. Прямо пришел запрос — обработали — сразу отдали? Или как-то интереснее? Волнует меня тема эта.
Ну а как еще можно?
Пришел запрос на thumb, если в кэше нет — отдали на бэкенд. Он проверяет кэш оригиналов, если есть — обрабатывает оригинал из кэша. Если нет, вытягивает картинку из AWS, сделал с ней что надо, отдал. И оригинал, и обработанный экземпляр кэшатся.
ну там много всякой мути по дороге…
Да, ессно, кэши разные: оригиналы кэшатся ненадолго, в расчете на то. что если кто-то запросил один размер, то есть большой шанс, что ему и другой размер той же картинки понадобится. А вот уменьшенные варианты кэшатся всерьез.
Пришел запрос на thumb, если в кэше нет — отдали на бэкенд. Он проверяет кэш оригиналов, если есть — обрабатывает оригинал из кэша. Если нет, вытягивает картинку из AWS, сделал с ней что надо, отдал. И оригинал, и обработанный экземпляр кэшатся.
ну там много всякой мути по дороге…
Да, ессно, кэши разные: оригиналы кэшатся ненадолго, в расчете на то. что если кто-то запросил один размер, то есть большой шанс, что ему и другой размер той же картинки понадобится. А вот уменьшенные варианты кэшатся всерьез.
Можно это делать синхронно, на общий бекенд, мы так делали изначально. А можно асинхронно разными способами, например у нас событие просто IIS примет, создаст задание и отправит его на выполнение и будет ждать события о том, что выполнилось все и тогда получит изображение из кэша. Т.е. не результат обработки от сервисов обработки, а именно от сервисов кэша, туда же перед тем как маякнуть событием об окончании той или ной обработки, положил его обработчик, допустим CropHandler. Вариантов по сути масса. Мы делали это для распределения нагрузки по нескольким серверам независимо, без балансировки нагрузки на базе бекенда, т.е. выбора при синхронном запросе одного из набора сервисов — обработчиков.
А еще мне нравится, когда разносортные сервисы через общую шину решат задачи независимо, при этом можно отключать то одни, то другие, а система устойчиво работает, забавно, как живой организм.
Допускаю, что это вопрос важный, хотя ни разу у нас не возникало какой-то очереди. Обработчик всегда совершенно пустой, хотя это самый дохлый и дешевый дроплет DO.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Изменение размеров изображений на сайте