multithreading - Mahout优化: Multithreading TopItems. getTopUsers()和TopItems.getTopItems()

Question

我们有以下系统:
用户数:〜500k
项目数:〜100k

UserSimilarity userSimilarity = new TanimotoCoefficientSimilarity(dataModel);       
UserNeighborhood neighborhood = new NearestNUserNeighborhood(neighborHoodSize,userSimilarity, dataModel);
GenericBooleanPrefUserBasedRecommender recommender = new GenericBooleanPrefUserBasedRecommender(dataModel, neighborhood ,userSimilarity);

通过以上推荐器，我们得到了400个邻域大小的平均600ms响应时间。

我们尝试使其小于100毫秒(在线引擎)，并且确实通过使用自定义的TopItems.getTopUsers()和TopItems.getTopItems()多线程(等于核数)函数来实现。功能所需的平均时间
TopUsers():〜30-40毫秒
TopItems():〜50-60毫秒

但是，当我们尝试发出多个并发请求(甚至达到25个命令)时，响应时间将激增至几秒钟。

我们可以为每个用户预计算类似邻居的内容，但是TopItems()仍然是并发请求的明显瓶颈。

您会提出任何方法来改善多线程并发请求的响应时间吗？

后备选项将是将预先计算的建议存储在某些NoSql DB中。
这对于我们来说是很便宜的，因为即使不是很活跃的用户，我们也可以定期进行预计算。我们可能会选择活跃用户并比不那么活跃的用户更频繁地预先计算推荐。

有什么想法吗？

Answer 1

是的，多线程不会增加系统的整体吞吐量。这意味着您可以承担更多线程来更快地响应一个请求。但是，当并发请求数等于您的内核数时，它或多或少返回到您开始的地方。实际上，线程的开销可能会使它变慢。

当然，您始终可以尝试添加更多计算机并维护该服务的N个实例。

这可能与您将在基于邻域的模型上所做的一样好。与项目相邻的版本还有更多杠杆可供您使用:您可以控制对所考虑项目数量的采样。这会有所帮助。

除此之外，您可能还需要查看为更好地扩展而构建的模型。我个人更喜欢以此方式基于矩阵分解的技术。