Discussion :

[ericd69]

c'est un tout... le matériel, les différentes couches d'abstraction dont la VM, qui n'arrange rien... et enfin le sgbd et la façon dont il courcircuite l'accès RAM physique de l'OS

je défends généralement mysql, mais il faut quand même admettre que là on atteint ses limites par rapport à ce qu'il peut gérer...

donc oui il faut encore essayer des réglages de la VM... mais si aucune amélioration n'est visible alors un teste sur un vrai PC s'imposera avec linux...

mac est pas pensé vraiment pour ce genre de chose... c'est super avec les logiciels dédié pour son OS pour le multimédia voir certain outils de développements... après tu passe par des couches logicielles pas forcément performantes pour adapter telle ou telle logiciels...

une VM, c'est pas forcément efficace selon le processeur et s'il est optimisé pour ça...

donc essaye sur un vrai pc... si là tu as toujours plus de 1 seconde pour lire juste ton index avec des réglages mysql boostés... à mon avis, il faudra soit revoir ta table soit tester d'autres sgbd... je pense que ça se limiterait à sql server ou oracle, car contrairement aux autres ils ont leur allocateur mémoire directe indépendant de l'OS... les autres sgbd je ne crois pas (à voir avec ceux qui connaissent mieux postgresql)

punkoff je suis d'accord avec toi il faut encore faire des tests mais la référence c'est cette pauvre requête de comptage de ligne... si elle ne passe pas en moins d'une seconde... faut voir alors l'enfer pour la moindre jointure, etc...

de même si le DD est pas d'une génération récente... et là mac.. comment dire... bref utilise au moins un pc qui sera au plus proche du serveur final...

[re12]

Une partie de ma config :

innodb_buffer_pool_size = 7168M
key_buffer_size=2048M
innodb_flush_method=O_DIRECT
innodb_thread_concurrency=4

[ericd69]

et avec linux reboosté et ces réglage innodb, ça donne quoi?

[re12]

je passe a 7 secondes lors de l'exécution du premier COUNT.

[ericd69]

tant que pour cette requête tu es pas inférieur à 1 seconde c'est pas bon...

tu as un pc pour tester, linux (idéal) ou windows ?

[re12]

Je pourrai tester cela ce soir sur un poste fixe avec un os dédié (toujours une debian)

Par contre si je fais la requête du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT COUNT(*) AS total
FROM product 
WHERE company = 102

La requête dure 100ms et retourne la valeur 9998

[ericd69]

company n'apparait pas dans le create de ta table...

et si tu as un index sur company c'est forcément très rapide vu que tu ne lis pas la table ou l'index principal...

[re12]

je viens de le rajouter
J'ai mis un index dessus.

[re12]

Alors je reviens vers vous, je suis passé sur une machine dédié dont voici la configuration :

- Intel core i5 2430
- 4Gb de mémoire vive
- SSD Intel 330 "Maple Crest" - 120 Go

La configuration de MySQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
character-set-server=utf8
collation-server=utf8_general_ci
init-connect='SET NAMES utf8;SET autocommit=0;'
innodb_buffer_pool_size = 2800M
key_buffer_size=1024M

Quelques statistiques :

La table à maintenant 151 millions de ligne.

Le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT COUNT(*) FROM product

met 26,32 seconds à s'executer la première fois.

[punkoff]

Vous avez 151 millions de produits ? vous vendez quoi ?

(sous cette question je me demande si il n'y aurai pas un problème de modélisation...)

[re12]

En fait c'est une application en cours de développement, et j'essaie de la pousser un max pour faire mes tests de perf.

Seulement comme vous le dites je pense qu'a ce niveau il faut le penser à la modélisation.

[ericd69]

oui aucun sgbd ne te donnera de la perf à ce niveau là...

il faut à un moment ou un autre faire du partitionnement, du load balancing, de la parallélisation multiserveur

comme ce qui est fait pour les mmorpg temps réel par exemple

les limitations de la plateforme et du sgbd (réglages inclus) et les contraintes de restitution (web, applicatif, temps réel, etc...) vont impliquer de penser le modèle de donnée en conséquence...

c'est un tout...

par exemple, une bd d'objets 3d va pas être peuplée pareil si elle est destinée à faire du temps réel ou du rendu photo-réaliste sur des heures de calcul par image

faire des tests tels que tu les fait n'est donc pas très parlant... car plein d'autres choses vont plomber tes performances... à titre d'exemple: le nombre de tables dans ta bd, le moteur de bd aussi (mono serveur ou distribuée), etc...

donc faut d'abord faire le modèle de données lié à ton application puis l'adapter à la mise en charge en phase de test...

en gros, il y a tellement d'interdépendances qu'il ne faut pas mettre la charrue avant les bœufs

[Fred_34]

Tu es passé de 20 millions en 7 secondes à 150 millions en 26 secondes.
Ta nouvelle config est donc environ deux fois plus rapide que l'ancienne.
Tu utilises un disque SSD, était-ce le cas avant ?
Si on suppose que le temps de cette requête est principalement lié au fait qu'il faut relire tous les index de la table depuis le disque, j'aurai pensé qu'un disque SSD aurait donné de meilleurs résultats.

[SQLpro]

Avec une vue indexées, disponible par exemple sous MS SQL Server, votre résultat serait calculé dans un temps non mesurable.
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/optimisation/indexation/

Hélas MySQL étant l'un des SGBDR les moins performant qui soit, en plus de ne pas être un vrai SGBD relationnel et ayant de très nombreux manques en matière de fonctionnalité, je ne m'étonne donc pas de ces performances incompatibles avec un gros site web marchand !
A lire sur MySQL : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

A +

[re12]

Effectivement les chiffres parlent d'eux même.
Je ne pensais pas qu'il y avait une telle différence entre PostgreSQL et MySQL.

Vu que je suis encore à l'étape de développement de l'application je peux me permettre de revoir le modèle de données ainsi que le SGBD.

Je vais faire un test avec PostgreSQL afin de comparer.
Je vous donnerai les chiffres.

[punkoff]

Pour votre cas précis, postgresql souffre du même problème. (mais d'un point de vue générale vous aurez plus de possibilité avec ce dernier..)

[re12]

Quel SGBDR serait capable de gérer le cas de gros volumes de données et les transactions a votre avis ?

[CinePhil]

SQL Server, Oracle, DB2

[CinePhil]

Actuellement en formation Oracle, on vient de me donner une indication que tu pourrais tester pour ton COUNT.
Dans COUNT(*), l'étoile signifie "tout". C'est à dire pas toutes les lignes mais toute la table. Selon le formateur, COUNT(1) serait plus rapide que COUNT(*).