Работа с графикой

[still swamp]

Как вам такой подход к графическому оформлению?

На сервер заливается графика с высоким разрешением. А далее с помощью урла происходит модификация на лету. Пользователь получает уже готовый имидж требуемого размера, цвета и так далее.

Пример тут: http://catlair.net/?&Body=Body&pag...mp;UIDNews=1341

Edited October 19, 2010 by still swamp

[Great Rash]

Технология не понятна, а вот грузится сайт достаточно долго. И как бы работы обсуждаются в другом разделе.

[still swamp]

Сожалею, в другом разделе у мя нет прав создавать топики, так как 30 мессаг ограничение. Что до скорости загрузки, отладчик стоял. Ща остановили.

На счет непонятности:

http://catlair.net/imagel.asp?GUID=6E64C8A...08-83F312B74811 - оригинальное изображение

http://catlair.net/imagel.asp?GUID=6E64C8A...mp - изображение отскалированное до 16x16.

http://catlair.net/imagel.asp?GUID=6E64C8A...mp;mul=80FFFFFF - изображение отскалированное до 64x64 c прозрачностью.

Edited October 19, 2010 by still swamp

[SelenIT]

Админу CMSки, может, оно и удобнее (при условии, что ему не надо думать, куда тыкать какой вариант, всё прошито в настройках соотв. модуля). А для клиента никакого преимущества перед традиционной системой с разными файлами нет — всё равно для каждой картинки отдельный запрос к серверу и т.п. Плюс малопонятные нечеловекочитаемые урлы, из которых не получить никакой полезной инфы поисковикам, а также невозможность хотлинка таких картинок на некоторых форумах, разрешающих только статические урлы (не знаю, минус это или плюс... как по мне — минус. Сама ресайзилка/кропалка работает, вроде, достаточно симпатично. Но в чем принципиальная новизна? В урезанном HTTP-интерфейсе к консольному граф. редактору?

[still swamp]

Хм... а я ничего ничего про новизну не писал, более того даже не претендую. Меня лично просто задрало под разные разрешения клепать одну и ту же графику.Появилось вот такое изделие. Решил поделиться, за одно и на шустрость проверить.

Для нерезионовых сайтов под разное разрешение - очень даже весело пойдет.

На кнопках enable disable - удобно. Не надо мозг ломать, и дизайнеров тревожить.

Edited October 19, 2010 by still swamp

[SelenIT]

Если сами дизайнеры с результатом такого обращения с их творчеством согласны — то всё отлично . Единственное, я бы подумал над "псевдостатичностью" и человекопонятностью урлов — имхо, ограничений будет меньше...

[Veseloff]

Как вам такой подход к графическому оформлению?

Плохо. Чуть-чуть нагрузки и хана серверу.

[still swamp]

Плохо. Чуть-чуть нагрузки и хана серверу.

Ну зря вы так не дочитавши...

Готовые изображения кэшируются и при последующем запросе отдаются уж не медленнее чем просто лежащий отдельно имидж.

Edited October 19, 2010 by still swamp

[stars]

Как вам такой подход к графическому оформлению?

Честно говоря не вижу задачи требующей такова подхода, разве что какая то галерея которая требует включать в себя картинки высокого разрешения, и из них делать привьюшки...

Просто вот допустим лого сайта так делать бессмысленно, использовать в и-нэт магазине для превью картинок это загубить сервер нафиг(если даже не загубить то бессмысленная трата ресурсов сервера)...

Как мне видится это неплохая идея для автоматического создания превью картинок тубишь ты загрузил большую картинку, ввел в форму адрес картинки, и у тебя автоматом получается превью которая сохраняется куда-то на сервер... Все круто только такие картинки будут не оптимизированы...

В общем сама идея ясна, реализация тоже угадываемо, я бы такой getimg.php сделал бы использую GD2

[still swamp]

Если сами дизайнеры с результатом такого обращения с их творчеством согласны — то всё отлично . Единственное, я бы подумал над "псевдостатичностью" и человекопонятностью урлов — имхо, ограничений будет меньше...

Дизайнеры - по моему опыту - люди с крайне тонкой и нежной психикой, до которой клиенту дела в общем то нет. А платит клиент....

Что касается псевдостатичности - идея отменная. Сделаем так. Можно отправить урл, а в ответ вернется GUID на изображение в кэше. Те хвоста из параметров не будет. И все станет прямо весело. Спасибо.

Как мне видится это неплохая идея для автоматического создания превью картинок тубишь ты загрузил большую картинку, ввел в форму адрес картинки, и у тебя автоматом получается превью которая сохраняется куда-то на сервер... Все круто только такие картинки будут не оптимизированы...

В общем сама идея ясна, реализация тоже угадываемо, я бы такой getimg.php сделал бы использую GD2

Ну да... и превью тоже. Только почему же не будут... будут. Только не сразу. Постеризация, глубина цвета, методы паковки - в ближайших планах.

А что касается реализации, то боже упаси php - столько труда и такое расточительство. SQL - для сих задач и проще и изящнее.

Edited October 19, 2010 by still swamp

[CEBEP]

не понравилась идея(серверу хана) но в закромах должна лежать

[still swamp]

не понравилась идея(серверу хана) но в закромах должна лежать

А аргументируйте? Почему хана, я с удовольствием залатаю, подпачу.

[stars]

SQL... ммм хорошо, а можно подробней как именно хранится картинка?

Edited October 19, 2010 by stars

[Veseloff]

А аргументируйте? Почему хана, я с удовольствием залатаю, подпачу.

Ну я так понимаю, что в любом случае картинка отдаётся при помощи скрипта? Так? Если так, то точно хана. Люди статику просто через апач-то не отдают, оставляя её нжинксу, а тут ещё и скрипт сверху наваливается. Сервер такого не прощает.

[still swamp]

SQL... ммм хорошо, а можно подробней как именно хранится картинка?

Картинка изначально после загрузки хранится в базе SQL в виде бинарника. Оттуда же добывается по прямой ссылке.

http://lab.catlair.net/index.asp?UIDMenu=4...eListCollection

Ну я так понимаю, что в любом случае картинка отдаётся при помощи скрипта? Так? Если так, то точно хана. Люди статику просто через апач-то не отдают, оставляя её нжинксу, а тут ещё и скрипт сверху наваливается. Сервер такого не прощает.

При какой нагрузке наступит хана? Какую скорость вы считаете критичной: 10кб/сек, 100кб/сек, 1мб сек, 10мб сек? Все ведь зависит от денег и целесообразности. Потом опять таки, вы же отчетливо понимаете что можно сохранять кэш по ссылке на файловом уровне. А вот поиск (если говорить о равных задачах) поверьте я в SQL организую куда как быстрее.

Edited October 19, 2010 by still swamp

[Veseloff]

Ой. Спасибо, нет.

Ну вот реально давайте посмотрим на вещи. Сейчас мы имеем то, что имеем. Кроме кошмарной нагрузки (я в этом почти уверен) есть еще один момент — хранение кэша. В принципе, кэширование — это гуд, но вот я сейчас, например, ВНЕЗАПНО делаю последовательно 10 миллионов GET-запросов на картинки разного размера (то есть меняю scalex и scaley). У меня это много трафика не сжирает, всё проходит быстро и безболезненно, а у вас заполняется HDD по самое небалуйся. Ограничить кэш? Тогда пропадает 50% его ценности — возрастёт нагрузка. Ограничить размеры только некоторыми определённые значениями? Тогда пропадает ценность библиотеки как таковой. Короче, всё очень сомнительно. И, да, походу у вас всё на ASP? Тогда еще и не кроссплатформенно. Увы.

[still swamp]

Сделайте 10 миллионов GET запросов вот сюда http://forum.htmlbook.ru/uploads/av-5734.gif. Какой вы ожидаете результат? Ведь все зависит от времени.

Про HDD. Естно заглушка стоит на количество кэшреплик. Однако не забывайте, что тут ситуация как со шведским столом. Более чем влезет не сожрешь, а уносить с собой нельзя. Для хитрых стоит охрана. И все довольны. У всего есть предел и у всего есть цена. Если вы собираетесь достигать рекордных скоростей, то у меня задача обеспечить вал за счет удобства и масштабируемости. Если можно, давайте говорить о байтах в секунду, а не о 10 миллионах.

Про кросплатформеность. Скрипт на ASP состоит из 20 строк. Больше от ASP ничего не нужно. Остальное в SQL. К стати, кросплатформенность вебсерверов - это миф. У вебсервера нет задачи работать на всем и вся как у инди игрушки.

Edited October 19, 2010 by still swamp

[Veseloff]

Если можно, давайте говорить о байтах в секунду, а не о 10 миллионах.

А при чём здесь байты в секунду? Тут скорость не важна совершенно, важна нагрузка на сервер. Ну а если о том, что 10 миллионов запросов буду отсылаться долго, то на одном 100 Мб канале я их зашлю минут за 20-30.

Про кросплатформеность. Скрипт на ASP состоит из 20 строк. Больше от ASP ничего не нужно. Остальное в SQL. К стати, кросплатформенность вебсерверов - это миф. У вебсервера нет задачи работать на всем и вся как у инди игрушки.

1. Большинство хостеров работают под линуксами и прочими фряхами по понятным причинам

2. Большинство сайтов пишется на php, perl, python, ruby, mysql, postgresql по тем же причинам

Миф мифом, а о заказчиках надо думать — не все настолько богаты, что могут себе позволить такие непомерные траты.

Вывод. Идея не нова, но хороша. Реализация есть и, я думаю, тоже весьма хороша. К сожалению, для большинства проектов неприменима. А жаль.

[still swamp]

А при чём здесь байты в секунду? Тут скорость не важна совершенно, важна нагрузка на сервер. Ну а если о том, что 10 миллионов запросов буду отсылаться долго, то на одном 100 Мб канале я их зашлю минут за 20-30.

1. Большинство хостеров работают под линуксами и прочими фряхами по понятным причинам

2. Большинство сайтов пишется на php, perl, python, ruby, mysql, postgresql по тем же причинам

Миф мифом, а о заказчиках надо думать — не все настолько богаты, что могут себе позволить такие непомерные траты.

Вывод. Идея не нова, но хороша. Реализация есть и, я думаю, тоже весьма хороша. К сожалению, для большинства проектов неприменима. А жаль.

Скажите, какая вам разница что происходит с сервером, если он выдает байты в секунду. Да никакой. Стоит он себе там трясется. В темноте. Каверзу я ему задумал на завтра. А тут вы еще навострили 10млн. Зачем вам такой запрос? В том то и дело что он бессмысленный, но требует ресурсов, а потому вы и делать его не станете. Я же буду только рад, если вы отправите эти запросы. Только что-бы совсем не выглядеть упырями по отношению к серверу, я бы очень хотел присутствовать для оказания посильной реанимации.

1. Нет у меня такой статистики. Все хостеры с которыми я общался предоставляют не линуксы и фряхи, а услуги... например удаленое размещение 1С, или веб склад, или не дай бог биллинг, те не то что интересно технарю, а то что требуется клиенту.

2. Что касается трат, то сайт на catlair сугубо бесплатен. За остальных говорить не буду.

Edited October 19, 2010 by still swamp

[stars]

Картинка изначально после загрузки хранится в базе SQL в виде бинарника. Оттуда же добывается по прямой ссылке.

А ну замечательно, вот интересно было бы проверить как поведет себя такой способ при изначально больших картинках и штук 10-15 запросов к таким картинкам

Хотя оракул вроде как творит чудеса, при больших объемах...

Edited October 19, 2010 by stars

[CEBEP]

переносить нагрузку с харда на проц - безумие! Хоть бы этот скрипт сам царь Саломон писал, концепт имеет смысл только в галерейках каких-нибудь которые залезают смотреть в основном по эскизам и эскизов этих нужно на страничку кинуть много. Если речь о маленьком хомячке то тут и говорить не о чем а если запускать круой ресурс то перегружать проц - последнее дело.

[CEBEP]

а кешировать тут вообще конечно надо но это не снимет основную нагрузку - в основном по одному разу просмотреть надо

[still swamp]

А ну замечательно, вот интересно было бы проверить как поведет себя такой способ при изначально больших картинках и штук 10-15 запросов к таким картинкам

Хотя оракул вроде как творит чудеса, при больших объемах...

А давайте проверим. Что значит большая картинка?

а кешировать тут вообще конечно надо но это не снимет основную нагрузку - в основном по одному разу просмотреть надо

Я понимаю разницу между реалтаймовой генерацией и хранением на HDD. Именно поэтому и появился кэш.

По моей статистике на одну генерацию приходится около двух тысяч чтений из кэша. Так что ...

Edited October 20, 2010 by still swamp

[Veseloff]

На самом деле сейчас всё (по крайней мере у меня) строится на догадках и предположениях, основанных на личном опыте. Хотелось бы увидеть цифр каких-нибудь. К примеру: «Железка такая-то. Исходное изображение такое-то. Проверять будем таким-то бенчмарком. Результаты теста на пережимание к такому-то размеру: с использованием кэша столько-то, без использования кэша столько-то. С другими параметрами такие-то результаты». А потом уже можно будет прикинуть сколько запросов в сутки на одну картинку выдержит сервер и насколько это всё рационально. Ну и можно будет, например, если хотите сделать такие же тесты на разных серверах как то: php5 gd на апаче, простая статика на нжинксе, прогон через imagemagick, ещё какие-нибудь извращения выдумаем... Тогда можно будет уже о чем-то говорить. Всё познаётся в сравнении.

[Veseloff]

UPD:

А вот и небольшие циферьки от апачбенча

1. Сайт, в котором я сейчас искореняю всякий мудизм. В том числе и обработу изображений «на лету». Сейчас они отдаются из php-скрипта при помощи GD. Это одно из них.

veseloff@veseloff-desktop:~$ ab -n 100 -c 10 http://mebel66.ru/icatalog/width/100/height/100/cropratio/1/1/modules/catalog/cache/good_images/narodmebel_10.jpg
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking mebel66.ru (be patient).....done


Server Software:		nginx
Server Hostname:		mebel66.ru
Server Port:			80

Document Path:		  /icatalog/width/100/height/100/cropratio/1/1/modules/catalog/cache/good_images/narodmebel_10.jpg
Document Length:		4029 bytes

Concurrency Level:	  10
Time taken for tests:   2.388 seconds
Complete requests:	  100
Failed requests:		0
Write errors:		   0
Total transferred:	  428000 bytes
HTML transferred:	   402900 bytes
Requests per second:	41.87 [#/sec] (mean)
Time per request:	   238.839 [ms] (mean)
Time per request:	   23.884 [ms] (mean, across all concurrent requests)
Transfer rate:		  175.00 [Kbytes/sec] received

Connection Times (ms)
			  min  mean[+/-sd] median   max
Connect:	   71   73   1.0	 72	  76
Processing:	81  147 245.4	 84	1187
Waiting:	   80  147 245.4	 84	1187
Total:		152  220 245.5	157	1259

Сайт располагается на обычном шаред-хостинге, так что говорить о том, что сервер хороший и быстрый не приходится.

2. А вот и одно из изображений с вашего сайта.

veseloff@veseloff-desktop:~$ ab -n 100 -c 10 http://catlair.net/imagel.asp?GUID=6E64C8AD-FD55-45C1-AF08-83F312B74811&scalex=64
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking catlair.net (be patient).....done


Server Software:		Microsoft-IIS/7.5
Server Hostname:		catlair.net
Server Port:			80

Document Path:		  /imagel.asp?GUID=6E64C8AD-FD55-45C1-AF08-83F312B74811
Document Length:		98285 bytes

Concurrency Level:	  10
Time taken for tests:   52.088 seconds
Complete requests:	  100
Failed requests:		0
Write errors:		   0
Total transferred:	  9921468 bytes
HTML transferred:	   9887532 bytes
Requests per second:	1.92 [#/sec] (mean)
Time per request:	   5208.840 [ms] (mean)
Time per request:	   520.884 [ms] (mean, across all concurrent requests)
Transfer rate:		  186.01 [Kbytes/sec] received

Connection Times (ms)
			  min  mean[+/-sd] median   max
Connect:	  389  469  88.4	439	 673
Processing:  2628 4536 1648.5   3864	9254
Waiting:	  452  614 232.5	578	2386
Total:	   3264 5005 1633.1   4336	9645

Такие дела...