Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


This forum is in read only mode, you can no longer reply
  • Michael Nielsen 99 posts 619 karma points
    Mar 18, 2016 @ 12:30
    Michael Nielsen
    0

    Questions about performance

    I've been looking at the timings of images loaded with ImageProcessor, and I'm seeing some things that makes me wonder.

    On a site running

    Umbraco 7.4.0

    ImageProcessor 2.3.3.0

    ImageProcessor.Web 4.5.3.0

    We have an image that is 1920x761 and 161 Kb. Load that without any parameters, and it takes 70 ms.

    Put width=1920 as a parameter, and then it takes 685 ms.

    I'm guessing ImageProcessor needs some time to generate the image, but isn't over half a second excessive?

    All other requests to the same image will be with the cached image. However, when testing, then it does still seem somewhat slower than just loading the picture

    http://prntscr.com/agsgph

    ...

    On another site running

    Umbraco v. 7.4.1

    ImageProcessor 2.3.3.0

    ImageProcessor.Web 4.5.3.0

    We have a slider, where the images are all 1280x438 and around 150-300 Kb.

    They take between 200-400 ms to load, and that's even after ImageProcessor has initially generated the images.

    http://prntscr.com/agryfu

    Retry http://prntscr.com/agrzv0

    So I don't know if I have too high expectations to ImageProcessor, or if somethings wrong on our solutions.

  • James Jackson-South 488 posts 1738 karma points c-trib
    Mar 22, 2016 @ 08:59
    James Jackson-South
    1

    Hi Michael,

    I think it's important for you to understand the implications of the difference of behaviour you are requesting.

    In your first example you are adding no parameters.

    That means that ImageProcessor.Web (It's really important to get naming correct here. There are two libraries) doesn't actually load and manipulate the image in any way. It is merely passed off to the static file handler and loaded like any other static resource.

    As soon as you add a querystring multiple things happen.

    1. The correct source of the image has to be determined. Is it local, remote, from cloud storage, etc
    2. The query string is required to be parsed by all the IWebGraphicsProcessors to identify which one should process the request. (Protip: You can speed things up by disabling unused individual IWebGraphicsProcesor instances by installing the config package and removing them from processing.config).
    3. The image is then loaded and decoded by ImageProcessor (ImageFactory class if you want to take a look) and its file type is determined.
    4. Since there is only one parameter given, ImageProcessor now has to calculate the other dimension. If both dimensions match the original, the original image is returned, otherwise the image is resized.
    5. The image is then encoded by the correct encoder, and cached to whatever caching mechanism you are using (usually the disk cache) and the request is rerouted.
    6. The response headers are then manipulated to ensure that the image is cached in the browser.

    Does all that make sense to you?

    Now I'm sure there are places I could improve performance (remove legacy code, locking) in that mechanism but since I am not actively working on the library (I'm working on ImageProcessor Core now), and community involvement isn't as high as I'd hope it would be, I am not able to spend the time to properly do so.

    In you second example there is either something terribly wrong with your setup, you have performed a refresh, or you have disabled caching in your browser tools. The browser will return a 304 for subsequent image requests once cached and not make the request to the server for the image. Those times should be either 0 or 1ms.

    I notice you are using slimmage for your image requests. I would recommend you use the picture element or image with sourceset and let the browser handle making the requests for you. (There are polyfills available if you require them).

    What are the specifications of your server? I get much faster load time (~200ms) for an image matching the first dimensions than that on my laptop. Intel M-5Y70 Processor @ 1.10GHz 1.30GHz with 8GB ram

    Cheers

    James

  • Michael Nielsen 99 posts 619 karma points
    Apr 28, 2016 @ 10:25
    Michael Nielsen
    0

    Hi James

    Sorry for taking so long to respond to this.

    And thanks for your detailed answer, and it absolutely maskes sense.

    My comment about having too high expectations for ImageProcessor (or ImageProcessor.Web), was not to imply that it's shit, or anything like that, so I hope you did not take offence. If so I'll make it up to you with a beer @Codegarden if you're going again this year. :-)

    We very much like ImageProcessor, and when pushing other platforms we work on to implement something similar, we always refer them to it.

    But back to our issue.

    Yes I've disabled the cache via the developer panel in Chrome as I want to get the same experience as first time visitors will see.

    And yes we use Slimmage to serve responsive images.

    Our server looks like this 2x Intel Xeon E5-2695 v2 @ 2.40 GHz 2.40 GHz (2 processors, 8 cores total) 16 GB RAM

    So power should not be an issue either

    The problem is, that Slimmage won't start to load the next image in a slider, until slide action to the next image has begun. You can then see the image being rendered at the same time it slides in place.

    I can barely see the problem, but the client thinks it is a huge problem, and the client is always right, right sigh

    But the problem is really Slimmage, but I thought squeezing a bit more performance out of the image loading, could do it so rendering happened so fast, it wan't noticable by the client.

    And when I saw the behaviour in my first post, I thought that my answer was there.

    Preloading is complicated with all the parameters Slimmage puts on the image, and I can't really get it to work.

    The picture element is only supported by approx. 55% of browsers in use, most notable is that is not supported in Safari untill iOS 9.3.

    But I guess it could be an alternative to still serve responsive images, while fixing the rendering issue.

    Thank you for your thoughts and input, I greatly appreciate it.

Please Sign in or register to post replies

Write your reply to:

Draft