Database/speed optimizations

I have a pretty plain vanilla LAMP install on a brand new EC2 server with 2 cores, 4GB of RAM, and 100GB SSD storage. Giving it more power than usual to see if that makes any difference in terms of page load time, but so far, not much!

I’m talking specifically about what I believe is the “advanced search” queries.

Anything from filtering a document type:
http://54.81.83.101/digital/items/browse/?type=1

A metadata value filter:
http://54.81.83.101/digital/items/browse?advanced[0][element_id]=51&advanced[0][type]=is+exactly&advanced[0][terms]=Correspondence#results

A sort within browse items:
http://54.81.83.101/digital/items/browse?sort_field=Dublin+Core%2CIdentifier

etc…

Do you have a sense of whether the speed is primarily constrained by processor or RAM? Are there any easy/obvious/potential MySQL service changes in terms of database configuration tuning that would help? Bigger buffers? Bigger temp tables?

1 Like

Referencing this (arbitrary) article:

Now temporarily running a t2.large instance on AWS EC2:
t2.large
2 vCPU
8 GB RAM
EBS-Only
Low to Moderate

With these optimizations:
#optimizations for Omeka
innodb_buffer_pool_size=6G
innodb_log_file_size=4G
max_connections=250

Have gotten page loads down from 5-6 seconds to 3.8-4.1 secs:
“This page was created in 3.8431360721588 seconds”

Do you think this is just a limit of how advanced search in Omeka Classic is executed? And how the database tables are indexed?

Do you see any difference using the master branch of Omeka?

We made a change to the way that the advanced search operates, and we’ve seen significantly better performance in some scenarios.

I’ll add that to my list to give a try! Thanks for the note about the difference.

I just tried the /master branch (temporarily replaced files in root + /application) and didn’t see any difference in query time execution.