上个月，Appwrite 0.7发布了很多新功能。我们发布的最大特性之一是从使用Nginx+PHP FPM的堆栈切换到使用Swoole作为我们的底层HTTP服务器。
在Appwrite中，我们构建了一个开源的免费替代Google Firebase的项目，你可以在任何基础设施上托管它。我们的堆栈由一组Docker容器组成，使用微服务架构，可以快速扩展和调试组成我们后端API的各个组件。使用我们的后端API，开发人员可以为新的Web、移动或Flutter项目提供更好的起点。我们的项目基本上提供了一个可以处理用户、权限和数据的认证、存储、数据库、云函数和其他标准API的准备就绪的解决方案。
我们如何使用Swoole？
Swoole是一个高性能、可扩展、并发的TCP、UDP、Unix Socket、HTTP、WebSocket服务，使用PHP和易于使用的Coroutine Fiber API。使用Swoole，我们有一个单一的多线程进程运行我们的HTTP服务器，这允许我们的HTTP请求在多个用户之间共享内存。采用这种方法，我们可以保持持久的DB连接，避免为每个用户从头开始重新初始化我们的应用程序，这有助于更好地利用内存和CPU。
此外，Swoole还允许我们使用协程。Swoole Coroutine类似于其他语言或框架中的Coroutine。Swoole为每个请求创建一个Coroutine，并根据每个请求的IO状态进行调度。Swoole还配备了内置的Redis、MySQL和Postgres异步客户端，使我们能够进一步提高性能。
使用Swoole作为我们的Web服务器在设计像我们这样的微服务架构的系统时也是一种更健康的方法。与使用Supervisord管理所有Nginx、FPM和PHP进程的一个容器不同，我们的每个Docker容器都有一个单一的进程作为入口点，这样更容易扩展、调试和监视。你可以在不同的容器中使用Nginx和PHP，但它不适用于Docker并具有额外的开销。
基准测试
为了说明改进，我们对版本0.6.2和版本0.7.0进行了各种方案的基准测试。我们对多个Appwrite端点进行了读写数据的请求。所有请求都是针对需要身份验证和滥用控制的端点进行的，这些功能也受益于这些改进。
两个测试都在同一单个节点硬件上执行，并不旨在展示Swoole的最大性能能力，而是专注于与我们的旧版本的差异。以下结果是使用K6进行的500个并发客户端的负载和压力测试的5分钟。
版本0.6.2
可以看到，只有98%的请求成功。其余的由于过载而导致超时。
版本0.7
在版本0.7中，情况看起来非常不同。不仅所有请求都成功了，而且几乎有两倍的请求，平均响应时间约为旧版本的一半。
结论
综合考虑所有因素，这意味着性能总体增加了约91%。使用Swoole，我们的堆栈现在更快，更容易维护。实际上，在线基准测试表明，Swoole+PHP轻松击败了流行的Node.js和Python替代品，并且与编译语言如GO相差无几。
这种性能提升是我们正在采取的一系列步骤的一部分，以确保开发人员可以充分利用他们的Appwrite服务器。我们计划在即将发布的新版本中分享更多来自开发过程和Appwrite基准测试的数据和见解。
这也是一个很好的机会，感谢整个Swoole团队在我们的迁移过程中的支持和帮助，这个过程非常简单和快速。我们花了几天时间就得到了我们整个API的第一个工作版本。
接下来是什么？
如果你对Appwrite感兴趣，你可以查看我们的Web、Flutter或Server入门指南，并访问我们的Discord社区，在那里我们与超过1,300个Appwriters不断地聊Appwrite。
如果你对这些改进感到兴奋，你也应该通过访问我们的Github项目跟踪即将推出的新功能。你也可以在我们的Github问题上请求新功能，并在Appwrite RFCs存储库上查看我们即将推出的功能规格。抱歉，我无法翻译这个空白的代码块，因为它没有任何内容或上下文。请提供更多的信息。
评论(0)