1

My task is to develop an Image server, that will:

  • load images from disk
  • resize it, according to HTTP parameter
  • apply one or more watermarks to the original image

The question is what technology should I use, I am going to do it with IHttpHandler, but I wonder if using IHttpAsyncHandler will be faster for this scenario?

Can I benefit from processing images asynchronously in IHttpHandler?

Also maybe I should consider some high level framework e.g. NancyFx or just return the images from controller (MVC2)?

Alex Sikilinda
  • 2,928
  • 18
  • 34
  • 1
    I would consider using http://imageresizing.net/ - Redeveloping this would likely cost you or your employer many times over the cost of licensing it. Doing image resizing on the fly is hard to do right. – Robert McKee May 18 '15 at 17:04
  • Are you planning on processing them on runtime? Depending on the size this can take a while. – brduca May 18 '15 at 17:04
  • @Brduca, yes the plan is to resize on the fly. I know I can resize them once and than use existing, but I am bound to rezise on runtime. – Alex Sikilinda May 18 '15 at 17:37
  • As @RobertMcKee well said, this is hard to be done properly. And anyway you can resize them and keep it on cache for use later. Do it every time you need is not the best approach. And as I said, depending on the base image this can take awhile. Consider pre processing it and caching too. – brduca May 18 '15 at 17:51
  • @Brduca it is cached acutally, so each size will be processed only once, so it is not my main concern. – Alex Sikilinda May 18 '15 at 17:53
  • 1
    I see no advantages in using it async, all the work you have do depends on the completion of the previous step (no tasks can be done in parallel), besides creating a task have always an overhead. This can actually make your request slower. One advantage on this resizes is using it unsafe (with pointers). http://www.gutgames.com/post/Using-Unsafe-Code-for-Faster-Image-Manipulation.aspx – brduca May 18 '15 at 18:05

2 Answers2

0

Asynchronous IO does not make IO faster in any way. It unblocks a thread while that IO runs. All CPU work that is being performed is not impacted at all.

In some cases it is a good idea to use async IO to unblock threads, in others it is a waste of dev time with no benefit to customers whatsoever. Do you expect a high number of concurrent image downloads (like 100 (at the same time!))? Then async IO can be of benefit.

Probably, you should not be using IHttpHandler for anything. Use MVC.

Community
  • 1
  • 1
usr
  • 168,620
  • 35
  • 240
  • 369
  • Downvoted because *IF* you have to implement this yourself, MVC is definitely NOT the way to go about it. IHttpHandler would be a much better approach. HttpModule would be best. – Robert McKee May 18 '15 at 17:09
  • @RobertMcKee can you elaborate? I'm not aware of any strong points that would support your argument. Especially the fact that you seem to think HttpModule is (far) superior seems unfounded. – usr May 18 '15 at 17:25
  • Sure. MVC is a great framework for delivering webpages, as it takes a lot of the grunt work away from having to do deal with things like threading and session state, making sure to force multiple requests that all uses session through a single thread (or execute them one at a time), looking and deserializing parameters from multiple places (URL, Form Post, Cookies, etc). However, each of those comes at a cost. Images get many many times the number of requests that a web page does, and that overhead adds up quick. – Robert McKee May 18 '15 at 18:12
  • As for HttpModule vs HttpHandler, there are many reasons, performance being one. HttpModules can also easily look at all incoming requests, while HttpHandlers not so much without a lot of rewriting, hooking, and some hacky stuff. MVC is built on top of ASP.NET so given the same code, the MVC solution (even the most optimal one -- which most people will miss a few things) will always perform much worse than the HttpModule. Most website have significantly more hits for images and those requests are significantly larger, it's the single biggest factor in being able to scale well. – Robert McKee May 18 '15 at 18:20
  • MVC overhead for a null request is next to nothing. Like 5k requests per second per CPU core. Most features that you mentioned are optional and do not come into play here. MVC costs are constant and not proportional to the amount of data you send. I do not follow the HttpModule thinking regarding performance. As I said the infrastructure costs are near zero as evidenced by the 5k requests/core number which I measured. – usr May 18 '15 at 18:21
  • 5k requests per CPU core would be a non-starter for me. Our site needs to be able to handle 12.5k requests per core per second of USEFUL requests (based on current peak usage). – Robert McKee May 18 '15 at 18:33
  • If that is the case then you have a point. Your advice does not apply to 99.999% of development scenarios. In those cases not using MVC is a waste of dev time because it results in time expenditure without any customer benefit whatsoever. Seeing your answer just now and want to let you know that I did not downvote it. – usr May 18 '15 at 18:37
  • In 99.999% of development scenarios, not using a pre-built library that does exactly what you want is a waste of development resources, which is why I gave the answer that I did above. Just use it, and move on to the next problem. – Robert McKee May 19 '15 at 15:40
-1

I would consider using http://imageresizing.net - Redeveloping this would likely cost you or your employer many times over the cost of licensing it. Doing image resizing on the fly is hard to do right. Based on what you describe for your needs, I believe the license would even be free. Only if/when you go beyond your simple needs would you need to upgrade to a pay license.

If you decide to try and roll your own, I suggest reading this first: http://www.nathanaeljones.com/blog/2009/20-image-resizing-pitfalls which will pinpoint some of the pitfalls to try and avoid.

Robert McKee
  • 21,305
  • 1
  • 43
  • 57