2

次のシステムを導入してい
ます: ユーザー数: ~500k
アイテム数: ~100k

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

上記のレコメンダーを使用すると、400 の近傍サイズで平均 600 ミリ秒の応答時間が得られました。

これを 100 ミリ秒未満 (オンライン エンジン) にしようとしましたが、カスタムの TopItems.getTopUsers()およびTopItems.getTopItems()マルチスレッド (コア数に等しい) 関数を使用してこれを達成しました。関数の平均所要時間
TopUsers(): ~ 30-40 ms
TopItems(): ~ 50-60 ms

ただし、多くの同時リクエスト (25 のオーダーまで) を試みた場合、応答時間は数秒に短縮されます。

各ユーザーの近隣などを事前に計算する余裕はありますが、TopItems() は依然として同時リクエストの明確なボトルネックです。

マルチスレッドによる同時リクエストの応答時間を改善する方法はありますか?

フォールバック オプションは、事前計算された推奨事項を一部の NoSql DB に保存することです。それほどアクティブでないユーザーに対しても定期的に事前計算を行うため、これは少しコストがかかります。おそらく、アクティブなユーザーを選択し、あまりアクティブでないユーザーよりも頻繁に推奨事項を事前計算することができます。

何かご意見は？

4

1 に答える 1

1

はい、マルチスレッド化によってシステム全体のスループットが向上するわけではありません。これは、より多くのスレッドを処理することで、1 つの要求により速く応答できることを意味します。しかし、同時リクエストの数がコアの数と同じになると、多かれ少なかれ最初の状態に戻ります。実際、スレッド化のオーバーヘッドにより速度が低下する可能性があります。

もちろん、いつでもマシンを追加して、このサービスの N インスタンスを維持することができます。

これはおそらく、近隣ベースのモデルで行うこととほぼ同じです。item-neighborhood バージョンには、プルするレバーがいくつかあります。考慮されるアイテムの数のサンプリングを制御できます。これは役に立ちます。

それを超えて、より適切にスケーリングするように構築されたモデルを検討する必要があるでしょう。個人的には、行列分解ベースの手法の方が優れていると思います。

于 2013-07-11T16:16:43.137 に答える