That's about it ... cept think I'd test first .... IF one has command line access to both servers, that is.
On the DB server:
Same grant for server/user etc. but change the FQDN of the web server to it's IP address.
Then turn off networking in the DB config ... that allows access by IP and won't be doing a DNS check each and every query the web server makes. If I re-call correctly that line is 'skip_networking' in the MySQL cnf file (might want to Google that). Any change there requires restart of DB service.
On the web server - use the mysql client and test connectivity:
mysql -h [IP address] - u [username] p[password] [ENTER]
Connected? Great .. now the next test ... query some tables .. the users and the larger log tables.
At the mysql> prompt on the connected client of the web server:
select * from mdl_user; [ENTER]
That will display all users with all columns ... what you are interested in is the seconds it takes to make that query.
Another query
select * from mdl_logstore_standard_log; [ENTER]
That table is one of the largest and think that's the one queried when in Moodle Admin clicking logs.
Again, lots of data ... pay attention to seconds.
You could do the same test on the DB server itself. Should see a slight different in how long the queries took - slightly longer query coming from web server. Faster when using DB server client.
IF it's significantly different then you might want to think this. Could be your need for speed could be solved by tuning the MySQL server on the Web server.
Seem OK? Well then make the changes to the config file of Moodle
On the config.php file ... think I'd copy the lines about DB, paste them back in, and comment out those lines that applied to the localhost (DB sever on the Web host) leaving the dedicated DB server info active. For reference or for quicking switching back if it doesn't work out for ya. When you edit config.php file there is no need to restart any service ... just hit the site.
Obviously, IF successful and you decide it's better on the dedicated DB server, shut down the MySQL on the Web server. *think I'd leave the DB there, just in case*.
That could free up some memory on the web server allowing you to launch more apaches on boot up ... (don't think that was the problem, with just 100 concurrent users, BTW).
Also strongly suggest (if you can) installing and using MySQLTuner for testing and tweaking the DB server. Right out of the shrink wrap MySQL DB server using the default cnf might not be enough. Also, MySQL provides some sample cnf files ... might want to take a gander at those - they are off in /usr/share/ some place (on CentOS/RHEL systems), IF I re-call correctly.
'spirit of sharing', Ken