Une possibilité est qu'il puisse y avoir d'autres problèmes causant des problèmes de performances - 6 secondes semblent excessives pour les opérations CRUD, même sur une base de données complexe. Gardez à l'esprit que (à l'époque) ArsDigita pouvait gérer 30 hits par seconde sur un Sun Ultra 2 (IIRC) bidirectionnel avec une configuration de disque assez modeste. Un serveur bas de gamme moderne avec une disposition de disque raisonnable et un réglage approprié devrait être capable de faire face à une charge de travail assez importante.
-
Il vous manque un index ? - vérifier les plans de requête des requêtes lentes pour les analyses de table là où elles ne devraient pas être.
-
Quelle est la disposition du disque sur le serveur ? - avez-vous besoin de mettre à niveau votre matériel ou de résoudre certains problèmes de configuration de disque (par exemple, pas assez de disques, journaux sur le même volume que les données).
-
Comme le suggère l'autre affiche, vous voudrez peut-être utiliser InnoDB sur les tables fortement écrites.
-
Vérifiez la configuration de l'utilisation de la mémoire sur le serveur de base de données. Vous voudrez peut-être configurer plus de cache.
Modifier : Les journaux de base de données doivent résider sur des disques silencieux qui leur sont propres. Ils utilisent un modèle d'accès séquentiel avec de nombreuses petites écritures séquentielles. Lorsqu'ils partagent des disques avec une charge de travail d'accès aléatoire, comme des fichiers de données, l'accès aléatoire au disque crée un gros goulot d'étranglement des performances du système sur les journaux. Notez qu'il s'agit d'un trafic d'écriture qui doit être complété (c'est-à-dire écrit sur un disque physique), donc la mise en cache n'aide pas à cela.
