(Server-Side Swift框架)Vapor 3.0 vs 2.0如何在性能方面做得如何？除了小规模项目之外,还有什么重要的吗？

Question

相比2.0,完美,或像Django这样的Python franeworks.如果可用于小规模项目以外的任何事情

Answer 1

我假设你的问题如下:

Vapor 3的架构变化对性能和大型项目意味着什么？

我会在讨论中将特定的硬数字留给其他框架.

Vapor 3是一个面向未来的框架.它具有极高的性能,内存使用量轻,可扩展,并具有大型官方支持的功能集.

性能

虽然这些不是硬数字,但我的笔记本电脑以每秒103k的明文请求/秒测量HTTP引擎.

该蒸汽框架是因为在默认中间件,服务和内容的系统开销稍低.它仍然真正具有80k请求/秒的明文吞吐量.

内存使用情况

启动时Vapor 3的内存开销在我的测试中介于6.4MB和7.5MB之间.这符合我测试的Go框架.

可扩展

Vapor 3的主要建筑差异是关键.我们已经开发了自己的Async库,它受Java生态系统的reactive-streams.org的启发.我们的流模型是一个拉流模型,其中数据不会强制在另一个库上,但是库在准备好时会请求更多数据.因为这适用于整个生态系统,所以无论请求的大小如何,内存使用率都会保持很低.此规则的少数例外是(多部分)表单,JSON和模板.模板化是我们将来能够应用适当反应性的唯一库.

特征

除了Web框架中的反应性,我们还构建了自己的ORM,Fluent.

Fluent默认支持SQLite,但也通过MongoKitten提供MySQL,PostgreSQL和MongoDB的驱动程序.

除了这些驱动程序,我们还得到了Redis的支持.

所有上述驱动程序都支持反应流和Codable.驱动程序是用Swift编写的,下面没有C库,并且针对减少的内存副本进行了高度优化.

积分

因为我们构建并维护了上述整个生态系统,所以我们能够在性能和API方面实现比大多数其他框架更深层次的集成.但是,这确实会对我们工作量的大小产生重大影响.

未来的证明

我们决定将大部分API内部化,直到需求明确可公开访问.这样做是为了确保对我们的实现的chages不会导致重大更改.

它适用于中/大型项目吗？

我无法做出判断.我是Vapor 3核心团队的成员.但是,我们有一个活跃的社区,能够告诉你他们到目前为止使用Vapor 3的经历.我们还处于测试阶段,所以我暂不发布它的产品.