Correct me if I'm wrong, when a user requests a page from your system, a connection to the database is opened, the queries that are required are made, the page is displayed and the connection is closed. This operation takes, say, 2 seconds. The user can be reading your page, say 10 minutes.
If your database accepts 3 simultaneous connections, you can serve 3 connections every 2 seconds or 90 connections per minute.
But even though 90 users are reading your page at the same time they are not simultaneous connections, because the page in question is already in the client .
If at the same time 5 clients arrived to request the page, and your database server accepts 3 simultaneous connections, two of those clients would wait 2 seconds to see your page. If you raise the MySQL limit to 5, then you could serve 150 pages every minute.
Obviously, the more open connections you allow, the more resources your system consumes.
The solution is to use temporary memories, cache , the queries of your database and the pages generated by PHP. This cache, let's say it reduces the response time to 1/2 second.
Now we go to your http server. If your server accepts 50 clients simultaneously, serving cached pages in 1/2, it can serve 100 simultaneous pages per second .
But it's the same, open a connection, serve the page and close ... no simultaneous users .
This changes if you use websockets, but do not indicate it in your question.
Answer
Apache has a program called ab that serves to make stress tests or benchmarking . It shows the number of requests per second your Apache server can serve, although I think it works for any server, because it does the tests under the http protocol.
It is used like this:
ab -n 200 -c 20 http://example.com
With this you generate 100 requests in 20 threads, to verify the concurrency. In this page of genbeta: dev you can see an example.
Recommendations
Unless you know for certain that your system has very high memory requirements, you should consider optimizing your code, using cache and optimizing your servers before thinking about scaling your servers. A badly programmed and / or poorly optimized system will have poor performance on a server with 1 GB or 224 Gb.