Recognizing that there are many ways every person’s Omeka Classic/Omeka-S instances vary across servers and networks and architectures, I’m still thinking there is a specific issue with my Omeka-S instance that might be applicable across multiple implementations.
On the same server, which is a decent modern VM but nothing superpowered (anyway I don’t think Apache, MySQL, and Omeka/Omeka-S take advantage of multiple cores or huge amounts of RAM) - in Omeka Classic, the admin/items view page takes a total of 3.3 seconds to load, with a 1.2 second wait before any response (presumably, a SQL query being executed to populate the results).
In Omeka-S, with nearly exact same set of documents (154,520), the admin/items page takes a total of 7.6 seconds to load, with a 5.5 second delay before ANY response (presume the same as above). So, once the query is delivered, both Omeka-S and Omeka Classic take exactly 2.1 seconds to render the page!
But for some reason, Omeka-S has a 5 second delay. Posting the Firefox > Web Developer > Network view screenshots to demonstrate this.
https://codepen.io/benbakelaar/full/XONwrr
Any suggestions as to what I should check on the server? In the database? On the app config?
Both load times feel slow to me… it’s a fairly large number of items and you’ve got bigger-than-standard pages configured which will slow things down on either system but usually the “standard” browse views don’t really have huge load times (whereas some of the searches we allow can be quite slow).
I would imagine that you’re correct that the source of the delay is database queries… I assume you’d see a pretty strong relationship between load times and your configured page limit.
Thanks John! Just ran a test, reduced items per page to 50.
Still a 4.4 second delay! Even though page size is ~200KB first ~400KB (which seems really high for HTML??).
Note the timings report in the bottom right. The server is not even responding to the first call (the base HTML file) until 4.4 seconds - so that means that the PHP code is assembling the HTML output which will be sent to the browser/file, and inside that, the MySQL database is being called to populate that table.
Now, call me crazy - I was just reviewing this before you posted and I swear that the load time on Omeka-S dropped to 500ms for the first item. 500ms wait before the first Apache response. I thought to myself oh man, I’m just going to go delete the post. And then, now, it’s back to “normal”. Very odd! But, either way - something is going on with this delay in the first item loading. I forget what the web optimization sites call it - time-to-first-load or something like that? time-to-first-response?
Once the first response comes in, then yes there is a roughly linear relationship between loading 25 items vs. 50 items vs. 100 - 50 is double 25, 100 is double 50.
The page size there is rather high… I suppose that’s probably the embedded JSON-LD that’s driving up the size here. You could try disabling that in Settings (if you’re on the latest version of S).
The time all being in “waiting” is pretty normal for Omeka sites or really anything database-intensive that uses traditional server-side rendering… the delay is all in waiting for the queries to complete. 4.4 seconds is still quite high. It’s more common today to see sites built to load the shell of the page first then issue a request for the data which would indeed improve the first-load time but you still wouldn’t have any useful contents until basically the same time.
1 Like
For some context, my simple localhost install running on a laptop has 30,000 items and a request to the items browse page (with a page limit of 25) takes about half a second to respond. A page limit of 1 is about 300 milliseconds, establishing more or less the floor on this setup of just assembling the page and performing the necessary queries for the user session and retrieving the list of (1) items. Obviously I’m getting some gains by removing network latency but that’s really irrelevant in the face of the times you’re talking about.
If your “floor” is really in the multiple seconds something is definitely problematic here. My usual guess for the culprit would be the base query to get the items, but it could be something (or things) else that’s running all the time. You can turn on logging of queries to see what’s happening… it might also help to know what modules you’re using.
John, after some tweaks and service restarts, I’m down to <1 sec before response (so, query execution).
This is the first open-source platform I’ve used that primarily uses InnoDB (as opposed to MyISAM).
I think the key difference was this one database configuration setting:
innodb_buffer_pool_size : this is the #1 setting to look at for any installation using InnoDB. The buffer pool is where data and indexes are cached: having it as large as possible will ensure you use memory and not disks for most read operations. Typical values are 5-6GB (8GB RAM), 20-25GB (32GB RAM), 100-120GB (128GB RAM).
It was set initially to 1024M. When I set it to 2048M, didn’t seem to change too much. But when I changed it to 4096M, basically reduced query time by 80% (from 5 sec to 1 sec).
Keyword search is still slow, but at least pagination is “normal” speed. We can live with search being slow, but not browse!
Also thanks for the note about JSON-LD (also not familiar with that being part of open-source content management platforms like Wordpress, Drupal, Joomla, OpenCart, etc.). Aside from disabling that, I’d also love to see a system setting (as opposed to a plugin) that disables images on the internal admin item browsing.
2 Likes