Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improving loggable extension querying performance #18

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

adagber
Copy link

@adagber adagber commented Aug 14, 2015

The issue is that the query got by the getLogEntriesQuery method don’t use the correct MySQL index therefore the performance is very low when the ext_log_entries has a several millions of rows.

The problem is that the “object_id” field in ext_log_entries table is a varchar(64) type field.

The table has the next indexes:

  • PRIMARY (id)
  • log_class_lookup_idx (object_class)
  • log_date_lookup_idx (logged_at)
  • log_user_lookup_idx (username)
  • log_version_lookup_idx (object_id, object_class, version)

getLogEntriesQuery method queries entries by objectId, objectClass and ordered by version. The right index should be log_version_lookup_idx but mysql always use log_class_lookup_idx even thought you force the log_version_lookup_idx index. This happens because objectId is stored as a varchar field and then is queried using an integer value. As an example:

where log.objectId = 1 AND log.objectClass = “AppBundle\Entity\FooClass” ORDER BY log.version DESC -> this uses log_class_lookup_idx index
where log.objectId = “1” AND log.objectClass = “AppBundle\Entity\FooClass” ORDER BY log.version DESC -> this uses log_version_lookup_idx index

In my case, I have 35 million rows in ext_log_entries table. When I perform a query with log_class_lookup_idx index, it takes several minutes!!! (a lot of time). But the same query with the log_version_lookup_idx takes a few milliseconds (great).

I propose, change the line 57 and 89 on Gedmo/Loggable/Entity/Repository/LogEntryRepository.php

Original: $objectId = $wrapped->getIdentifier();
To: $objectId = (string) $wrapped->getIdentifier();

By this way, Mysql will use log_version_lookup_idx index and it will improve performance in a big way.

Thanks a lot.

The issue is that the query got by the getLogEntriesQuery method don’t use the correct MySQL index therefore the performance is very low when the ext_log_entries has a several millions of rows.

The problem is that the “object_id” field in ext_log_entries table is a varchar(64) type field.

The table has the next indexes:

 - PRIMARY (id)
 - log_class_lookup_idx (object_class)
 - log_date_lookup_idx (logged_at)
 - log_user_lookup_idx (username)
 - log_version_lookup_idx (object_id, object_class, version)

getLogEntriesQuery method queries entries by objectId, objectClass and ordered by version. The right index should be log_version_lookup_idx but mysql always use log_class_lookup_idx even thought you force the log_version_lookup_idx index. This happens because objectId is stored as a varchar field and then is queried using an integer value. As an example:

   where log.objectId = 1 AND log.objectClass = “AppBundle\Entity\FooClass” ORDER BY log.version DESC -> this uses log_class_lookup_idx index
   where log.objectId = “1” AND log.objectClass = “AppBundle\Entity\FooClass” ORDER BY log.version DESC -> this uses log_version_lookup_idx index

In my case, I have 35 million rows in ext_log_entries table. When I perform a query with log_class_lookup_idx index, it takes several minutes!!! (a lot of time). But the same query with the log_version_lookup_idx takes a few milliseconds (great).

I propose, change the line 57 and 89 on Gedmo/Loggable/Entity/Repository/LogEntryRepository.php 

Original:         $objectId = $wrapped->getIdentifier();
To:               $objectId = (string) $wrapped->getIdentifier();

By this way, Mysql will use log_version_lookup_idx index and it will improve performance in a big way.

Thanks a lot.
@l3pp4rd
Copy link
Owner

l3pp4rd commented Aug 14, 2015

you should PR to https://github.com/Atlantic18/DoctrineExtensions
regarding mapping, you can extend the loggable mapped supperclass instead and modify the annotation for objectId to be integer instead. Although, loggable is not that usable, check a specific impl audit bundle

@adagber
Copy link
Author

adagber commented Sep 1, 2015

Hi,
How can I PR to https://github.com/Atlantic18/DoctrineExtensions from my current fork?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants