Optimisation requete DQL

Version imprimable

Voila, j'ai besoin de récuperer une collection d'enregistrement d'une table à partir d'un enregistrement d'une table parente. Ma collection devant être filtrés par une date max.
Voici mon schéma:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
 
groupasset:
  actAs: 
    Timestampable:
    Sluggable:
      fields: [name, site]
      unique: true
      canUpdate: true
  columns:
    name: string(255)
    site_id: integer
    user_id: integer
    status: string(2)
    person: string(2)
    lastview: date
  indexes:
    Unique1:
      fields: [name, site_id]
      type: unique
  relations:
    owner:
      class: sfGuardUser
      local: user_id
      foreign: id
      foreignAlias: groupassets
      onDelete: SET NULL
    site:
      class: Site
      local: site_id
      foreign: id
      onDelete: SET NULL
 
Typeasset:
  tableName: typeasset
  columns:
    name: string(255)
 
Asset:
  tableName: asset
  actAs: [Timestampable]
  columns:
    typeasset_id: integer
    value: string(255)
    groupasset_id: integer
    etat: string(50)
    action: string(50)
    lastview: date
  indexes:
    unique1:
      fields: [typeasset_id,value,groupasset_id]
      type: unique
    lastview:
      fields: 
        lastview:
          sorting: DESC      
  relations:
    type:
      class: Typeasset
      local: typeasset_id
      foreign: id
      foreignAlias: listTypeAsset
      onDelete: CASCADE
    group:
      class: groupasset
      local: groupasset_id
      foreign: id
      foreignAlias: listGroupAsset

donc a partir d'un enregistrement dans groupasset je veux récupérer tout les enregistrements liés de la table asset qui ont la date lastview la plus haute.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public function getListActiveGroupAsset()
	{
		if ($this->getListGroupAsset()->count()==0) return null;
		$list = $this->getListGroupAsset();
 
		$lastView = "2010-11-01";
 
		foreach($this->getListGroupAsset() as $asset)
		{
			if( $asset->getLastview()==$lastView){
				$list[]=$asset;
			}
		}
 
		return $list;
	}

si je met la date en dur comme ci-dessus j'ai un temps d'affichage de 1498ms, tout a fait correcte.
Mais si je vais chercher cette date:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public function getListActiveGroupAsset()
	{
		if ($this->getListGroupAsset()->count()==0) return null;
		$list = $this->getListGroupAsset();
 
		$lastView=Doctrine_Core::getTable('Asset')->getLastDate();
 
		foreach($this->getListGroupAsset() as $asset)
		{
			if( $asset->getLastview()==$lastView){
				$list[]=$asset;
			}
		}
 
		return $list;
	}

avec la function getLastDate():

Code:

1
2
3
4
5
6
7
8
9
 
public function getLastDate(){
		$q = $this->createQuery('a')
			->select('DISTINCT a.lastview ')
			->orderBy('a.lastview DESC')
			->fetchOne();
		$lastView = $q->getLastview();
		return $lastView;
	}

je passe à un temps d'affichage de 44262 ms !!!!
je ne m'explique pas ce temps ahurissant et comment résoudre ça ?

17/01/2011, 10h07
Michel Rotta

Je ne suis pas entièrement sur de savoir ce que tu veux comme résultat.

Par contre, avec la méthode qui recherche la date, tu vas avoir une requête pour chaque membre de getListGroupAsset, ce qui peut faire un nombre important de requête.

Je pense que tu aurais intérêt à créer une requête unique au départ qui récupère l'ensemble des informations en une seul passe au niveau sql.
17/01/2011, 10h24
erictomcat

en faites dans ma table asset je peut avoir des enregistrement qui ne sont plus actuel mais que je conserve pour des raisons d'historiques.
Par contre quand j'affiche les assets d'un group je ne veut affiché que ceux qui sont "actifs";
pour cela je gére un champ lastview dans la table asset.

Normalement je ne vais pas chercher la date a chaque enregistrement puisque je vais la chercher avant le Foreach. d'ailleurs au niveau du log des request SQL créés je ne la voie qu'une fois.

pour la requête unique j'y pense, mais je trouvait intéressant d'utiliser le foreignAlias de ma table asset pour récupérer tout les enregistrements liés à mon groupe et filtrer ensuite sur la date.
17/01/2011, 10h32
Michel Rotta

Est-ce que, dans ton shema, tu as un index sur lastview ?

oui:

Code:

1
2
3
4
5
6
7
8
9
10
 
...
indexes:
    unique1:
      fields: [typeasset_id,value,groupasset_id]
      type: unique
    lastview:
      fields: 
        lastview:
          sorting: DESC

17/01/2011, 14h31
Michel Rotta

En mode debug tu as pu identifier quel partie du code était aussi lente ?

comme dans un autre sujet c'est a la création de la page, et si je réduit le time_limit, ça plante au niveau de l'hydratation:
en allant récuperer la date:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
Configuration 12 26.87 0 
Factories 1 102.51 0 
Action "groupasset/edit" 1 44193.68 97 
Database (Doctrine) 42 0.56 0 
View "Success" for "groupasset/edit" 1 588.13 1 
Partial "groupasset/_assets" 1 1.58 0 
Partial "groupasset/_flashes" 1 1.55 0 
Partial "groupasset/_form_header" 1 2.07 0 
Partial "groupasset/_form" 1 508.73 1 
Partial "groupasset/_form_actions" 1 5.12 0 
Partial "groupasset/_form_footer" 1 2.42 0

en la mettant en dur:

Code:

1
2
3
4
5
6
7
8
9
10
11
Configuration 12 106.64 2 
Factories 1 731.12 14 
Action "groupasset/edit" 1 1656.27 33 
Database (Doctrine) 40 0.57 0 
View "Success" for "groupasset/edit" 1 1472.67 30 
Partial "groupasset/_assets" 1 1.57 0 
Partial "groupasset/_flashes" 1 1.57 0 
Partial "groupasset/_form_header" 1 2.41 0 
Partial "groupasset/_form" 1 933.02 19 
Partial "groupasset/_form_actions" 1 19.21 0 
Partial "groupasset/_form_footer" 1 2.33 0

17/01/2011, 16h22
Michel Rotta

C'est manifestement le code de l'action qui bouffe tous le temps.

Essaye de mettre des codes autour du lancement de la méthode qui récupère la date pour voir si c'est elle qui bouffe le temps. Je ne me rappel plus de la méthode, mais dans mes souvenirs, il y a une méthode dans l'objet debug qui permet de le faire. Objectif vérifier si c'est bien cette requête qui est mortel.

des fois je comprend pas tout avec doctrine/symfony.

il semblait que c'était l'action qui posait problème et non la requete de recherche de la date max.

Mais en réfléchissant, même si je faisait un fetchOne() je n'avait besoin que d'un enregistrement donc j'ai modifié ma request, avec un limit(1):

Code:

1
2
3
4
5
6
7
8
9
public function getLastDate(){
		$q = $this->createQuery('a')
			->select('DISTINCT a.lastview ')
			->orderBy('a.lastview DESC')
			->limit(1)
			->fetchOne();
 
		return $q->getLastview();
	}

et miracle !!! je retrouve des temps de réponse tout à fait correcte :mouarf:

bon il me lance la request 2 fois, je sais pas trop pourquoi mais je vais pouvoir lever cet issue pour le moment:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
SET NAMES 'UTF8'
 
0.00s, "doctrine" connection
SELECT g.id AS g__id, g.name AS g__name, g.site_id AS g__site_id, g.user_id AS g__user_id, g.status AS g__status, g.person AS g__person, g.lastview AS g__lastview, g.created_at AS g__created_at, g.updated_at AS g__updated_at, g.slug AS g__slug FROM groupasset g WHERE (g.id = '15162')
 
0.00s, "doctrine" connection
SELECT a.id AS a__id, a.typeasset_id AS a__typeasset_id, a.value AS a__value, a.groupasset_id AS a__groupasset_id, a.etat AS a__etat, a.action AS a__action, a.lastview AS a__lastview, a.created_at AS a__created_at, a.updated_at AS a__updated_at FROM asset a WHERE (a.groupasset_id IN ('15162'))
 
0.00s, "doctrine" connection
SELECT DISTINCT a.id AS a__id, a.lastview AS a__lastview FROM asset a ORDER BY a.lastview DESC LIMIT 1
 
0.00s, "doctrine" connection
SELECT DISTINCT a.id AS a__id, a.lastview AS a__lastview FROM asset a ORDER BY a.lastview DESC LIMIT 1
 
0.00s, "doctrine" connection
SELECT s.id AS s__id, s.name AS s__name, s.description AS s__description, s.manager_id AS s__manager_id, s.country_id AS s__country_id FROM site s WHERE (s.id = '12')
 
0.00s, "doctrine" connection
SELECT s.id AS s__id, s.first_name AS s__first_name, s.last_name AS s__last_name, s.email_address AS s__email_address, s.username AS s__username, s.algorithm AS s__algorithm, s.salt AS s__salt, s.password AS s__password, s.is_active AS s__is_active, s.is_super_admin AS s__is_super_admin, s.last_login AS s__last_login, s.matricule AS s__matricule, s.epass AS s__epass, s.costcenter_id AS s__costcenter_id, s.company_id AS s__company_id, s.emailintranet AS s__emailintranet, s.site_id AS s__site_id, s.contrat AS s__contrat, s.relationwithdupont AS s__relationwithdupont, s.esi AS s__esi, s.grpe_chq_dej_list_id AS s__grpe_chq_dej_list_id, s.startdate AS s__startdate, s.gardenleavedate AS s__gardenleavedate, s.offrolldate AS s__offrolldate, s.created_at AS s__created_at, s.updated_at AS s__updated_at FROM sf_guard_user s WHERE (s.id = '487') LIMIT 1
 
0.00s, "doctrine" connection

17/01/2011, 17h30
Michel Rotta

Mais c'est bien sur...

Le fechtOne commence par récupérer toutes les données pour n'en garder qu'une. Avec tes tables à 15.000 enregistrements...

Alors qu'avec limite, tu ne récupère que celui que tu veux, donc 1 dans le tuyau. CQFD.

Bien vu.
13/05/2011, 03h31
lenybernard

En effet c'est bien vu, j'avais pris pour acquis que fetchOne faisait un limit 1, c'est une chose étrange tout de même...
J'ai aussi du mal à optimiser comme il faut le nombre de requêtes doctrine... avez vous des resources à ce niveau la ? tutoriel, livre etc ?
Merci encore, bon courage
13/05/2011, 11h42
Michel Rotta

Non, pas de ressource.

Un brin d'expérience.

Il y a des trucs mais cela dépend d'où sont les trop plein de ressources.