应用程序设计——ServiceStack； OrmLite.MySql;风趣； IDb连接；石英答案

【问题标题】：Application design - ServiceStack; OrmLite.MySql; Funq; IDbConnection; Quartz应用程序设计——ServiceStack； OrmLite.MySql;风趣； IDb连接；石英
【发布时间】：2016-03-12 08:53:33
【问题描述】：

我们有一个 ServiceStack 服务 (API)，它提供使用 AppSelfHostBase 托管的 HTTP 端点。这些服务稍后使用 ServiceStack.OrmLite.MySql 查询数据库。所有方法均使用 async / await 模式 实现。数据库连接手动注册到具有请求重用范围的 Funq，并注入到基 DAL 类的属性中。

当此服务仅由 HTTP 请求访问时，这一切正常。我们有另一个调用此 API 的 Windows 服务。由于它们可以托管在同一台服务器上，我们实现了本地 IRestClientAsync 来包装服务调用，因此 API 服务方法可以加载到 Windows 服务并访问更有效（例如 1200 req/sec 与 400 req/sec 相比）。这个 Windows 服务有很多线程同时运行。通过这样做，我们打破了请求生命周期并得到了

“已经有一个打开的 DataReader 与此 Connection 关联，必须先关闭。”

错误。我们尝试使用自定义连接提供程序手动处理此问题，使用 ThreadLocal 和 CallContext 通过线程分离连接。这并不是一直有效。我们尝试通过手动调用 OnBeginRequest(null); 和 OnEndRequest(); 来处理请求生命周期，但性能很差（接近 HTTP 调用），并且出现“打开 DataReader”错误。

我们使用 RequestContext.UseThreadStatic 选项，因为线程是从 Quartz .NET 作业实例化的。

管理数据库连接的最佳解决方案是什么？我们能否使当前的解决方案可靠地工作？

【问题讨论】：

标签： c# web-services servicestack quartz.net funq

【解决方案1】：

我要做的第一件事就是不要费心将 Async API 与 MySql 一起使用，因为它是 not truly asynchronous，因为它最终会在幕后创建新线程来伪造异步，这使得它比使用 Sync API 的效率更低。您也不能使用具有相同数据库连接的多个读取器，这最终会引发此异常。

所以我首先会回到使用 MySql 的同步 API，如果仍然存在问题，请使用瞬态范围（即不重复使用）而不是请求范围，并让 db 连接池完成其工作。请求范围在连接上的保留时间更长，占用了不必要的资源。

【讨论】：

感谢您的回答！在这种情况下（使用异步 .NET 客户端），您会推荐使用哪个数据库（在 Linux 上）？另外，为什么性能差异如此之大？我们能否以某种方式跳过一些 HTTP 生命周期步骤以获得更高的性能？
@МаркоПађен 只有 AFAIK 的 SQL Server 具有稳定的真正异步 ADO.NET 提供程序。看起来 Npgsql（PostgreSQL）现在在 v3 包中提供异步，因为它是一次重大升级，ORM 需要一些时间来升级到它。不知道跳过 HTTP 生命周期是什么意思。但为了获得最佳性能，您应该尽可能积极地缓存。
通过跳过 http 生命周期，我的意思是让请求初始化和发布部分花费更少的时间。我们有一个服务调用，当通过 http（自托管）访问时，每秒可以执行 400 个请求。如果通过调用SomeService : Service 对象的Post(SomeRequest request) 方法来调用相同的方法，则每秒最多可以获得1200 个请求。我知道反序列化请求、执行过滤器和其他检查、插件、funq 的东西有很多……但想知道我们是否可以利用这个过程？
@МаркоПађен 您可以通过在 AppHost/HostContext 上调用 ServiceController.Execute() 来执行 Request DTO 或 use ResolveService 直接调用服务方法来避免反序列化/http。