I maintain a custom built CMS-like application.
Whenever a document is submitted, several tasks are performed that can be roughly grouped into the following categori
Scaling out Web Servers is not going to make MySQL budge one inch when it comes to accessing Multicore CPUs. Why? First consider the two main Storage Engines of MySQL
This storage engine does not access multiple cores. It never has and never will. It does full table locking for each INSERT, UPDATE, and DELETE. Sending queries from multiple Web Servers to do anything with a MyISAM just gets bottlenecked.
Prior to MySQL 5.1.38, this storage engine has accessed only one CPU. You had to do strange things like run MySQL multiple times on one machine to coerce the cores to handle different instances of MySQL. Then, have the Web Servers' DB connections load balanced among the multiple instances. That's old school (especially if you are using versions of MySQL before MySQl 5.1.38).
Starting with MySQL 5.1.38, you install the new InnoDB Plugin. It has features that you have to tune for getting InnoDB to access multiple CPUs. I have written about this in the DBA StackExchange
Sep 20, 2011 : Multi cores and MySQL PerformanceSep 12, 2011 : Possible to make MySQL use more than one core?May 26, 2011 : About single threaded versus multithreaded databases performanceThose new features are fully available in MySQL 5.5/5.6 and Percona Server as well.
If your custom CMS uses FULLTEXT indexing/searching, you should upgrade to MySQL 5.6 because InnoDB now supports FULLTEXT indexing/searching.
Installing to MySQL 5.6 is not going to automatically make the CPUs get going. You will have to tune it because, LEFT UNCONFIGURED, it is possible for older versions of MySQL to outrun and outgun newer versions:
Nov 24, 2011 : Why mysql 5.5 slower than 5.1 (linux,using mysqlslap)Oct 05, 2011 : Query runs a long time in some newer MySQL versionsJun 19, 2011 : How do I properly perform a MySQL bake-off?