Welcome to the Question2Answer Q&A. There's also a demo if you just want to try it out.
+1 vote
1.1k views
in Q2A Core by
edited by

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. 
Q2A version: V1.5 -> 1.5.1

1 Answer

+1 vote
by
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.
by
+1
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.
by
+1
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...
...