Performance MongoDB-Java avec le pilote Sync reconstruit vs Async

Question

J'ai testé MongoDB 2.6.7 ces deux derniers mois en utilisant YCSB 0.1.4. J'ai capturé de bonnes données comparant SSD à HDD et je produis des rapports d'ingénierie. Une fois mes tests terminés, je voulais explorer le pilote async allanbank. Quand je l'ai fait fonctionner (je ne suis pas un développeur, donc c'était un défi pour moi), je voulais d'abord essayer le pilote de synchronisation reconstruit. J'ai trouvé des améliorations de performance de 30 à 100%, en fonction de la charge de travail, et j'en étais très content.

Ensuite, j'ai essayé le pilote asynchrone. Je n'ai pas été en mesure de voir beaucoup de différence entre elle et mes résultats avec le pilote natif.

La commande est en cours d'exécution, je suis:

./bin/ycsb run mongodb -s -P workloads/workloadb -p mongodb.url=mongodb://192.168.0.13:27017/ycsb -p mongodb.writeConcern=strict -threads 96 

Au cours de mes tests (la plupart du temps avec le pilote natif), je l'ai expérimenté avec plus ou moins de threads que 96; allumé "noatime"; essayé à la fois xfs et ext4; hyperthreading désactivé; désactivé la moitié de mes 12 cœurs; mettre le journal sur un lecteur différent; changement de synchronisation de 60 secondes à 1 seconde; et vérifié la bande passante réseau entre le client et le serveur pour s'assurer qu'il n'est pas sursouscrit (10GbE).

Vos commentaires ou suggestions sont les bienvenus.

Answer 1

Le mouvement Async a dépassé mes attentes. Mon expérience est avec le Python Sync (pymongo) et le pilote Async (moteur) et le pilote Async atteint plus de 10 fois le débit. De plus, le moteur utilise toujours le pymongo sous les capots mais ajoute la capacité asynchrone. cela pourrait facilement être le cas avec votre chauffeur allanbank.

Souvent, les changements importants proviennent des stratégies de thread et des configurations du système d'exploitation.

Async n'a pas besoin et ne doit pas utiliser plus de threads que les cœurs sur la VM ou la machine. Par exemple, si votre code serveur génère un nouveau thread par connexion entrante, tous les paris sont désactivés. Commencez par regarder la façon dont le conducteur est utilisé. Une machine 4 core utilise < = 4 threads entrants. Au niveau du système d'exploitation, vous devrez peut-être affiner les paramètres tels que net.core.somaxconn, net.core.netdev_max_backlog, sys.fs.file_max, /etc/security/limits.conf nofile et le meilleur endroit pour commence à regarder les guides de performance liés nginx including this one. nginx est le serveur qui a mené ou au moins attiré l'attention de nombreux enthousiastes de sysadmin de Linux. Contrairement à la tradition populaire, vous devriez réduire votre délai d'attente keepalive opposé à l'allonger. Le délai d'attente keep-alive par défaut est un nombre absurde (4 heures) de secondes. vous pourriez vouloir couper le cordon en 1 minute. Fondamentalement, pensez à une relation douce avec les relations de vos clients. Gardez à l'esprit que Mongo n'est pas Async, vous pouvez donc utiliser un pool de pilotes Mongo. Néanmoins, ne laissez pas le conducteur bloqué sur des requêtes lentes. couper en 5 à 10 secondes en utilisant les équivalents suivants en Java. Je ne fais que couper et coller ici sans recommandations.

# Specifies a time limit for a query operation. If the specified time is exceeded, the operation will be aborted and ExecutionTimeout is raised. If max_time_ms is None no limit is applied. 
# Raises TypeError if max_time_ms is not an integer or None. Raises InvalidOperation if this Cursor has already been used. 
CONN_MAX_TIME_MS = None 

# socketTimeoutMS: (integer) How long (in milliseconds) a send or receive on a socket can take before timing out. Defaults to None (no timeout). 
CLIENT_SOCKET_TIMEOUT_MS=None 

# connectTimeoutMS: (integer) How long (in milliseconds) a connection can take to be opened before timing out. Defaults to 20000. 
CLIENT_CONNECT_TIMEOUT_MS=20000 

# waitQueueTimeoutMS: (integer) How long (in milliseconds) a thread will wait for a socket from the pool if the pool has no free sockets. Defaults to None (no timeout). 
CLIENT_WAIT_QUEUE_TIMEOUT_MS=None 

# waitQueueMultiple: (integer) Multiplied by max_pool_size to give the number of threads allowed to wait for a socket at one time. Defaults to None (no waiters). 
CLIENT_WAIT_QUEUE_MULTIPLY=None 

Espérons que vous aurez le même succès. J'étais prêt à renflouer sur Python avant async