Welcome to the Question2Answer Q&A. There's also a demo if you just want to try it out.
+6 votes
in Q2A Core by
A system which has 64 GB RAM, 30 GB RAM is still free, but, the system slows down with 5000 simaltaneous users.

I suspect that, this could be because of complex queries created by the Q2A framework. which might be loading the system.

Do we have any benchmarks of maximum users on the system?

2 Answers

+5 votes

Gideon stated here that Q2A has been tested with hundreds of thousands of posts and users. However I'm not sure if it's been specifically "stress tested" with many users at once.

If you're able to do some testing and profiling yourself, let me know of any specific queries or functions that can be improved.

You mention "complex queries" - there is the option in qa-config.php to optimise for a local database (if MySQL runs on the same server). That simplifies the queries greatly.

Make sure to check which queries are slow, they could be from plugins.

By the way there are some big optimisations coming in v1.8. Depending on certain setting you could see page load times 3x faster. And there will be caching, to lighten the load even more.

Wow thats great, when will v.1.8  will come???
exited ... :)
Caching sounds great. Hope it is not breaking plugins.

And thanks for pointing out the qa-config option "QA_OPTIMIZE_LOCAL_DB". However, how to determine if both "run on the same box"?
+1 vote
I got 400 000 requests yesterday on my shared hosting and the provider told me I should improve my scripts or they shut the script down.

I checked the script by using the debug option (see qa-config.php) and found out that one of my old plugins was the "bad boy". So I quickly fixed that.

Before I had a mysql execution time on the live server of 120 ms, which is now down on 20 ms.

By math I would say:

Before: 400 000 requests * 120 ms = 48 000 000

Now: 48 000 000 / 20 ms = 2 400 000 possible requests.

I mean, this is an assumption and probably will be incorrect sine PHP isusing 50 % of the load time... but you get an idea.
Out of interest, do you know roughly how many of your requests are logged in users vs not logged in?
Just a tiny bit of logged-in users. Defenitely less than 1 %.