2012-04-05 4 views
0

Je suis en train de tester quelques solutions NoSQL et je me concentre principalement sur les performances de lecture. Aujourd'hui était le jour MongoDb. La machine de test est une VM avec un processeur Quad Core Xeon à 2,93 GHz et 8 Go de RAM.MongoDb/C# performance de lecture concurrente médiocre

Je teste avec seulement la base de données et une collection unique avec ~ 100.000 documents. La taille du document BSON est d'environ 20 Ko, plus ou moins.

L'objet géré Je travaille avec est:

private class Job 
{ 
    public int Id { get; set; } 
    public string OrganizationName { get; set; } 
    public List<string> Categories { get; set; } 
    public List<string> Industries { get; set; } 
    public int Identifier { get; set; } 
    public string Description { get; set; } 
} 

Le processus de test:

-Créer 100 threads.

-Démarrer tous les filetages.

-Tout thread lit 20 documents aléatoires de la collection.

est ici la méthode de sélection J'utilise:

private static void TestSelectWithCursor(object state) 
{ 
    resetEvent.WaitOne(); 

    MongoCollection jobs = (state as MongoCollection); 
    var q = jobs.AsQueryable<Job>(); 
    Random r = new Random(938432094); 
    List<int> ids = new List<int>(); 
    for (int i = 0; i != 20; ++i) 
    { 
     ids.Add(r.Next(1000, 100000)); 
    } 
    Stopwatch sw = Stopwatch.StartNew(); 
    var subset = from j in q 
       where j.Id.In(ids) 
       select j; 

    int count = 0; 
    foreach (Job job in subset) 
    { 
     count++; 
    } 
    Console.WriteLine("Retrieved {0} documents in {1} ms.", count, sw.ElapsedMilliseconds); 
    ThreadsCount++; 
} 

Le truc « count ++ » est juste de faire semblant que je fais quelque chose après avoir récupéré le curseur, alors s'il vous plaît ignorer.

Quoi qu'il en soit, l'idée est que j'obtiens ce qui me semble être des temps de lecture très lents. Ceci est un résultat de test typique:

> 100 threads created. 
> 
> Retrieved 20 documents in 272 ms. Retrieved 20 documents in 522 ms. 
> Retrieved 20 documents in 681 ms. Retrieved 20 documents in 732 ms. 
> Retrieved 20 documents in 769 ms. Retrieved 20 documents in 843 ms. 
> Retrieved 20 documents in 1038 ms. Retrieved 20 documents in 1139 ms. 
> Retrieved 20 documents in 1163 ms. Retrieved 20 documents in 1170 ms. 
> Retrieved 20 documents in 1206 ms. Retrieved 20 documents in 1243 ms. 
> Retrieved 20 documents in 1322 ms. Retrieved 20 documents in 1378 ms. 
> Retrieved 20 documents in 1463 ms. Retrieved 20 documents in 1507 ms. 
> Retrieved 20 documents in 1530 ms. Retrieved 20 documents in 1557 ms. 
> Retrieved 20 documents in 1567 ms. Retrieved 20 documents in 1617 ms. 
> Retrieved 20 documents in 1626 ms. Retrieved 20 documents in 1659 ms. 
> Retrieved 20 documents in 1666 ms. Retrieved 20 documents in 1687 ms. 
> Retrieved 20 documents in 1711 ms. Retrieved 20 documents in 1731 ms. 
> Retrieved 20 documents in 1763 ms. Retrieved 20 documents in 1839 ms. 
> Retrieved 20 documents in 1854 ms. Retrieved 20 documents in 1887 ms. 
> Retrieved 20 documents in 1906 ms. Retrieved 20 documents in 1946 ms. 
> Retrieved 20 documents in 1962 ms. Retrieved 20 documents in 1967 ms. 
> Retrieved 20 documents in 1969 ms. Retrieved 20 documents in 1977 ms. 
> Retrieved 20 documents in 1996 ms. Retrieved 20 documents in 2005 ms. 
> Retrieved 20 documents in 2009 ms. Retrieved 20 documents in 2025 ms. 
> Retrieved 20 documents in 2035 ms. Retrieved 20 documents in 2066 ms. 
> Retrieved 20 documents in 2093 ms. Retrieved 20 documents in 2111 ms. 
> Retrieved 20 documents in 2133 ms. Retrieved 20 documents in 2147 ms. 
> Retrieved 20 documents in 2150 ms. Retrieved 20 documents in 2152 ms. 
> Retrieved 20 documents in 2155 ms. Retrieved 20 documents in 2160 ms. 
> Retrieved 20 documents in 2166 ms. Retrieved 20 documents in 2196 ms. 
> Retrieved 20 documents in 2202 ms. Retrieved 20 documents in 2254 ms. 
> Retrieved 20 documents in 2256 ms. Retrieved 20 documents in 2262 ms. 
> Retrieved 20 documents in 2263 ms. Retrieved 20 documents in 2285 ms. 
> Retrieved 20 documents in 2326 ms. Retrieved 20 documents in 2336 ms. 
> Retrieved 20 documents in 2337 ms. Retrieved 20 documents in 2350 ms. 
> Retrieved 20 documents in 2372 ms. Retrieved 20 documents in 2384 ms. 
> Retrieved 20 documents in 2412 ms. Retrieved 20 documents in 2426 ms. 
> Retrieved 20 documents in 2457 ms. Retrieved 20 documents in 2473 ms. 
> Retrieved 20 documents in 2521 ms. Retrieved 20 documents in 2528 ms. 
> Retrieved 20 documents in 2604 ms. Retrieved 20 documents in 2659 ms. 
> Retrieved 20 documents in 2670 ms. Retrieved 20 documents in 2687 ms. 
> Retrieved 20 documents in 2961 ms. Retrieved 20 documents in 3234 ms. 
> Retrieved 20 documents in 3434 ms. Retrieved 20 documents in 3440 ms. 
> Retrieved 20 documents in 3452 ms. Retrieved 20 documents in 3466 ms. 
> Retrieved 20 documents in 3502 ms. Retrieved 20 documents in 3524 ms. 
> Retrieved 20 documents in 3561 ms. Retrieved 20 documents in 3611 ms. 
> Retrieved 20 documents in 3652 ms. Retrieved 20 documents in 3655 ms. 
> Retrieved 20 documents in 3666 ms. Retrieved 20 documents in 3711 ms. 
> Retrieved 20 documents in 3742 ms. Retrieved 20 documents in 3821 ms. 
> Retrieved 20 documents in 3850 ms. Retrieved 20 documents in 4020 ms. 
> Retrieved 20 documents in 5143 ms. Retrieved 20 documents in 6607 ms. 
> Retrieved 20 documents in 6630 ms. Retrieved 20 documents in 6633 ms. 
> Retrieved 20 documents in 6637 ms. Retrieved 20 documents in 6639 ms. 
> Retrieved 20 documents in 6801 ms. Retrieved 20 documents in 9302 ms. 

La ligne de fond est que je m'attendais à obtenir des temps de lecture beaucoup plus rapides que cela. Je pense toujours que je fais quelque chose de mal. Je ne sais pas quelle autre information je peux fournir maintenant, mais si quelque chose est manqué alors s'il vous plaît faites le moi savoir.

Je suis aussi, y compris, en espérant que ça vous aidera, l'expliquer() trace sur l'une des requêtes qui est exécutée par le test:

{ 
     "cursor" : "BtreeCursor _id_ multi", 
     "nscanned" : 39, 
     "nscannedObjects" : 20, 
     "n" : 20, 
     "millis" : 0, 
     "nYields" : 0, 
     "nChunkSkips" : 0, 
     "isMultiKey" : false, 
     "indexOnly" : false, 
     "indexBounds" : { 
       "_id" : [ 
         [ 
           3276, 
           3276 
         ], 
         [ 
           8257, 
           8257 
         ], 
         [ 
           11189, 
           11189 
         ], 
         [ 
           21779, 
           21779 
         ], 
         [ 
           22293, 
           22293 
         ], 
         [ 
           23376, 
           23376 
         ], 
         [ 
           28656, 
           28656 
         ], 
         [ 
           29557, 
           29557 
         ], 
         [ 
           32160, 
           32160 
         ], 
         [ 
           34833, 
           34833 
         ], 
         [ 
           35922, 
           35922 
         ], 
         [ 
           39141, 
           39141 
         ], 
         [ 
           49094, 
           49094 
         ], 
         [ 
           54554, 
           54554 
         ], 
         [ 
           67684, 
           67684 
         ], 
         [ 
           76384, 
           76384 
         ], 
         [ 
           85612, 
           85612 
         ], 
         [ 
           85838, 
           85838 
         ], 
         [ 
           91634, 
           91634 
         ], 
         [ 
           99891, 
           99891 
         ] 
       ] 
     } 
} 

Si vous avez une idée, je vais être le plus anxieux de le lire. Merci d'avance!

Marcel

+0

Eh bien, pas de chance jusqu'à maintenant ... Des idées nouvelles? –

+0

Salut marceln, je regarde. Juste pour la rigueur, vous avez mentionné que vous étiez en train d'en tester d'autres également. Avez-vous exécuté ce test contre ceux-ci et avez-vous eu des résultats différents? –

+0

J'essaie de rester avec Mongo. J'ai testé RavenDb, mais c'est trop lent. J'ai aussi testé CouchDb brièvement, ce qui me semble encore plus lent. Quoi qu'il en soit, je voudrais utiliser MongoDb car les autres n'ont qu'une interface REST, ce qui n'est pas aussi rapide que le protocole binaire de Mongo (je pense). –

Répondre

2

Je soupçonne que le « dans » (Modificateur générique) est une analyse séquentielle force avec l'extraction complète de chaque document pour vérifier la clause where, sans passer par l'efficacité de l'utilisation de l'indice _id. Étant donné que les nombres aléatoires peuvent être assez distribués, je suppose que chaque thread/requête analyse essentiellement la base de données complète.

Je suggère d'essayer quelques choses. (1) Interrogation individuellement pour chacun des 20 documents par identifiant unique personne (2) Pensez à utiliser un MongoCursor et utiliser Expliquer pour obtenir des informations sur l'utilisation d'index pour votre requête

bénédictions,

-Gary

PS Les temps d'exécution semblent indiquer qu'il existe également des effets d'ordonnancement de threads au travail.

+0

Merci Gary! Cependant, récupérer chaque document individuellement n'a pas amélioré les résultats. La sortie explain() pour la clause In est ci-dessus. Comme vous pouvez le voir, un thread ne provoque pas l'analyse de la base de données entière (nscanned est très faible). Mais je pense que vous aviez raison de dire que le fait d'avoir beaucoup de threads accédant à des documents aléatoires entraînerait l'analyse de la base de données de toute façon. Pas tout à la fois, mais 100 fois en plus petites quantités. J'essaierai aussi le forum MongoDb. –

Questions connexes