Performance of MYSQL (qa_options table query)

Question

I install V1.5. And after, upgrade 1.5.1.

I enable QA_DEBUG_PERFORMANCE.

Although it was high-speed immediately after installing, while carrying out initial setting, performance worsened sharply. It seems that degradation of performance has a cause in the query of qa-options table. Also, differing from the query sentence immediately after installation feels me strange. Is some added plug-in the causes? 

below is output of DEBUGGER. (NOW)

---

SELECT title, content FROM qa_options

99.58 ms - 354 rows - 2 columns

 

below is output of DEBUGGER. (1.5.1 installed)

---

(SELECT 'options' AS selectkey, title, content FROM qa2_options) UNION ALL (SELECT 'time', 'db_time', UNIX_TIMESTAMP(NOW()))

1.89 ms - 176 rows - 3 columns

 

It does not become a low speed when the same SQL is made to process by mysqladmin. The database exists in the same hardware as Web server. 

Moreover, my server is managed-dedicated server. Performance is not improved even if it reduces the record of qa-options. 

Answer 1

It seems that query results of qa-options table is not cached if the capacity of qa-options records exceeds query_cache_limit of MySQL. In my server, query_cache_limit was 1 M byte. It solved by deleting the record related to FAQ plugin. If dedicated server, enlarging query_cache_limit may also be solved.

Comments

Thanks - well spotted. In general the qa_options table should not be used for large pieces of content, since it is retrieved in full for every request that Q2A processes. Instead, the qa_blobs table should be used for those.

---

Thank you gideon.
Much plug-in is using the qa-options table.  Since qa-options table is cached by the beginning of all page processings at memory, I am worried that it may have influence on the whole Q2A performance...