IHttpHandler или IHttpAsyncHandler для сервера изображений

Моя задача - разработать сервер изображений, который:

  • загружать изображения с диска
  • изменить его размер в соответствии с параметром HTTP
  • применить один или несколько водяных знаков к исходному изображению

Вопрос в том, какую технологию я должен использовать, я собираюсь сделать это с IHttpHandler, но мне интересно, будет ли использование IHttpAsyncHandler быстрее для этого сценария?

Могу ли я получить выгоду от асинхронной обработки изображений в IHttpHandler?

Также, возможно, мне следует рассмотреть некоторую структуру высокого уровня, например. NancyFx или просто вернуть изображения с контроллера (MVC2)?


image c# asp.net-mvc ihttphandler ihttpasynchandler
person Alex Sikilinda    schedule 18.05.2015    source источник
comment
Я бы подумал об использовании imageresizing.net - переработка этого, вероятно, будет стоить вам или вашему работодателю во много раз больше стоимости лицензирования. . Изменить размер изображения на лету сложно.   -  person Robert McKee    schedule 18.05.2015
comment
Планируете ли вы обрабатывать их во время выполнения? В зависимости от размера это может занять некоторое время.   -  person brduca    schedule 18.05.2015
comment
@Brduca, да, план состоит в том, чтобы изменять размер на лету. Я знаю, что могу изменить их размер один раз, а затем использовать существующие, но я обязан изменить размер во время выполнения.   -  person Alex Sikilinda    schedule 18.05.2015
comment
Как хорошо сказал @RobertMcKee, это сложно сделать должным образом. В любом случае вы можете изменить их размер и сохранить в кеше для использования позже. Делать это каждый раз, когда вам нужно, - не лучший подход. И, как я уже сказал, в зависимости от базового изображения это может занять некоторое время. Подумайте также о предварительной обработке и кешировании.   -  person brduca    schedule 18.05.2015
comment
@Brduca он кэшируется фактически, поэтому каждый размер будет обрабатываться только один раз, поэтому это не моя главная забота.   -  person Alex Sikilinda    schedule 18.05.2015
comment
Я не вижу преимуществ в использовании асинхронного режима, вся ваша работа зависит от завершения предыдущего шага (никакие задачи не могут выполняться параллельно), кроме того, создание задачи всегда связано с накладными расходами. Это действительно может замедлить ваш запрос. Одним из преимуществ этого изменения размера является его небезопасное использование (с указателями). gutgames.com/post/   -  person brduca    schedule 18.05.2015

Ответы (2)


arrow_upward
0
arrow_downward

Асинхронный ввод-вывод никоим образом не ускоряет ввод-вывод. Он разблокирует поток во время выполнения этого ввода-вывода. На всю выполняемую работу ЦП это никак не влияет.

В некоторых случаях рекомендуется использовать асинхронный ввод-вывод для разблокировки потоков, в других - это пустая трата времени разработки без пользы для клиентов. вообще. Ожидаете ли вы, что большое количество одновременных загрузок изображений (например, 100 (одновременно!))? Тогда асинхронный ввод-вывод может быть полезным.

Наверное, не стоит использовать IHttpHandler ни для чего. Используйте MVC.

person usr    schedule 18.05.2015
comment
Проголосовали против, потому что IF вы должны реализовать это самостоятельно, MVC определенно НЕ подходит для этого. IHttpHandler был бы намного лучшим подходом. HttpModule подойдет лучше всего. - person Robert McKee; 18.05.2015
comment
@RobertMcKee, ты можешь уточнить? Мне не известны какие-либо сильные стороны, которые поддерживали бы ваш аргумент. Особенно тот факт, что вы, кажется, думаете, что HttpModule (намного) лучше, кажется необоснованным. - person usr; 18.05.2015
comment
Конечно. MVC - отличный фреймворк для доставки веб-страниц, поскольку он избавляет от большого количества рутинной работы, связанной с такими вещами, как многопоточность и состояние сеанса, обеспечивая принудительное выполнение нескольких запросов, которые все используют сеанс через один поток (или выполняют их. по одному), поиск и десериализация параметров из нескольких мест (URL, сообщение формы, файлы cookie и т. д.). Однако каждый из них имеет свою цену. Изображения получают во много раз больше запросов, чем веб-страница, и эти накладные расходы быстро накапливаются. - person Robert McKee; 18.05.2015
comment
Что касается HttpModule vs HttpHandler, есть много причин, одна из которых - производительность. HttpModules также может легко просматривать все входящие запросы, в то время как HttpHandlers не так много без переписывания, перехвата и некоторых хакерских вещей. MVC построен на основе ASP.NET, поэтому при одинаковом коде решение MVC (даже самое оптимальное, которое большинство людей упускает из виду) всегда будет работать намного хуже, чем HttpModule. Большинство веб-сайтов имеют значительно больше обращений к изображениям, и эти запросы значительно больше, это единственный самый важный фактор для возможности хорошего масштабирования. - person Robert McKee; 18.05.2015
comment
Накладные расходы MVC для нулевого запроса почти ничего. Примерно 5 тыс. Запросов в секунду на ядро ​​ЦП. Большинство упомянутых вами функций являются необязательными и не используются здесь. Затраты на MVC постоянны и не пропорциональны объему отправляемых вами данных. Я не следую мышлению HttpModule относительно производительности. Как я уже сказал, затраты на инфраструктуру близки к нулю, о чем свидетельствует измеренное мной количество запросов на ядро ​​в 5 тысяч. - person usr; 18.05.2015
comment
5 тыс. Запросов на ядро ​​ЦП были бы для меня непростой задачей. Наш сайт должен иметь возможность обрабатывать 12,5 тыс. Запросов на ядро ​​в секунду ПОЛЕЗНЫХ запросов (исходя из текущего пикового использования). - person Robert McKee; 18.05.2015
comment
Если это так, то вы правы. Ваш совет не распространяется на 99,999% сценариев развития. В этих случаях неиспользование MVC является пустой тратой времени разработчиков, поскольку приводит к затратам времени без какой-либо выгоды для клиента. Увидев ваш ответ только что, хочу сообщить, что я не голосовал против него. - person usr; 18.05.2015
comment
В 99,999% сценариев разработки неиспользование предварительно созданной библиотеки, которая делает именно то, что вы хотите, является пустой тратой ресурсов разработки, поэтому я дал ответ, который я сделал выше. Просто используйте его и переходите к следующей проблеме. - person Robert McKee; 19.05.2015

arrow_upward
-1
arrow_downward

Я бы подумал об использовании http://imageresizing.net - его перепланировка, вероятно, будет стоить вам или вашему работодателю во много раз больше затрат на лицензирование. Изменить размер изображения на лету сложно. Исходя из того, что вы описываете для своих нужд, я считаю, что лицензия будет даже бесплатной. Только если / когда вы выйдете за рамки своих простых потребностей, вам нужно будет перейти на платную лицензию.

Если вы решите попробовать свои собственные, я предлагаю сначала прочитать это: http://www.nathanaeljones.com/blog/2009/20-image-resizing-pitfalls, в котором будут указаны некоторые подводные камни, которых следует избегать.

person Robert McKee    schedule 18.05.2015