I am wondering if you are looking at this problem from the wrong angle.
This is a scaling issue, and while it is good that the code/process is running as fast as possible. What you try to archive here, should be set up in such a way that you can easily scale by adding more hardware.
With other words, this is an architecture problem, and not necessarily caused by the execution speed of the code. This becomes especially true, if you think long term.
Assuming the system is not already setup this way, I would recommend to:
Make the thumbnail conversion asynchronous, and use a Queue system to handle the requests. The initial request will save the uploaded image to a shared cache, then create a queue message. The first available thumbnail worker (server), will then take the request, and create the thumbnail. With queue system I mean RabbitMQ, Amazon SQS etc. (There is a lot of alternatives, so make certain to do a proper review to find the best fit for your use case).
The benefit with this system is that you do not have a bottleneck when you need to scale fast. All you need to do is add more servers to create the workers you need. This way you can rapidly scale the operation from creating 100 thumbnails a minute, to 10000 thumbnails a minute, without having to change a line of source code.
And not to mention, many times it is more effective with several smaller servers to do the job, than one large one. Then if you take redundancy into the calculation, it is a no brainer.