Welcome to the Question2Answer Q&A. There's also a demo if you just want to try it out.
+2 votes
in Q2A Core by
My site contains more than 450,000 questions
When asking a new question takes a lot of time is it because the database is large and is there a solution to speed up asking the questions
Q2A version: 1.8
I don't think it is related to a "large database" but rather to some plugin, theme customization or core hack that is slowing it down. Not to mention hosting, of course
I noticed that this plugin very slows down the site in versions q2a 1.8. After the removal of this plugin, the site normally fast openend.
The issue with that plugin was already reported. This happened in Q2A version 1.7 for me. The exact reason was an image creation function call causing memory leak.

3 Answers

+1 vote
I had this problem the solution is more RAM. or talk to your users and start over.
i have Ram 4 my site use % 25 Just
@islam afify, is this dedicated server only for your site? how  many CPU? are you using SSD? what is version of php and mysql? 4GB RAM may be good, but depends on how much traffic you get and how much utilization. what are the plugins you are using other than default.

all these factors can contribute to slow down your site.

List details here or PM me, I may be able help you.
I have installed another site on the same server and the questions are asked quickly so the problem is not in the server
Have u cloned your site or installed fresh q2a?
Just copy the files and install a new database
If you try to use the database for the primary site the same problem occurs in the new site
I assume you installed exact same plugins that are on primary site, including ads and other scripts.

Which hosting provider you are using?

I recommend you to clone same site and enable q2a debug performance, this flag is in qa-config.php file(QA_DEBUG_PERFORMANCE, true)

then share new site, will see what is causing issue.
There is no difference between them

But note something important

Asking questions is very quick if you use moderation
It is slow when the question is accepted
what does that mean?
edited by
How about measuring the time of post processing?

For example ...

Source: qa-include/app/post-create.php (about L70 ?)

Code for measuring:

$debug_time = array();
$debug_time[] = microtime(true);
qa_post_index($postid, 'Q', $postid, @$followanswer['postid'], $title, $content, $format, $text, $tagstring, $categoryid);
$debug_time[] = microtime(true);
$debug_time[] = microtime(true);
qa_db_points_update_ifuser($userid, 'qposts');
$debug_time[] = microtime(true);  // !!! Added !!!
for($i=0; $i < (count($debug_time)-1); $i++) {
    echo "{$i} processing time: ";
    echo ($debug_time[$i+1] - $debug_time[$i]) . "seconds<br>";
0 processing time: 0.010718822479248seconds
1 processing time: 8.3870871067047seconds
I updated "Code for measuring".

$debug_time[] = microtime(true);  // !!! Added !!!

Re-try it.
0 processing time: 0.015072107315063seconds
1 processing time: 6.4552569389343seconds
2 processing time: 0.021444082260132seconds
If you set true to the QA_DEBUG_PERFORMANCE in the config.php, is there a particularly slow query?

 For example, what is the processing time of the query below?

INSERT INTO qa_userpoints (?????.'points) VALUES ('?????') '.
                'ON DUPLICATE KEY UPDATE '????points=????+bonus
It is statistical information. Query logs is in the different location in the debug panel.
There is another thing to try. Is the performance improved by returning to 1.7.5? If so, a fatal performance problem may be in V1.8.
That's right. Is there a particularly slow query in that?
Of course, it must be a log when asking a question.
It is a log of the question page after redirection. Comment out redirect process below. As a result, question page will not be shown after asking question.

qa-include/pages/ask.php (around L171)
qa_redirect(qa_q_request($questionid, $in['title'])); // our work is done here
//qa_redirect(qa_q_request($questionid, $in['title'])); // our work is done here
+1 vote

To islam afify

Since other users will trouble by email, let's discuss in the new (this) answer section.

OK. There is no problem as long as that record count. It may be caused by MySQL setting. Above tool may be useful. When searching qa_posts table, MySQL may be running out of memory.
Thank you for your help
I've tired you a lot
I wish for good luck.
You have deleted the qa_posts table
The question is quickly asked. I think the problem is the number of big questions
+2 votes

The cache update queries are slow because the indexes are not properly tuned. This has already been discussed and I have explained it here.

Create the following indexes:

CREATE INDEX `test_index_1` ON `qa_posts`(`type`, `acount`, `closedbyid`);
CREATE INDEX `test_index_2` ON `qa_posts`(`type`, `selchildid`, `closedbyid`);
CREATE INDEX `test_index_3` ON `qa_posts`(`type`, `amaxvote`, `closedbyid`);

Try again and report back the results. Currently:

cache_unaqcount: 2347.10 ms
cache_unselqcount: 2699.90 ms
cache_unupaqcount: 2103.15 ms

If you are a purist and don't want those changes you can remove them with:

DROP INDEX `test_index_1` ON `qa_posts`;
DROP INDEX `test_index_2` ON `qa_posts`;
DROP INDEX `test_index_3` ON `qa_posts`;

edited by
Main points of your reports:

Variables to adjust:
    query_cache_size (=0)
    query_cache_type (=0)
    query_cache_limit (> 1M, or use smaller result sets)
    thread_cache_size (start at 4)
    performance_schema = ON enable PFS
    innodb_buffer_pool_size (>= 1G) if possible.
    innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
    innodb_buffer_pool_instances (=1)

What is "innodb_buffer_pool_size" setting of your MySQL? If it is the default 128 MB, it must allocate 1 GB or more.
I did all the recommendations but nothing changed
Have you restarted MySQL server?
Yes, I also used MySQLTuner again and there are no recommendations