Moving From Nginx+FPM to Swoole Has Increased Our PHP API Performance by 91%

Appwrite 0.7 was just released last month with a lot of new features. One of the biggest features we released was our internal switch from a stack using Nginx + PHP FPM to using Swoole as our underline HTTP server.

In Appwrite, we build an open-source, free alternative to Google’s Firebase, which you can host on your own on any infrastructure. Our stack is composed of a set of Docker containers using a micro-services architecture, allowing us to scale and debug individual components composing our backend API quickly. Using our backend API, developers get a much better starting point for new web, mobile, or Flutter projects. Our project basically offers a ready-to-use Auth, Storage, Database, Cloud Functions, and other standard APIs any app requires to handle users, permissions, and data.

How We Use Swoole 👩‍💻👨‍💻

On top of that, Swoole also allows us to use Coroutines. Swoole Coroutine is similar to Coroutine in other languages or frameworks. Swoole creates one Coroutine for each request and schedules mainly based on the IO status of each request. Swoole also comes with built-in Redis, MySQL, AND Postgres async clients allowing us to push performance even farther.

Using Swoole as our web server is also a much healthier approach when designing a system to work in a microservices architecture like ours. Instead of having one container with Supervisord to manage all Nginx, FPM, and PHP process running altogether in the background, each of our Docker containers has one single process as an entry point which is much easier to scale, debug and monitor. You can use Nginx and PHP on separate containers, but don’t feel native to Docker and has extra overhead.

Benchmarks 🧪⚙️

Both tests have been performed on the same single node hardware and are not designed to show Swoole max performance capabilities but focus on the difference from our older version. The following results are for 5 minutes of load and stress testing with 500 concurrent clients using K6.

Version 0.6.2

Appwrite 0.6 benchmark results

As can be seen, only 98% of all requests were successful. The rest resulted in a timeout due to overload.

Version 0.7

Appwrite 0.7 benchmark results

With version 0.7, things look quite different. Not only were all requests successful, but there were almost twice as many requests with, on average, around half the response time.

Conclusions 🤔

Considering all factors together, this signifies a total increase in performance of ~91%. With Swoole, our stack is now way faster and easier to maintain. Actually, online benchmarks demonstrate that Swoole+PHP is beating popular Node.js and Python alternatives with ease and is not far behind compiled languages like GO.

This performance boost is part of a series of steps we are taking to ensure developers can take full advantage of their Appwrite servers. We plan to share more data and insights from both the development process and Appwrite benchmarks with upcoming new versions.

This is also a good opportunity to thank the entire Swoole team for their support and help in our migration process, which was surprisingly simple and fast. It literally took us a couple of days to get to a first working version of our entire API.

What’s Next? 🚀

If you’re excited about these improvements, you should probably also track what is coming up next by visiting our Github projects. You can also ask for new features on our Github issues and go over our upcoming feature specs on the Appwrite RFCs repository.

Entrepreneur, Software Architect, open source enthusiastic and the creator of appwrite.io. You can follow me on twitter: https://twitter.com/eldadfux