I have two Omeka S installations on the same server. Both the installation use the same modules and the same vocabularies.
While one seems to be really fast in managing, the second is really very slow whenever I try to load a configuration page with a config form (configuration page of a module, edit page of an item, etc…).
I’m struggling to find why without any fortune.
Is there anyone that can suggest something to check?
Is there any way to measure processes time to find out where Omeka take long time?
I have update with the latest develop version 1.1.0-alpha (only application folder that should be enough?), but nothing is changed.
What I’ve seen analyzing the usage of DB by this Omeka-S instance is an huge bunch of identical twins of sql queries like these:
SELECT c0_.id AS id_0, c0_.label AS label_1, c0_.lang AS lang_2, c0_.terms AS terms_3, c0_.owner_id AS owner_id_4 FROM custom_vocab c0_ GROUP BY c0_.id ORDER BY c0_.id ASC
SELECT COUNT(*) AS dctrn_count FROM (SELECT c0_.id AS id_0, c0_.label AS label_1, c0_.lang AS lang_2, c0_.terms AS terms_3 FROM custom_vocab c0_ GROUP BY c0_.id ORDER BY c0_.id ASC) dctrn_table
This happens only for this particular instance. Does this make sense for someone?
Thanks in advance for any help!
Even if not repeatable on every Omeka-S sites, the problem looks to be strictly related with the usage (or even only to the load) of extra vocabularies.
It seems to be related to the module CustomVocab, not to the core. How many custom vocab do you have?
I was talking about Vocabularies as ontologies (classes and properties), not CustomVocabs. No CustomVocabs created at this time and I’ve also tried to remove that module without any difference in performance. But When I’ve removed Classes and Properties Vocabularies the site speeded up significantly. Does this make sense to you?
Because the sql queries are related exclusively with custom vocab. So there may be two issues in fact.
I see. As I have already tried to uninstall CustomVocab without any adavntage in terms of performances, do you think I have to try to do something directly on DB to remove any referneces to this module?
No, this module has a clean uninstall process. So it seems that the issue is related to the number of properties. How many properties do you have?
Well, schema.org, for instance, has 601 classes and 877 properties! But also if I use bibframe that has 186 classes and 195 properties the system slow down. What is sounds strange to me is that I don’t see the same behaviour on another system that is installed on the same server with the same modules. Now I’d like to make a further test loading schema.org on the site that seems to be unaffected by the amount of properties loaded and I let you know if performances change or not…
Well, after the test I can say that also for the second site, loading the schema.org vocabulary leads in a loss of performances but, in this case, the loss is very small. Vocabularies affect the first site much more then the second one. I understand that this diversity in amount of performances losses can be suspect, but I’m not able to see any real configuration defference between the two instances of Omeka-S. Let me know if you need more information or if you want me to do more tests.