玩框架2.X和阻断数据库调用 [英] Play Framework 2.X and blocking database call

问题描述

我有点困惑。

从文档：

播放默认的线程池 - 这是默认的线程池，其中
  在播放框架的所有应用程序code被执行，不包括一些
  iteratees code。它是一个阿卡调度，并且可以通过可配置
  配置阿卡，如下所述。默认情况下，它每一个线程
  处理器。

Play default thread pool - This is the default thread pool in which all application code in Play Framework is executed, excluding some iteratees code. It is an Akka dispatcher, and can be configured by configuring Akka, described below. By default, it has one thread per processor.

是否造福于包装在未来阻塞数据库调用，在调用未来存在本身由包裹异步控制器（它返回），为了让在默认线程池处理其他用户的请求？

Does it bring benefit to wrap a blocking database call in a Future, the call to the Future being itself wrapped by an async controller (returning it), in order to let the default thread pool handling other users requests?

这将只是移动另一个线程（由专用的ExecutionContext）内阻塞code，但离开动作畅通。

It would just move the blocking code inside another thread (from a dedicated ExecutionContext), but leave the Action unblocked.

我碰到<少时href=\"http://stackoverflow.com/questions/22421322/how-to-rewrite-synchronous-controller-to-be-asynchronous-in-play\">this帖子但我并不满足于给定的答案。结果
事实上，如果我让数据库调用默认的线程池中的阻塞，是不是有可能prevent处理，这并不在此期间，依赖于数据库的其他用户的请求？

I came across this post but I'm not satisfied with the given answer.
Indeed, if I let the database call blocking within the default thread pool, wouldn't it potentially prevent handling other users requests that does not depend on database in the meantime?

请注意：我的数据库（Neo4j的）还没有一个异步驱动程序。

Note: My database (Neo4j) hasn't an async driver.

推荐答案

有几种方法来处理阻塞调用。我不能说这是最好的，因为这将肯定取决于具体的使用情况，并要求一吨的标杆。

There are a few ways to handle blocking calls. I can't say which is best, as it would most certainly depend on specific use cases, and require a ton of benchmarking.

在默认情况下，播放处理与利用每个CPU核心一个线程的线程池的请求。所以，如果你正在运行在一个四核CPU Google Play应用程式，例如，它只会如果他们使用的是阻塞调用数据库能够处理4个并发请求。所以，是的，所有其他的传入请求将不得不等待，直到一个线程被释放。

By default, Play handles requests using a thread pool with one thread per cpu core. So, if you're running your Play app on a quad-core cpu, for example, it will only be able to handle 4 concurrent requests if they're using blocking calls to the database. So yes, all other incoming requests will have to wait until one of the threads had been freed up.

的最简单的解决方案是增加的数目的线程播放用途来处理在默认线程池请求（在application.conf）：

The simplest solution is to increase the number of threads Play uses to process requests in the default thread pool (in application.conf):

play {
   akka {
     akka.loggers = ["akka.event.slf4j.Slf4jLogger"]
     loglevel = WARNING
     actor {
        default-dispatcher = {
           fork-join-executor {
             parallelism-min = 300
             parallelism-max = 300
           }
        }
     }
   }
}

下一个选项是你在你的问题提一 - 卸载拦截数据库调用另一个的ExecutionContext 。您可以在application.conf像这样配置一个单独的线程池：

The next option is the one you mention in your question--offloading blocking database calls to another ExecutionContext. You can configure a separate thread pool within application.conf like so:

database-io {
    fork-join-executor {
       parallelism-factor = 10.0
    }
}

这将在名为数据库IO 池创建每个CPU核心10线程，并能起到内，像这样来访问：

This will create a 10 threads per cpu core in the pool called database-io, and can be accessed within Play like so:

val dbExecutor: ExecutionContext = Akka.system.dispatchers.lookup("database-io")

val something = Future(someBlockingCallToDb())(dbExecutor)

这将使默认的线程池，而它的等待未来处理更多的请求来完成。第三种选择是使用演员来处理数据库的调用，但这是更为复杂和超出此问题的范围。

This will allow the default thread pool to handle more requests while it's waiting for the Future to complete. A third option would be to use an Actor to handle the database calls, but that's more complicated and beyond the scope of this question.

底线是，是后，使用一个更大的线程池或不同的的ExecutionContext 阻止呼叫，您从不要在默认线程池阻塞，如果你能帮助它。

The bottom line is, yes, use a larger thread pool or a different ExecutionContext for blocking calls, as you never want to block in the default thread pool if you can help it.

这是所有在线程池中的播放文件概述。 （最新版本）

This is all outlined in the Play Documentation for Thread Pools. (latest version)

这篇关于玩框架2.X和阻断数据库调用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！