(Parlant d'un point de vue MySQL...)
Quelques "règles empiriques" :
- Un seul
INSERT:10ms - 100 lignes ou plus insérées par un seul
INSERT:10 fois plus rapide par ligne. BEGIN; INSERT...; INSERT...; ... COMMIT;:Aussi 10x.- Ce qui précède suppose un disque dur ; Le SSD pourrait être encore 10 fois plus rapide.
- Si plusieurs connexions effectuent chacune des insertions, elles peuvent pouvoir fonctionner en parallèle. 10 threads pourraient être capables de faire 5 fois le travail dans le même temps écoulé. (Bien sûr, cela peut ajouter une complexité indésirable à l'application.)
Chiffres similaires pour UPDATE , bien qu'il ne soit pas facile d'effectuer différentes mises à jour sur différentes lignes avec une seule requête.
Votre test affiche 8,5 ms par ligne UPDATEd lorsque vous faites une rangée à la fois. Traitement par lots soit avec BEGIN...COMMIT prendra probablement environ 85 ms pour les 100 lignes, même sur le disque dur.
Certaines applications se prêtent au traitement par lots; certains ne le font pas. Si vous souhaitez discuter de l'amélioration des performances de MySQL, nous devons entrer dans les détails de votre application.
Les compteurs "J'aime" et "Voir" peuvent doivent être déplacés vers une table "parallèle" car ils ont tendance à être mis à jour un par un, avec une certaine interférence avec d'autres activités. Ils ont également tendance à autoriser automatiquement le multi-threading, donc bien moins de 850 ms pour 100. En cas d'activité très élevée (plus de, disons, 1 000 vues par seconde), ces compteurs peuvent être regroupés artificiellement via un code d'application supplémentaire.
Veuillez réécrire votre benchmark pour refléter l'activité qui se produira dans l'application réelle. (Je suppose que les mises à jour se produiront en parallèle, et non en série. Et ils seront répartis de manière aléatoire dans le temps.)
Autre chose... Si chaque "view count" arrive sur un serveur web, alors il y a aussi connexion et déconnexion; d'où le écoulé le temps est susceptible d'être supérieur à 8,5 ms. Mais "écoulé" n'est pas le problème critique ; le vrai problème est "combien de mises à jour peuvent être effectuées par seconde".)
Et autre chose... Si vous testez 'parallèle', n'appuyez pas sur la même ligne à chaque requête. Ce sera probablement beaucoup plus lent que si vous frappez des lignes différentes. (Frapper une rangée au hasard serait mieux. Avoir un biais dans quelle rangée frapper serait encore plus réaliste.)
