Tornado

The 350M API requests we handle daily include many processing tasks such as image enhancements, resizing, filtering, face recognition, and GIF to video conversions.

Tornado is the one we currently use and aiohttp is the one we intend to implement in production in the near future. Both tools support handling huge amounts of requests but aiohttp is preferable as it uses asyncio which is Python-native. Since Python is in the heart of our service, we initially used PIL followed by Pillow. We kind of still do. When we figured resizing was the most taxing processing operation, Alex, our engineer, created the fork named Pillow-SIMD and implemented a good number of optimizations into it to make it 15 times faster than ImageMagick

Thanks to the optimizations, Uploadcare now needs six times fewer servers to process images. Here, by servers I also mean separate Amazon EC2 instances handling processing and the first layer of caching. The processing instances are also paired with AWS Elastic Load Balancing (ELB) which helps ingest files to the CDN.

setup an api for a client with tornado backend. incredibly fast and lightweight. unfortunately breaks down when using third party libraries which block internally. Tornado

Tornado with Async/Await coroutines provided in Python 3.5 make up for an excellent stack for a micro-service. Tornado

SpreadServe's RealTimeWebServer is built in Tornado. Spreadsheets loaded into SpreadServeEngine instances are projected into browsers using Tornado. Server side recalcs are pushed to the browser using web sockets. Tornado

We use Tornado as our websockets server, using SockJS (an alternative to socket.io). Tornado