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 ???

Ancien pseudo : lolo

2

- 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 ?
avatar
Webmaster et développeur du site. Pour tout probleme ou question envoyez un mini message ou mail.

Suivez l'actualité de tous vos site préférés sur yAronews : http://ns.yaronet.com =)

3

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 
Ancien pseudo : lolo

4

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

5

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

6

Pour le tri,

ALTER TABLE `promesses` ORDER BY `id` DESC

par contre je pense pas que le bigint change qqc aux perfs
avatar
Webmaster et développeur du site. Pour tout probleme ou question envoyez un mini message ou mail.

Suivez l'actualité de tous vos site préférés sur yAronews : http://ns.yaronet.com =)

7

Tu peux faire un explain sur tes requetes ?
avatar
Webmaster et développeur du site. Pour tout probleme ou question envoyez un mini message ou mail.

Suivez l'actualité de tous vos site préférés sur yAronews : http://ns.yaronet.com =)

8

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
Ancien pseudo : lolo

9

sinon met une clé double (id, created_by) smile
avatar
Webmaster et développeur du site. Pour tout probleme ou question envoyez un mini message ou mail.

Suivez l'actualité de tous vos site préférés sur yAronews : http://ns.yaronet.com =)

10

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....
Ancien pseudo : lolo