ElkArte Community Modern, Free, Powerful
Community building forum software

Quote from: Joshua Dickerson – January 12, 2016, 02:37:00 pmLet us know if there is anything we can do to make it easier (besides writing a custom importer).

Quote from: Joshua Dickerson – January 16, 2016, 11:55:07 pmCache enabled?

Quote from: kode54 – January 17, 2016, 12:42:31 amI haven't run into any extended loading on Hydrogenaudio, other than caching new style sheets or scripts if changes were made server side. Currently using the opcache module, and PECL Memcached module with memcached running with a 64MB buffer. Maybe it would help me to know what exactly the caching serves to buffer for the loading.

I'm also using database sessions, which was pulling up some errors before, because of some malformed code that assumed that $db->insert returned a value. Oh crud, that reminds me, that's more code I need to make a pull request for. E: Never mind, development already does it even better than I did, so I've pulled the changes from development into my release version.

Quote from: emanuele – January 17, 2016, 08:24:12 amDo you have the option to minify js and css on?
It doesn't sound like that, but worth a try.

Quote from: emanuele – January 17, 2016, 10:24:55 amI split up the discussion for better organization.

The reason for loading the messages is for the "recent activity" tab in the profile summary.
It's a kind of "stop gap", the content of the tab is meant to be loaded via ajax, though for the time being has been put in-line.

The query is rather slow, and in some cases is even repeated twice (one time with a limit to reduce the table scan and if it doesn't find enough entries is repeated without the limiting condition).
Actually this may even be one of the reasons.

Since you are using a testing forum, would you mind adding:

Code: [Select]

$db_show_debug = true;

to your Settings.php?
Then open the profile page and take a look to the queries at the end of the page, see if there is one or two that start with:

Code: [Select]

			SELECT
				b.id_board, b.name AS bname,
				c.id_cat, c.name AS cname,
				m.id_topic, m.id_msg, m.body, m.smileys_enabled, m.subject, m.poster_time, m.approved,
				t.id_member_started, t.id_first_msg, t.id_last_msg

Thanks!

Quote from: Joshua Dickerson – January 17, 2016, 12:44:08 pmI don't see any reason why it is taking that long. Those joins can be left or inner and be fine either way. Filesort/temp table on a table with 162 rows is nothing. That can actually just be a MySQL optimization.

I think this is grasping at straws, but can you try this query on its own:

Code: [Select]

SELECT
  m.id_topic, m.id_msg, m.body, m.smileys_enabled, m.subject, m.poster_time, m.approved,
  t.id_member_started, t.id_first_msg, t.id_last_msg
  b.id_board, b.name AS bname,
  c.id_cat, c.name AS cname,
FROM fmf_messages AS m
  LEFT JOIN fmf_topics AS t ON (t.id_topic = m.id_topic)
  LEFT JOIN fmf_boards AS b ON (b.id_board = t.id_board)
  LEFT JOIN fmf_categories AS c ON (c.id_cat = b.id_cat)
WHERE m.id_member = 1
ORDER BY m.id_msg DESC
LIMIT 0, 10

Can you keep browsing your forum and keep trying to reproduce it to make sure it is that query. It might be another query that locks the tables and you're just getting the effect on that query.