Comments 156
И почему я сразу подумал об ImageMagic?
> задействуя четыре 16-ядерных сервера
Ну, это в значительной мере объясняет такую скорость обработки )
А вот про GraphicsMagick не знал… нужно будет попробовать.
Ну, это в значительной мере объясняет такую скорость обработки )
А вот про GraphicsMagick не знал… нужно будет попробовать.
Отлично :)
Программисты вынуждены проявлять недюжинную смекалку иза-за промахов дизайнера и проектировщика UI («старые превью-окошки не вписываются в новые шаблоны страниц»), и при этом еще проводить психологические опыты над собственным руководством ("… очень важно, чтобы руководство не видело на странице информацию о параметрах компрессии каждой картинки...").
Кто-то сомневается, что программист — профессия XXI века? :)
Программисты вынуждены проявлять недюжинную смекалку иза-за промахов дизайнера и проектировщика UI («старые превью-окошки не вписываются в новые шаблоны страниц»), и при этом еще проводить психологические опыты над собственным руководством ("… очень важно, чтобы руководство не видело на странице информацию о параметрах компрессии каждой картинки...").
Кто-то сомневается, что программист — профессия XXI века? :)
> иза-за промахов дизайнера и проектировщика UI
Это не промахи, а вполне рабочие моменты.
Это не промахи, а вполне рабочие моменты.
Если судить по тексту, то «после смены дизайна оказалось», а вовсе не было изначально задумано.
Я обычно такие «оказии», когда работа одного человека порождает пустую, в общем-то, работу для другого, расцениваю именно как промахи :)
Я обычно такие «оказии», когда работа одного человека порождает пустую, в общем-то, работу для другого, расцениваю именно как промахи :)
Все-таки это не промах, просто поменялся дизайн и из-за этого иногда меняются размеры превью, потому что при редизайне часто меняются размеры элементов дизайна сайта. Просто был старый дизайн, там были картинки например 150х100, потом дизайнер придумал новый дизайн и там размер кратинок изменился
дык в том-то и дело, что «мужики-то и не знали». Промах в несогласованности действий разных подразделений компании. Обычное дело.
Есть такой тип овнодизайнеров, которые меняют размеры превьюшек, лишь бы поменять, лишь бы было по другому, дизайн-то новый епта. Не задумываясь, зачем они это делают.
А есть те, кто делает это обоснованно. Полагаю, тут как раз такой случай.
А есть те, кто делает это обоснованно. Полагаю, тут как раз такой случай.
Вот хороший кандидат в качестве ответа на вопрос, «обоснованно или нет».
Текущий образец превьюшки с www.etsy.com/, 170х153, файл ny-image3.etsy.com/il_170x135.124446939.jpg
Предыдущий вариант, найден через web.archive.org, 155х125, файл ny-image3.etsy.com/il_155x125.98513191.jpg
Коллега, вы видите разницу? Считаете ее достаточным основанием для программистской смекалки и четырех 16-ядерных серверов на 9 суток? :)
Только честно :)
Текущий образец превьюшки с www.etsy.com/, 170х153, файл ny-image3.etsy.com/il_170x135.124446939.jpg
Предыдущий вариант, найден через web.archive.org, 155х125, файл ny-image3.etsy.com/il_155x125.98513191.jpg
Коллега, вы видите разницу? Считаете ее достаточным основанием для программистской смекалки и четырех 16-ядерных серверов на 9 суток? :)
Только честно :)
Да, достаточным. По крайней мере, если целью было повышение конверсии и изменение вида страницы для этого. Чуть более большие картинки могут (в связке с остальным) дать повышение конверсии на 1-2%, что в масштабах аукциона сможет за короткий период окупить затраты на изменение и дальше работать в плюс.
Если программист в чем-то не видит смысл, это не значит, что его нет.
Если программист в чем-то не видит смысл, это не значит, что его нет.
Хм. Это философский вопрос, однако. Я не уверен, можно ли его вообще измерить сплит-тестами.
Обратите внимание: речь идет о превьюшках на страницах категорий, где много продуктов, а не о странице конкретного продукта, где расположена кнопка добавления в корзину.
Таким образом единственный параметр, на который могли потенциально влиять размеры превьюшек — это процент перехода из категорий к страницам конкретных продуктов.
Его легко померять аналитиксом, но — тут уже мое глубокое имхо — есть МАССА других факторов, которые влияют гораздо больше, нежели размер превьюшки. Тем более при такой смешной разнице: 170x135 вместо 155x125 :)
Обратите внимание: речь идет о превьюшках на страницах категорий, где много продуктов, а не о странице конкретного продукта, где расположена кнопка добавления в корзину.
Таким образом единственный параметр, на который могли потенциально влиять размеры превьюшек — это процент перехода из категорий к страницам конкретных продуктов.
Его легко померять аналитиксом, но — тут уже мое глубокое имхо — есть МАССА других факторов, которые влияют гораздо больше, нежели размер превьюшки. Тем более при такой смешной разнице: 170x135 вместо 155x125 :)
Меряется очень просто, считаются все затраты на редизайн (работа дизайнеров, юзабилистов, программистов, верстальщиков итд), смотрится на усредненное изменение конверсии, рассчитывается за сколько окупается работа. На основе этого уже делают вывод о полезности изменения.
На больших масштабах разница в пару байт или пикселей вполне может быть существенной.
На больших масштабах разница в пару байт или пикселей вполне может быть существенной.
Не могу с вами согласиться. Меряются такие вещи не просто, а очень сложно (это я по собственному опыту, не навязывая своего мнения).
Тезисы следующие:
1. Размер превьюшки напрямую не может влиять на конверсию (если мы под конверсией оба понимаем отношение посетителей к покупателям), потому что страница с превьюшками не ведет непосредственно к действию «положить в корзину».
2. Изменений при редизайне много, они все влияют на поведение посетителей по-разному. Вычленить влияние каждого из факторов можно только сплит-тестингом, когда изменения изолированы одно от другого.
3. Результатом сплит-тестов в данном случае может быть только контроль изменения параметра переходов из категории к продукту, но никак не конверсия посетителей в покупателей (см. п. 1)
Тезисы следующие:
1. Размер превьюшки напрямую не может влиять на конверсию (если мы под конверсией оба понимаем отношение посетителей к покупателям), потому что страница с превьюшками не ведет непосредственно к действию «положить в корзину».
2. Изменений при редизайне много, они все влияют на поведение посетителей по-разному. Вычленить влияние каждого из факторов можно только сплит-тестингом, когда изменения изолированы одно от другого.
3. Результатом сплит-тестов в данном случае может быть только контроль изменения параметра переходов из категории к продукту, но никак не конверсия посетителей в покупателей (см. п. 1)
Дизайн меняют по-хорошему не дизайнеры, а юзабилисты (сначала), потом дизайнеры просто реализовывают их пожелания. Вот эти юзабилисты обосновывают каждое изменение (в том числе и размеров).
Изменени размера влияет на кликабельность напрямую, если есть сайт с большой посещаемостью, можно повесить тизеры, замерять средний СTR за неделю, потом с теми-же объявлениями, изменить размер и провести замер повторно. Для чистоты эксперимента, показывать не больше 1 раза посетителю такие тизеры за все время.
Я в свое время тестировал такие вещи в разных вариациях, и размер картинок роль играет (еще правда нужно соблюсти баланс с количеством картинок на экране и странице).
Программеру эти вещи вообще знать не нужно, ему дали задание, он реализовывает и отвечает за результат выполнения своего задания. Есть люди, что отвечают за конверсию и прочие параметры, они уже решают что важно, с них за это спросят. В том числе и за потраченное в пустую время, если редизайн не окупится.
Изменени размера влияет на кликабельность напрямую, если есть сайт с большой посещаемостью, можно повесить тизеры, замерять средний СTR за неделю, потом с теми-же объявлениями, изменить размер и провести замер повторно. Для чистоты эксперимента, показывать не больше 1 раза посетителю такие тизеры за все время.
Я в свое время тестировал такие вещи в разных вариациях, и размер картинок роль играет (еще правда нужно соблюсти баланс с количеством картинок на экране и странице).
Программеру эти вещи вообще знать не нужно, ему дали задание, он реализовывает и отвечает за результат выполнения своего задания. Есть люди, что отвечают за конверсию и прочие параметры, они уже решают что важно, с них за это спросят. В том числе и за потраченное в пустую время, если редизайн не окупится.
Коллега, таки предлагаю пользоваться однозначными терминами :)
Что вы понимате под кликабельностью? Процент переходов на страницу продукта (см. тезис №3)? Или результирующую конверсию (см. №1)?
Если процент переходов на страницу продукта, то из самых общих соображений смею утверждать, что здесь главное — количество превьюшек на странице, а никак не размер отдельной картинки-ссылки :)
Кроме того, есть еще интересный способ — не увеличивая картинку, увеличьте просто «поле клика», и без того обозначенное сейчас светлой рамкой; можно для дополнительного эффекта выделять их зветом фона (шахматкой, через один).
Что вы понимате под кликабельностью? Процент переходов на страницу продукта (см. тезис №3)? Или результирующую конверсию (см. №1)?
Если процент переходов на страницу продукта, то из самых общих соображений смею утверждать, что здесь главное — количество превьюшек на странице, а никак не размер отдельной картинки-ссылки :)
Кроме того, есть еще интересный способ — не увеличивая картинку, увеличьте просто «поле клика», и без того обозначенное сейчас светлой рамкой; можно для дополнительного эффекта выделять их зветом фона (шахматкой, через один).
кликабельность = CTR
это проще всего мерять.
Вы то, что утверждаете тестировали или просто так думаете? Потому, как ваши советы немного не сходятся с практикой.
это проще всего мерять.
Вы то, что утверждаете тестировали или просто так думаете? Потому, как ваши советы немного не сходятся с практикой.
CTR = click through rate, важный параметр для интернет-рекламы, отношение кликов по рекламному объекту (баннера, текстового блока и т.п.) к количеству показов данного объекта. Применять термин CTR к чему-то другому (здесь — к кликам по превьюшке продукта, одной из многих на странице) считаю некорректным.
Это такой интеллигентный вариант тезиса «Сперва добейся»? :)
Наша компания продает софт для интернет-магазинов (в двух собственных магазинах), сам я занимался в свое время и разработкой интерфейса одного из них, и сплит-тестингом, и аналитикой, и рекламой через GA.
Это такой интеллигентный вариант тезиса «Сперва добейся»? :)
Наша компания продает софт для интернет-магазинов (в двух собственных магазинах), сам я занимался в свое время и разработкой интерфейса одного из них, и сплит-тестингом, и аналитикой, и рекламой через GA.
Это вариант тезиса «сперва проверь». Я ни к чему CTR не примерял, кроме как тизерам.
Хотите посмотреть на опыт других: marketgid.com. Они выкупают показы, а продают клики, следовательно заинтересованы в максимальном CTR.
Зависит CTR у них от объявлений (текстов/картинок) и того, как они представлены. Возьмем простой пример, вся страница в тизерах, чтобы не зависеть от внешнего сайта.
Страница имеет вот такой вид: marketgid.info/bestsellers.html?s=9623
Картинки большие.
У них есть сайты, на которые они гонят новостной трафик, чтобы превратить в товарный. Вот пример: shockodrom.com/news/5049.html (тексты не читайте, целее мозг будет). Обратите внимание, картинки тоже большие!
Почему они используют меньше больших картинок там, где можно использовать больше мелких? Считаете там не знают, где будет выше CTR?
У вас нет опыта, но вы пытаетесь кого-то учить жизни. Нет данных по конверсии, но рассказываете, какие все идиоты. Зачем?
Поставьте мне минус в карму и давайте закроем тему. Считайте и дальше, что нет важнее человека в аукционе, чем программист.
Хотите посмотреть на опыт других: marketgid.com. Они выкупают показы, а продают клики, следовательно заинтересованы в максимальном CTR.
Зависит CTR у них от объявлений (текстов/картинок) и того, как они представлены. Возьмем простой пример, вся страница в тизерах, чтобы не зависеть от внешнего сайта.
Страница имеет вот такой вид: marketgid.info/bestsellers.html?s=9623
Картинки большие.
У них есть сайты, на которые они гонят новостной трафик, чтобы превратить в товарный. Вот пример: shockodrom.com/news/5049.html (тексты не читайте, целее мозг будет). Обратите внимание, картинки тоже большие!
Почему они используют меньше больших картинок там, где можно использовать больше мелких? Считаете там не знают, где будет выше CTR?
У вас нет опыта, но вы пытаетесь кого-то учить жизни. Нет данных по конверсии, но рассказываете, какие все идиоты. Зачем?
Поставьте мне минус в карму и давайте закроем тему. Считайте и дальше, что нет важнее человека в аукционе, чем программист.
Коллега, не надо «меряться опытом» и переходить на личности, это непродуктивно и неинтересно. Последний абзац вынужден проигнорировать как не относящийся к делу. :)
Я почему с вами тут беседую? Не для того, чтобы вас или кого-то чему-то учить, а потому, что мне самому интересно — где тут истина.
Вот конкретно здесь мне кажется, что именно вы меня не понимаете, а не я — вас. Вы упорно пишете о рекламе, тизерах и CTR. В то время как обсуждаемый сайт совсем из другой оперы — это магазин (а не аукцион, как написано в посте).
Согласитесь, страница с тизерами, где цель — получить клик, — это совсем не то, что страница категории в магазине, где цель — довести дело до покупки?
Если вам, как и мне, в беседе важно не переспорить собеседника любыми средствами, а что-то выяснить для обоих по делу — думаю, мы доберемся до истины к обоюдной пользе :)
Я почему с вами тут беседую? Не для того, чтобы вас или кого-то чему-то учить, а потому, что мне самому интересно — где тут истина.
Вот конкретно здесь мне кажется, что именно вы меня не понимаете, а не я — вас. Вы упорно пишете о рекламе, тизерах и CTR. В то время как обсуждаемый сайт совсем из другой оперы — это магазин (а не аукцион, как написано в посте).
Согласитесь, страница с тизерами, где цель — получить клик, — это совсем не то, что страница категории в магазине, где цель — довести дело до покупки?
Если вам, как и мне, в беседе важно не переспорить собеседника любыми средствами, а что-то выяснить для обоих по делу — думаю, мы доберемся до истины к обоюдной пользе :)
Что значит не надо меряться опытом? Пиписьками что ли меряться?
Опыт, как правило, и позволяет сказать есть в чем-то смысл или нет.
В данном случае, я пытаюсь на чужом опыте продемонстрировать что ваше утверждение Если процент переходов на страницу продукта, то из самых общих соображений смею утверждать, что здесь главное — количество превьюшек на странице, а никак не размер отдельной картинки-ссылки :) не верно.
У меня тоже есть тизерная сеть и там я получаю аналогичные выводы, просто она нишевая, а не с миллонами говнотрафика, потому в пример привожу тех, кто известен, в том числе и масштабами.
Понятно, что клик это еще не покупка, но без клика и покупки не будет. Я просто привожу пример того, что размер имеет значение.
Сейчас как раз помогаю готовить доклад на завтрашнюю конференцию по юзабилити в Харькове. Организаторы конференции как раз и занимаются повышением конверсии с помощью юзабилити. Сам я не еду (едет коллега), порошу задать вопрос о том, как подобное изменение может улучшить продажи и почему. Может быть ответ профильного специалиста вас больше устроит, чем мои доводы в стиле «юзабилисты знают что делают и отвечают за результат, не нужно учить их жизни».
Опыт, как правило, и позволяет сказать есть в чем-то смысл или нет.
В данном случае, я пытаюсь на чужом опыте продемонстрировать что ваше утверждение Если процент переходов на страницу продукта, то из самых общих соображений смею утверждать, что здесь главное — количество превьюшек на странице, а никак не размер отдельной картинки-ссылки :) не верно.
У меня тоже есть тизерная сеть и там я получаю аналогичные выводы, просто она нишевая, а не с миллонами говнотрафика, потому в пример привожу тех, кто известен, в том числе и масштабами.
Понятно, что клик это еще не покупка, но без клика и покупки не будет. Я просто привожу пример того, что размер имеет значение.
Сейчас как раз помогаю готовить доклад на завтрашнюю конференцию по юзабилити в Харькове. Организаторы конференции как раз и занимаются повышением конверсии с помощью юзабилити. Сам я не еду (едет коллега), порошу задать вопрос о том, как подобное изменение может улучшить продажи и почему. Может быть ответ профильного специалиста вас больше устроит, чем мои доводы в стиле «юзабилисты знают что делают и отвечают за результат, не нужно учить их жизни».
Примеры с тизерной сетью, рекламой и CTR — нерелевантны, я ведь уже дважды об этом аргументированно написал. Тизеры, покупка-продажа трафика — это одна сфера, она меня не очень интересует и к делу не относится; поведение человека в интернет-магазине — другая сфера, в ней я разбираюсь. :)
Поэтому и не предлагаю меряться опытом, — полагаю, что в области интернет-магазинов он у меня явно больше :)
Поэтому меня и удивляет настойчивое упоминание CTR, который отношения к категории товаров в интернет-магазине не имеет. Продукты на странице категории — не тизеры, клик по картинке — не самоцель, и сам по себе денег он не приносит (в отличие от клика по баннеру или страничке с тизерами).
Размер имеет значение! Кто же спорит. Но в интернет-магазине разница в 22% площади картинки влияет на поведение пользователя исчезающе мало! :) По сравнению с остальными факторами, можно сказать. что и вовсе не влияет.
Поэтому и не предлагаю меряться опытом, — полагаю, что в области интернет-магазинов он у меня явно больше :)
Поэтому меня и удивляет настойчивое упоминание CTR, который отношения к категории товаров в интернет-магазине не имеет. Продукты на странице категории — не тизеры, клик по картинке — не самоцель, и сам по себе денег он не приносит (в отличие от клика по баннеру или страничке с тизерами).
Размер имеет значение! Кто же спорит. Но в интернет-магазине разница в 22% площади картинки влияет на поведение пользователя исчезающе мало! :) По сравнению с остальными факторами, можно сказать. что и вовсе не влияет.
Не тратьте время, вас не понимают.
Есть еще момент: трафик. картинки по объему меньше стали. если даже на 20% то уже суперплюс
С этим нельзя не согласиться.
Авторам многих статей на хабре это расскажите.
По площади больше, возможно просто от самой картинки в данном случае зависит (на старой больше деталей). Или чуть хуже качество в итоге или более эффективный алгоритм.
Вообще, если преследовали цель уменьшить трафик с картинок, то ресайзить в данном случае бы не пришлось. Скорее бонусом получилось просто (если это действительно так)
Вообще, если преследовали цель уменьшить трафик с картинок, то ресайзить в данном случае бы не пришлось. Скорее бонусом получилось просто (если это действительно так)
Если бы при создании preview действительно думали, то она никогда не стала бы 153 пиксела. Была бы 168x152.
Собственно все ясно теперь. Ну работа админская все равно достойна уважения. Пост то о них родимых.
По-нормальному, как только стало известно, что ресайзинг всех картинок под новый дизайн займёт длительное время или потребует сильных вливаний средств, руководство должно было дать пендель дизайнерам и сказать, что «А теперь ПЕРЕДЕЛАЙТЕ, что-бы картинки были ВОТ ТАКОГО КАК РАНЬШЕ РАЗМЕРА!»…
Можно было бы конечно не менять 20 лет дизайн, или масштабировать картинки через css. И это было бы счастье без «работы впустую». Ну вы поняли.
Пустую, в общем-то, работу для четырех 16-ядерных серверов на 9 суток. Я молчу про самих программистов.
Именно так, уважаемый коллега. :)
Работу, требующую существенных ресурсов людских и машинных, которая не приносит пользы делу и без которой можно было бы обойтись вообще, если бы на предыдущем этапе кто-то подумал и поступился какими-то незначащими моментами — именно такую работу я назвал пустой.
Вы не согласны? :)
Работу, требующую существенных ресурсов людских и машинных, которая не приносит пользы делу и без которой можно было бы обойтись вообще, если бы на предыдущем этапе кто-то подумал и поступился какими-то незначащими моментами — именно такую работу я назвал пустой.
Вы не согласны? :)
Я уточнил масштабы. Объем изысканий программеров — отдельная песня.
Вы уверенны, что это не принесло пользы? Есть цифры про конверсии до и после?
Коллега, я ответил здесь.
интересный пост в бложек с отчетом о проделаной работе тоже дорогого стоит
Привет! Согласен :)
Слушай, глянь-ка вот сюда:
habrahabr.ru/blogs/webdev/99108/#comment_3057143
И вниз по треду. Это я туплю или мой собеседник тупит? Я ему про магазин, просмотры продуктов и финальную конверсию, а он мне про рекламу, тизеры и CTR. Где именно я непонятно выражаюсь? :)
Слушай, глянь-ка вот сюда:
habrahabr.ru/blogs/webdev/99108/#comment_3057143
И вниз по треду. Это я туплю или мой собеседник тупит? Я ему про магазин, просмотры продуктов и финальную конверсию, а он мне про рекламу, тизеры и CTR. Где именно я непонятно выражаюсь? :)
Не совсем впустую — размер превьюшек стал меньше, стало быть и размер файликов должен был уменьшиться. Сколько они после этого сэкономят на траффике? Хотя в остальном — согласен полностью.
Размер превьюшек стал больше, см. habrahabr.ru/blogs/webdev/99108/#comment_3057143
Ага, уточнение подоспело.
Размеры картинок увеличились, а вот объем (размер файлов) действительно они уменьшили. Отсюда и психологические эксперименты над руководством по выбору уровня сжатия.
Размеры картинок увеличились, а вот объем (размер файлов) действительно они уменьшили. Отсюда и психологические эксперименты над руководством по выбору уровня сжатия.
Да все понятно, что рабочие, но я бы не выдержал и набросился на дизайнера за такое. 135 миллионом картинок… капец.
Хабр уже не тот. В посте про интересные задачи для программиста разрастается просто фееричный тред «Ой, ну ппц, как я не хочу ничего делать и придумывать, дайте нам клепать визитки». Ну и что, что 135 миллионов картинок? Ну и что, что 16-ядерники? Эти затраты единовременные и окупаются новым нормальным дизайном с нормальными превьюшками.
Когда возразить что-то трудно — проще поставить минус.
Не обращайте внимания. «Программисты» на Хабре считают, что веб-программист не должен править CSS (пусть даже и в одной строчке), не должен проектировать базу, не должен уметь настраивать веб-сервера и т.п. «Программисты» считают, что они — короли вселенной, а остальные должны крутиться вокруг них.
Как-то в комментариях проскакивало обсуждение стартапа, который делали два программиста без дизайнера и вообще всякого конкретного разделения обязанностей. Так вот человека раскритиковали, что он не наняли дизайнера, верстальщика, админа, проектировщика БД и еще кого-то, уже не помню. Это было феерично.
Что такие «программисты» понимают под программированием и какой смысл видят в своей работе остается только предполагать.
ЗЫ: На всякий случай — я сам программист.
Как-то в комментариях проскакивало обсуждение стартапа, который делали два программиста без дизайнера и вообще всякого конкретного разделения обязанностей. Так вот человека раскритиковали, что он не наняли дизайнера, верстальщика, админа, проектировщика БД и еще кого-то, уже не помню. Это было феерично.
Что такие «программисты» понимают под программированием и какой смысл видят в своей работе остается только предполагать.
ЗЫ: На всякий случай — я сам программист.
Программистам респект, качественный подход к делу. Но забавно, что не зная ситуации в контексте, вы уже делаете вывод, что кто-то виноват, а кто-то мученик.
По идее можно было конвертить изображения по ходу: если нет — конвертим и пишем, если есть — тащим напрямую. Юзеры особого замедления, думаю, не заметили бы.
что-то там было недавно про pageRank и время отклика сайта…
Ну посчитайте. 180 в секунду они делали кучей всяких тулз. Если сделать это соответствующем модулем nginx, думаю, медленнее точно не будет. т.е. замедление на запрос картинки (на которую, гуглю, кстати, совершенно пофиг) будет 1/180 секунды.
Какой тучей тулз? Одним оптимизированным Graphics Magick'ом — очень быстро работающей консольной утилитой. Про Graphicks Magick я раньше не слышала, а вот ImageMagick опробован лично — при обращении напрямую из PHP (через exec) превьюшка генерится просто мгновенно, в то время как PHP-GD затрачивает на изготовление этой же превьюшки n милисекунд. Где n напрямую зависит от размера исходного изображения. Про ресурсоемкость и качество и вовсе молчу. Генерить nginx'ом не пробовала, но мне кажется, что качество будет ниже, чем у специализированного графического приложения, которому можно к тому же задавать различные параметры.
Да, верно. И с кучей ошибся и, возможно, со скоростью nginx (GD) против скорости ImageMagick.
Ресайз изображений на лету с помощью nginx
4 сервера, 2 ядра на задачу — уже 1/5 секунды без учёта дополнительных тормозов нфс.
Причём тут время отклика сайта и время отклика превьюшки изображения? Сам сайт откликается точно так же, а вот когда запрашивается превьюшка — то отдаётся она чуть-чуть медленнее, если для неё ещё не создана версия новых размеров.
это не превьюшка изображения, а картинка на странице.
Например, webpagetest считает документ загруженным вместе с картинками
а Вы знаете что google включает в pageRank? — поделитесь ссылкой
Например, webpagetest считает документ загруженным вместе с картинками
а Вы знаете что google включает в pageRank? — поделитесь ссылкой
Имхо, EBay на PageRank мягко говоря…
Что-то мне подсказывает, что на странице может быть и куча превьюшек.
Далее — сайт явно популярен, и если запросят одновременно 200 страниц по 20 картинок, то кластер указанный за секунду получит 20 своих секундных норм.
Замедление от 20-ти превью будет существенным.
Далее — сайт явно популярен, и если запросят одновременно 200 страниц по 20 картинок, то кластер указанный за секунду получит 20 своих секундных норм.
Замедление от 20-ти превью будет существенным.
бутылочное горлышко — это узкое место (… не то)
нужно было в китайцах посчитать :)
интересно кто нибудь пробовал использовать клиентские машины в качестве ресурсов, в браузере вполне можно изменить размер изображения и вернуть серверу?!
Потрясающая работа, нет слов.
кстати, nginx умеет «на лету», т.е. по запросу генерить превьюхи. И не нужно препроцессинг такой делать мощный.
как думаете, лучше одну картинку один раз ресайзить или 20 миллионов раз (ну ладно, с кешированием 2 тыс раз)?
после ресайзинга на лету стоило бы класть не в кэш, а в то самое укромненькое местечко, где сейчас все эти превьюхи лежат ;)
извините, мне разрешено писать коммент в час.
при использовании онлайн-рисайза через nginx будет все равно лишний напряг — как минимум проверка наличия файла с кешем. Превьюшек много и они, скорее всего, на разных серверах. Самих серверов у них тоже наверняка, Вы же не предлагаете натривить на них один nginx :)
Все не так очевидно, слишком много заморочек с онлайн-ресайзом.
при использовании онлайн-рисайза через nginx будет все равно лишний напряг — как минимум проверка наличия файла с кешем. Превьюшек много и они, скорее всего, на разных серверах. Самих серверов у них тоже наверняка, Вы же не предлагаете натривить на них один nginx :)
Все не так очевидно, слишком много заморочек с онлайн-ресайзом.
а он и шейпинг умеет делать? Или с 1,5 метровой фотки в 3кб — итак сойдет?
В «Высокую производительность» бы перенесли
заменить NFS им в голову не пришло
Вроде и магазин и аукцион, но какой приятный дизайн. По сравнению с танком еБэя — этот просто пёрышко.
Увидел маечку: www.etsy.com/listing/20910403/lets-ride-bikes-sleeveless-tunic-size-m?ref=cat1_gallery_18 Вроде женская, а рука потянулась нажать «Моё», «Дайте потрогать», «Да-да-да!»
Старый дизайн не видел, но новый хороший. Думаю не зря старались.
Есть мнение, что они могли бы сильно сэкономить время и деньги на 16 ядерных-серверах задействовав что-нибудь на базе CUDA или OpenCL. Ну и опять же даже без этого заменив NFS на iSCSI могли бы задёшево поиметь профит в скорости.
«заменив NFS на iSCSI… задешево» это как вы себе представляете????
Разработчикам дали задачу, а они побежали требования к инфраструктуре проекта менять??
Это оочень дорогое удовольствие и совсем не вариант в данном вопросе.
Меня больше интересует как вообще можно обеспечить высокую производительность NFS seek для подобной задачи, когда последовательность обхода файлов не важна? Чисто теоретически если обращаться к файлам в порядке их физического хранения, то производительность бы существенно выросла.
Разработчикам дали задачу, а они побежали требования к инфраструктуре проекта менять??
Это оочень дорогое удовольствие и совсем не вариант в данном вопросе.
Меня больше интересует как вообще можно обеспечить высокую производительность NFS seek для подобной задачи, когда последовательность обхода файлов не важна? Чисто теоретически если обращаться к файлам в порядке их физического хранения, то производительность бы существенно выросла.
Они сделали на том, что они знали. СИльно сомневаюсь, что у них было время изучать CUDA/OpenCL
Ради шутки они прикинули, сколько займёт эта работа вручную в «Фотошопе». Если на каждую фотографию отдать по 40 секунд, то выходит 170 лет непрерывного труда.
А про пакетную обработку и вычисления средствами видюхи они не слышали? Сравнивают ужа с ежом, к чему тут было приведено ручное масштабирование если из покон веков есть пакетная обработка, а в новых версиях уже и OpenGL прикрутили для простейших операций. JPEG сжатие/распаковку по всей видимости всё равно нужно процом рулить, но вот аппаратное масштабирование — нативная функция любой видеокарты.
А почему 40 секунд на одну картинку в фотошопе? Почему так много? Фотошоп к тому же батчит неплохо.
180 * 1,5 = 270 Мб/с была скорость чтения картинок в течение 9 суток. Это не поражает воображение, обычный сильный домашний комп, напр., с какой-нибудь CUDA для аппаратного жмаканья.
Я не понял, если у них скорость обработки фотографий фактически равна скорости чтения этих фотографий из NFS, то зачем все эти описания мутков с перлами и GraphicMagick'ами? Ну придумали как быстро считать-записать, жмаканье-то не проблема сейчас.
Мало что понял, мутная статья.
180 * 1,5 = 270 Мб/с была скорость чтения картинок в течение 9 суток. Это не поражает воображение, обычный сильный домашний комп, напр., с какой-нибудь CUDA для аппаратного жмаканья.
Я не понял, если у них скорость обработки фотографий фактически равна скорости чтения этих фотографий из NFS, то зачем все эти описания мутков с перлами и GraphicMagick'ами? Ну придумали как быстро считать-записать, жмаканье-то не проблема сейчас.
Мало что понял, мутная статья.
В кои веки Alizar запостил что-то по-настоящему близкое к ИТ-тематике :)
Странный подход, если честно.
Почему бы не применить генерацию превьюшек на лету, по мере их необходимости?
Впрочем об этом тут и без меня уже написали.
Почему бы не применить генерацию превьюшек на лету, по мере их необходимости?
Впрочем об этом тут и без меня уже написали.
> Почему бы не применить генерацию превьюшек на лету, по мере их необходимости?
Даже если не учитывать обычный траффик, первый приход гугл бота и сервер в дауне.
Даже если не учитывать обычный траффик, первый приход гугл бота и сервер в дауне.
Да перестаньте. При такой инфраструктуре, я думаю, проблема с поисковыми ботами давно решена.
Так генерируйте и складывайте. Отдайте эти 16 ядер на генерацию превьюшек на лету и скалывание куда-надо на первые дни (неделю). Результат тот же, но генерируется только то, что нужно, а не все подряд. У них наверняка есть «просроченные» картинки
UFO just landed and posted this here
500-1800 фоток на лету за секунду? 4-мя 16-ти ядерными серваками?
Говно вопрос.
Говно вопрос.
UFO just landed and posted this here
>правильно они сделали с точки зрения доверия пользователей
Это объясняет остановку проекта на 9 дней.
А потом еще, при следующем редизайне.
Это объясняет остановку проекта на 9 дней.
А потом еще, при следующем редизайне.
UFO just landed and posted this here
Обойдусь без копипаста.
habrahabr.ru/blogs/webdev/99108/?reply_to=3057636#comment_3057641
habrahabr.ru/blogs/webdev/99108/?reply_to=3057636#comment_3057641
я бы перекодировал при запросе нужные картинки… вряд ли у них все 100500 картинок одновременно грузят…
Не так давно была похожая задача, для сайта агентства недвижимости в NY (представляете сколько там фотографий). Мы пошли по другому пути. При попытке загрузить фото, мы проверяем если уже готовое превью, если нет, то загружаем с сервера мультилистига, создаем превью и показываем его; если есть то показываем то, что есть. Тем самым при первом просмотре фото это занимает немного дольше, но дальше все очень шустро. Тем более что изначально при детальном просмотре показывается одно фото, а остальные мы подготавливаем в фоновом режиме (выходит почти незаметно для конечного пользователя) и ежевременно прогоняем все новые записи на наличие фото и необходимость удалить старые файлы. При создании было хлопотно, но в итоге все работает на ура без необходимости «насиловать» 16 ядер :)
Вы ресайзите постепенно, а вот как наберется 135 млн картинок и вы перключитесь на другое разрешение ваш сайт будет лежать ~9 дней.
Так результат то тот же самый, так же резайтится картинки только 1 раз, но только то, что нужно. Отрезайзили и положили куда нужно. Те же самые 16 ядер, но «просроченные картинки» ресайзится не будут. Вы уверены, что каждая из 135 млн картинок показывается раз в 9 дней? Или там несколько миллионов актуальных, а остальные время от времени и большая часть вообще уже не показывается.
Результат в теории будет тот же самый, но на практике в самом начале пик. И из-за этого пика ни одна картинка не отресайзится вообще (просто не хватит памяти) так что пик будет до тех пор пока кто-то не зарежет трафик.
Аналогичную проблему решали + просто отсеивали картинки, которые уже в принципе не используются долго.
Без проблем, за пару месяцев, 500 тыс картинок, реально осталось не более 40 тыс, нагрузка минимальная, так как смотрят только «популярные», архивные 3-х годичной давности так до сих пор никому и не нужны.
Без проблем, за пару месяцев, 500 тыс картинок, реально осталось не более 40 тыс, нагрузка минимальная, так как смотрят только «популярные», архивные 3-х годичной давности так до сих пор никому и не нужны.
Что-то я не понял зачем им GraphicsMagick, ведь сказано «это форк ImageMagick, который обеспечивает лучшую производительность благодаря поддержке многопроцессорной обработки.» а в итоге оказалось что тредов нужно максимум 2. Тестов для одного треда нету, но уверен, что результат был бы еще лучше, ведь зачем параллелить ресайзинг одной картинки, это только даст тормоза на операции разрезания и склеивания.
Более того, насколько я понимаю, ImageMagick тоже поддерживает многопроцессорную обработку. GraphicsMagick в среднем немного быстрее, это да, но форкнулся он из-за разногласий разработчиков на обработку параметров командной строки: GraphicsMagick более консервативен, а в ImageMagick постоянно что-то изобретают.
Нехуево так дизайнеры промахнулись. «Да лан вам, 135 млн картинок отресайзить, за-то красиво!» Я бы, все же, сделал бы шаблон под старые превью, если уж такая пьянка :)
Занимался подобным совсем недавно.
Достиг 90-300 обработок в секунду, да еще с проходом pngcrush на одном i7
Суть проста — одну картинку обрабатывает один тред.
Всего 12 тредов на 8 «ядер»( 4 физических )
Еще один тред на них подает данные и снимает эти данные обратно.
Это САМЫЙ главный тред — балансирошик и префетчер доступа к диску.
и он один по любому
(кстати был сделан через nginx+AIO)
Достиг 90-300 обработок в секунду, да еще с проходом pngcrush на одном i7
Суть проста — одну картинку обрабатывает один тред.
Всего 12 тредов на 8 «ядер»( 4 физических )
Еще один тред на них подает данные и снимает эти данные обратно.
Это САМЫЙ главный тред — балансирошик и префетчер доступа к диску.
и он один по любому
(кстати был сделан через nginx+AIO)
sysoev.ru/nginx/docs/http/ngx_http_image_filter_module.html
Не в качестве рекламы, а так, как защита от тупого перекладывания картинок из одного размера в другой.
Не в качестве рекламы, а так, как защита от тупого перекладывания картинок из одного размера в другой.
на аукционе же контент меняется.
почему было просто _заранее_ не поставить в генерилке превюшек генерацию дополнительного размера под новый дизайн, а пока заканчивают дизайн и верстку — все старые лоты заменятся новыми с уже готовыми превьюшками.
почему было просто _заранее_ не поставить в генерилке превюшек генерацию дополнительного размера под новый дизайн, а пока заканчивают дизайн и верстку — все старые лоты заменятся новыми с уже готовыми превьюшками.
Потрясающе! Правда впечатляет.
Но мне момент один не ясен. Зачем параллелить обработку одного изображения? Не лучше ли каждому из 16 ядер вручить по отдельной картинке? Ведь тогда *полностью* исчезнет overhead на синхронизацию, который был ярко продемонстрирован при распараллеливании одной картинки на все ядра.
Да, авторы говорят:
Но в сводной таблице я не вижу колонки Threads=1 вообще.
Где подвох?
Но мне момент один не ясен. Зачем параллелить обработку одного изображения? Не лучше ли каждому из 16 ядер вручить по отдельной картинке? Ведь тогда *полностью* исчезнет overhead на синхронизацию, который был ярко продемонстрирован при распараллеливании одной картинки на все ядра.
Да, авторы говорят:
Оказалось, что самая высокая производительность достигается при использовании двух процессорных ядер на задачу
Но в сводной таблице я не вижу колонки Threads=1 вообще.
Где подвох?
Что характерно — если внимательно прочитать оригинал, то вопрос исследования других вариантов очень мило зажеван — типа, чтобы отвязались. Сравнения проводились с заведомо нежизнеспособными вариантами. Например, это пример с Фотошопом — «если бы я наскилялся, я бы делал ресайз за 35 секунд». Почему-то факт наличия пакетной обработки был опущен.
Или загрузка в облако — интересно, а почему они не посчитали, сколько по времени будет идти загрузка изображений туда и выгрузка результатов обратно?
Другими словами, мне описанное в топике решение не кажется ни интересным, ни эффективным — типичное решение задачи «в лоб».
— Как заресайзить кучу изображений?
— Пакетно
— А изображений очень много.
— Тогда утилитой из командной строки.
— Какой?
— www.google.ru/search?q=fast+image+processing+command+line+utility — первая ссылка. Есть тулза — ImageMagick называется
— А она самая быстрая?
— www.google.ru/search?q=imagemagick+speed+comparison — первая ссылка… Ээээ, нет, GraphicsMagick вроде бы быстрее
— Хорошо, тестируйте. Как предварительные результаты?
— 15 изображений в секунду, 104 дня работы.
— Это много.
— А если на 16-ядерном сервере запустить?
— Ну, после настройки — примерно 45 в секунду, 34 дня работы
— Много
— Тогда два сервера. 90 в секунду, 17 дней работы
— Много
— Тогда три сервера. 135 в секунду, 11 дней работы
— Много
— Тогда четыре сервера. 180 в секунду, 8 дней работы
— Ну, это другое дело. Запускайте.
Или загрузка в облако — интересно, а почему они не посчитали, сколько по времени будет идти загрузка изображений туда и выгрузка результатов обратно?
Другими словами, мне описанное в топике решение не кажется ни интересным, ни эффективным — типичное решение задачи «в лоб».
— Как заресайзить кучу изображений?
— Пакетно
— А изображений очень много.
— Тогда утилитой из командной строки.
— Какой?
— www.google.ru/search?q=fast+image+processing+command+line+utility — первая ссылка. Есть тулза — ImageMagick называется
— А она самая быстрая?
— www.google.ru/search?q=imagemagick+speed+comparison — первая ссылка… Ээээ, нет, GraphicsMagick вроде бы быстрее
— Хорошо, тестируйте. Как предварительные результаты?
— 15 изображений в секунду, 104 дня работы.
— Это много.
— А если на 16-ядерном сервере запустить?
— Ну, после настройки — примерно 45 в секунду, 34 дня работы
— Много
— Тогда два сервера. 90 в секунду, 17 дней работы
— Много
— Тогда три сервера. 135 в секунду, 11 дней работы
— Много
— Тогда четыре сервера. 180 в секунду, 8 дней работы
— Ну, это другое дело. Запускайте.
"""
В процессе тестирования было обнаружено, что ресайзинг предварительно уменьшенного изображения обеспечивает лучшее качество и более высокую скорость, чем ресайзинг непосредственно полноразмерного оригинала.
"""
призываю К.О.
В процессе тестирования было обнаружено, что ресайзинг предварительно уменьшенного изображения обеспечивает лучшее качество и более высокую скорость, чем ресайзинг непосредственно полноразмерного оригинала.
"""
призываю К.О.
проще и дешевле было бы все-таки подогнать дизайн. но, что сделано, то сделано.
А зачем им 135млн фото сразу??? Подозреваю, что это долгий архив и за один день скачивают максимум 1млн фоток. Ну максимум 10млн.
Я, прежде чем ресайзить 135млн, посмотрел бы в сторону ресайза по требованию. Т.е. ресайзить фотку в момент показа. что-то типа:
< img src="< ?= getResized($oldSrc, $newSrc, 170, 135);? >" / >
При этом для запуска нового дизайна, потребовалось бы предварительно отконвертить только 1млн — 10млн самых свежих фоток (те которые точно понадобятся в первый день), а все остальные генерить по требованию + в паралельном режиме, пока новый дизайн уже крутится не спеша обрабатывать оставшиеся 130млн.
Я, прежде чем ресайзить 135млн, посмотрел бы в сторону ресайза по требованию. Т.е. ресайзить фотку в момент показа. что-то типа:
< img src="< ?= getResized($oldSrc, $newSrc, 170, 135);? >" / >
При этом для запуска нового дизайна, потребовалось бы предварительно отконвертить только 1млн — 10млн самых свежих фоток (те которые точно понадобятся в первый день), а все остальные генерить по требованию + в паралельном режиме, пока новый дизайн уже крутится не спеша обрабатывать оставшиеся 130млн.
Потому что это проще чем:
1) Выяснять, какие фотки понадобяться в первый день
2) Лесть во вьювы и там мусорить с временной правкой, которая в итоге станет не нужна
3) По ночам думать об оверлоаде и цене, которую выставит площадка
4) По ночам ловить все ботсети купленные конкурентами для планомерного запроса всех картинок (это проще и быстрее ресайза)
5) Чувствовать себя идиотом, и не знать почему.
В общем, перефразируя поговорку: эти ребята не настолько богаты, чтобы покупать дешевые решения.
1) Выяснять, какие фотки понадобяться в первый день
2) Лесть во вьювы и там мусорить с временной правкой, которая в итоге станет не нужна
3) По ночам думать об оверлоаде и цене, которую выставит площадка
4) По ночам ловить все ботсети купленные конкурентами для планомерного запроса всех картинок (это проще и быстрее ресайза)
5) Чувствовать себя идиотом, и не знать почему.
В общем, перефразируя поговорку: эти ребята не настолько богаты, чтобы покупать дешевые решения.
Ммм… Можно было-бы не всё сразу, а по мере необходимости:
На каталог с новыми превьюшками ставим обработку 404 ошибки.
Если превьюшка уже есть — показывает на автомате, если нет — в обработчике 404 ошибки вызывает процедуру ресайзинга для нужной картинки, сохраняет куда надо, после чего возвращает пользователю вместо 404 страницы файл с превьюшкой…
В итоге по мере работы — на автомате перекодировало-бы все картинки…
На каталог с новыми превьюшками ставим обработку 404 ошибки.
Если превьюшка уже есть — показывает на автомате, если нет — в обработчике 404 ошибки вызывает процедуру ресайзинга для нужной картинки, сохраняет куда надо, после чего возвращает пользователю вместо 404 страницы файл с превьюшкой…
В итоге по мере работы — на автомате перекодировало-бы все картинки…
Вообще по-моему довольно таки бесполезно вообще было пробовать использовать несколько ядер при пакетной обабоке изображений, так как можно просто отдельные изображения обрабатывать параллельно.
В талбице почему-то нет варианта с 1-м потоком, чето я подозреваю что по той причине что надо было вообще оправдать всю возню.
В талбице почему-то нет варианта с 1-м потоком, чето я подозреваю что по той причине что надо было вообще оправдать всю возню.
Алёши. Я бы эту задачу решил намного быстрее… написал бы swf'ку которая качает изображения, ресайзит, и шлет обратно. Для приема/передачи изображений поставил бы nginx, и простенький PHP-скрипт работающий с mongodb для разделения задач по клиентам и учета выполнения.
Упёрся бы в канал :-) При условии что на страницы с swf'кой поступало бы достаточно много запросов.
Тем более что для юзера всё картинки сразу показываются в обработанном виде, просто необработанные грузятся дольше в первый раз.
Упёрся бы в канал :-) При условии что на страницы с swf'кой поступало бы достаточно много запросов.
Тем более что для юзера всё картинки сразу показываются в обработанном виде, просто необработанные грузятся дольше в первый раз.
Я так и не понял для чего конвертацию одной картинки распаралелили на 16 потоков? Можно 16 картинок одновременно обрабатывать.
>>Ради шутки они прикинули, сколько займёт эта работа вручную в «Фотошопе». Если на каждую фотографию отдать по 40 секунд, то выходит 170 лет непрерывного труда.
Про Actions они конечно нечего не знают.
Про Actions они конечно нечего не знают.
Sign up to leave a comment.
Ресайзинг изображений со скоростью 180 штук в секунду