tarantool-c中的read_reply太慢

Question

我正在设置c服务器，并使用tarantool-c作为数据库使用tarantool。但是，每次我设置read_reply()时，每秒的请求都会像使用mysql一样。如何解决？

Answer 1

我们与James进行了讨论，他分享了code。该代码实现了http服务器，这就是它处理请求的方式：

• 接受新的传入http请求。
• 发送请求到tarantool（使用二进制协议）。
• 等待tarantool的回复（同步，无法处理其他传入的HTTP请求）。
• 回答http请求。

问题的根源在于我们无法利用http服务器和tarantool之间的整个网络带宽。这样的服务器应该使用select（）/ poll（）/ epoll（）（在Linux上）/ kqueue（在FreeBSD上）或libev之类的库来确定它是否能够写入套接字，从套接字读取或接受请求。

让我简单地描述一下when-X-then-Y规则集应如何操作（至少从一个线程使用网络时）：

• 当新的http请求到达时，它应该注册将请求发送到tarantool的需要（让我将其命名为待处理请求）。
• 当tarantool的套接字已准备好写入并且至少有一个挂起的请求时，服务器应向tarantool发出请求，保存其ID（请参阅tnt_stream.reqid）并将请求写入套接字。
li>
• 当tarantool的套接字已准备好读取时，服务器应读取tarantool的答复，将其ID（请参见tnt_reply.sync）与保存的ID相匹配，并向http客户端写入响应，然后将套接字关闭到客户。

如果需要支持http keepalive /流水线，则服务器需要检查http客户端的套接字以准备执行read（）/ write（）。此外，它还需要注册未决的http响应，而不是在它们出现时立即写。

此外，HTTP本身不容易以适当的方式实现：如果您不控制客户端和服务器的实现，它总是会给您带来惊喜。

因此，我将介绍实现其自己的http服务器的替代方法，这些替代方法与tarantool兼容并且能够以异步方式与它进行操作以获得良好的性能。他们是：

• 使用http.server tarantool模块，该模块允许直接在tarantool中处理http请求，而无需外部服务，并且不使用tarantool连接器。
• 使用nginx_upstream_tarantool nginx模块，该模块允许使用二进制协议从nginx执行对tarantool的请求。

这两种方式都有优点和缺点。但是，使用nginx作为将请求代理到tarantool的代理的前端可以克服http.server的缺点，从而节省http.server的优点。

http.server缺点：

• 不支持https。
• 单个CPU绑定/单个tarantool实例绑定。
• 性能可能比nginx差（但不多）。
• 对HTTP警告的支持可能更差（但我不知道）。

http.server的优点：

• 更容易开始开发。
• 配置/部署更简单：应用程序配置的某些部分不会分布在tarantool和nginx的配置中。

nginx_upstream_tarantool的利弊与http.server的利弊相反。我还要特别提到，nginx允许您在多个tarantool实例之间平衡负载，这些实例可能形成复制组或正在分片前端。此功能可用于按期望的性能扩展服务，例如代理到http.server以及nginx_upstream_tarantool。

我想您也对http.server和nginx_upstream_tarantool的基准测试结果感兴趣。查看this测量。但是请注意，它是非常综合的：它执行小的请求并以小的响应进行回答。实际RPS编号可能会有所不同，具体取决于请求和响应的大小，硬件，是否需要https等。