Comments 19
А не проводили тесты по скорости отдачи просто статического файла и с ресайзом через Ваш модуль с кешированием и без?
Боюсь, что даже один пользователь, который в несколько потоков начнет запрашивать несколько картинок c разницей в размерах 1px, сможет, во-первых, «убить» кеш, а во-вторых, занять практически все процессорное время.
Думаю, что можно доработать и указывать модулю список допустимых разрешений.
Не вариант. Вы же не будете указывать список допустимых разрешений для каждой картинки? Простого ограничения на размер сверху тоже будет недостаточно.
Ну если для разных картинок размеры могут быть совершенно разными, то да, Вы правы. Но если брать, например, каталог продукции, то в большинстве случаев для всех картинок каталога список нужных размеров будет одинаков. Хотя в этом случае иногда проще сделать ресайз при загрузке, если конечно не планируется частое изменения размеров.
Вообщем, не панацея конечно, но в некоторых ситуациях модуль будет удобен для использования, имхо.
Вообщем, не панацея конечно, но в некоторых ситуациях модуль будет удобен для использования, имхо.
Это так. Но эта проблема относится не только к ресайзу картинок. Примеров тяжёлых серверных сценариев много.
Собственно бороться с флудом надо уже изученным способом — определять источник и банить.
Но в простейшем случае я бы действительно опделели готовый список профилей для ресайза на сайте да и всё.
Другое дело ресайз адаптивный (Picasa Web) — тут только бороться с флудом как таковым.
Собственно бороться с флудом надо уже изученным способом — определять источник и банить.
Но в простейшем случае я бы действительно опделели готовый список профилей для ресайза на сайте да и всё.
Другое дело ресайз адаптивный (Picasa Web) — тут только бороться с флудом как таковым.
Рекомендую взглянуть на проект imageresizing.net, имеет много различных опций и плагинов.
Сам пока не использовал, но как утверждает автор, библиотека используется на довольно крупных сайтах с хранилищем картинок 10Тб — 20Тб.
Пост Скотта Хансельмана об этом.
Сам пока не использовал, но как утверждает автор, библиотека используется на довольно крупных сайтах с хранилищем картинок 10Тб — 20Тб.
Пост Скотта Хансельмана об этом.
Замечательный проект.
Но настолько умный, что 20% overhead-а не отделаешься.
По ab у меня не получилось меньше 40%. Хотя, может сейчас что-то поменялось у них.
Но настолько умный, что 20% overhead-а не отделаешься.
По ab у меня не получилось меньше 40%. Хотя, может сейчас что-то поменялось у них.
Провел тесты — без использования кеширования оверхед состалял где-то 40-50% (делался ресайз, кроппинг с параметром scale=canvas); однако при использования кешируешего плагина (DiskCache) получаем практически самое время, что и без использовании данного проекта. Что есть очень хорошо, учитывая гибкость данного подхода.
Поделился опытом внедрения данного модуля.
Автор, если на вашем сайте больше 10 пользователей в день, то все печально.
У нас нагрузка была повыше (> 5000 показов в день), поэтому картинки предварительно резались и клались в CDN, в вашем случае можно просто на диск кидать.
У нас нагрузка была повыше (> 5000 показов в день), поэтому картинки предварительно резались и клались в CDN, в вашем случае можно просто на диск кидать.
UFO just landed and posted this here
Использование System.Drawing в asp.net-приложениях ведёт к утечкам памяти и иногда к падениям и зависаниям IIS. В MSDN об этом слегка упомянуто :)
Есть такое. По крайней мере в теории. Одновременно с этим imageresizer вроде как GDI+ использует и ничего.
Хотя вот тоже планирую переделать на WIC — побыстрее будет.
Хотя вот тоже планирую переделать на WIC — побыстрее будет.
После определённой нагрузки начинается и на практике :) Обычно с этим борются, вынося проблемный ресайзер в отдельный AppDomain и установку ему рестарта рабочего процесса каждые 5 минут :)
Однако я в своём опыте встречал даже падения всего IIS'а в native exception от использования System.Drawing.
Ну а на небольших нагрузках «всё пучком», т.к. ресурсы не успевают утечь достаточно сильно между перегрузками рабочего процесса.
Однако я в своём опыте встречал даже падения всего IIS'а в native exception от использования System.Drawing.
Ну а на небольших нагрузках «всё пучком», т.к. ресурсы не успевают утечь достаточно сильно между перегрузками рабочего процесса.
Чтобы заработало кеширование необходимо отдавать 304 статус на запросы с заголовками кеширования. В вашем случае надо либо в районе 82 или 104 строки вставить какой-то такой код:
string entityTag = Request.Headers["If-None-Match"];
DateTime lastModifiedDate = DateTime.TryParseExact(Request.Headers["If-Modified-Since"]
,"r"
,CultureInfo.InvariantCulture
,DateTimeStyles.None
,out lastModifiedDate)
? lastModifiedDate
: DateTime.MinValue;
if ((!String.IsNullOrEmpty(entityTag) && cacheName == entityTag)
|| DateTime.UtcNow.Subtract(lastModifiedDate).TotalDays < 1)
{
Response.StatusCode = 304;
Response.StatusDescription = "Not Modified";
Response.SuppressContent = true;
return;
}
PS: ну и да, если фреймворк > 2.0 лучше использовать WPF, неплохой пример для старта есть здесь.
Sign up to leave a comment.
IIS — изменяем размер картинок на лету