MySQL pb de lenteur de requete - Page 1

yop à tous !

j'ai développé une appli (php+mysql) multi utilisateur relativement simple (un formulaire de saisie, avec la liste des 10 dernières saisies de l'utilisateur)

Elle sera utilisée à fond pendant 2 jours par environ 1000 personnes pour effectuée 1 000 000 enregistrements (soit un enregistrement par personne par minute, ou encore 18 enregistrements à la seconde pour la totalité des utilisateurs)

seulement 2 requêtes sont présentes : celle d'enregistrement, et celle permettant de récupérer les 10 derniers enregistrements faites par l'utilisateur.

j'ai fait un test de charge de l'application en local (afin de ne pas prendre en compte dans un premier temps les pbs de réseau) pour 10 000 pages sur 10 accès concurrentiels, et j'ai obtenus des résultats assez pourris... (40 pages par seconde, avec 28 secondes par page pour les dernières)

j'ai du coup fait des test, et j'ai réussit à isoler le pb : la récupération des 10 derniers enregistrements faites par l'utilisateur. Voici les tests que j'ai fait sur cette requête :

[ul]
[li]SELECT * FROM `promesses` WHERE `created_by` = 'USER' LIMIT 10
=> dans les 500 pages par secondes[/li]
[li]SELECT * FROM `promesses` ORDER BY `id` DESC LIMIT 10
=> dans les 500 pages par secondes[/li]
[li]SELECT * FROM `promesses` WHERE `created_by` = 'USER' ORDER BY `id` DESC LIMIT 10
=> dans les 40 pages par secondes[/li]
[/ul]

ces tests m'ont montrés que l'application en elle même était assez rapide (temps de traitement d'apache+php+mysql < 3ms), ce qui conviendra sans pb (restera les pbs de lenteur réseau, mais ce ne devrait pas posé de pb, les pages étant assez légère), à l'exception d'une requête...

Pour info, les tests ont été fait avec 20 000 enregistrements en base. `id` est un clef primaire auto-incrémenté, et `created_by`est en index

quelqu'un aurait une solution ???

- tes tables sont en quel systeme de stockage ? (MyISAM, Innodb, etc.)
- est ce que tes index sont triés en DESC par défaut ? (vu que tu fais que ca comme tri)
- quels sont les types de tes colonnes ?

voici la structure de ma table :

CREATE TABLE `promesses` (
  `id` bigint(20) unsigned NOT NULL auto_increment,
  `created_at` datetime NOT NULL,
  `created_by` varchar(15) collate latin1_general_ci NOT NULL,
  `updated_at` datetime NOT NULL,
  `updated_by` varchar(15) collate latin1_general_ci NOT NULL,
...,
  PRIMARY KEY  (`id`),
  KEY `created_by` (`created_by`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci 

comment ca, "tes index sont triés en DESC par défaut" ??? on peut faire ca ?

et le bigint(20) ça te ferait pas perdre du temps par rapport à un int(4) ou un int(8) ?

Pour le tri,

ALTER TABLE `promesses` ORDER BY `id` DESC

par contre je pense pas que le bigint change qqc aux perfs

Tu peux faire un explain sur tes requetes ?

l'explain me conseille de mettre un index sur le created_at (ce quie st déjà fait)

bon, ben je vais voir les diffs de perf avec int à la place de bigint, et avec le alter table

sinon met une clé double (id, created_by)

bigint => int : ca n'a kasi rien changé (j'ai juste gagné une page par seconde)

pour le "ALTER TABLE `promesses` ORDER BY `id` DESC" => en fait ca ne me servirait à rien, ca ne tri la table qu'à l'instant t. Ma page va être vu 17 fois par seconde, mais à chaque fois qu'elle est vue, un nouvel enregistrement a eu lieu, donc il faudrait faire un alter table après chaque insert, ce qui n'est pas envisageable, car ca ne ferait que déporter le pb de l'affichage vers l'insert...

bon, il me reste la clé double à tester, on va voir....