4 ms·
I guess it would be depend on the resizing profile, fetching from a remote origin and reading into a buffer should involved <1ms of computer time (latency not a
by sitepodmatt 9y ago
I guess it would be depend on the resizing profile, fetching from a remote origin and reading into a buffer should involved <1ms of computer time (latency not an issue given 15seconds of async wait) but then guaranteeing all done in 50ms of compute time for resizing I would be doubtful, if you could get compute bound resizing node.js code to yield control the event loop every 1ms you could abort after 14ms and issue a subrequest to your own image resize processing server or something like imgix.
- trevyn 9y ago>all done in 50ms of compute time for resizing I would be doubtful I don’t know the details of your environment or timing precision, but I’m quite sure that a single core on a modern server CPU can resize and JPEG compress more than 20 reasonably-sized images per second. :-)
- sitepodmatt 9y agoYou're probably right, presumably the 50ms of compute time, is that of reasonable 1.6ghz xeon+, and compute time is accounted as actual real compute time - not inclusive of waiting on some virtual CPU to be multiplexed onto a real core.
- ht85 9y agoI benchmarked various programs to resize images a year ago. There was a JS package with native bindings to GD, a go program, and a pure JS implementation. Both go and GD were an order of magnitude faster at scaling down and converting PNG to JPG.
- zackbloom 9y agoAs the person who's desk is next to @kentonv, I think the only reasonable thing to do is to build in image resizing service, make it incredibly popular, and drive him crazy with your never ending resource requirements. Joking aside, we don't know yet what is and isn't possible. Please build this and other things. If you need help or more resources, including CPU time, please reach out (workers-developer-help@cloudflare.com).