Currently all MySQL data/API calls are handled by a remote DB cluster (i.e. network latency is a factor in total script execution time).
To reduce execution time in this context, would it be sensible to run a local MySQL instance on each app server to handle mysql_real_escape_string API calls? Has anybody ever done this?
What you think you want to do isn't what you want to do.
A call to mysql_real_escape_string doesn't actually send anything to the server (this can be confirmed by looking at tcpdump output). All that call needs a current connection for is to determine the character set used (and hence what might need to be quoted).
By running mysql_real_escape_string on anything other than your real, live, actual database, you're not improving performance at all, and you're running the risk that the connection configuration won't be the same, opening you up to all sorts of potential risks.
You'd be making out of process calls across a TCP connection, even though it's to localhost. In addition, you'll use additional memory for the mysql process and add complexity to your code.
A better method would be to find a function that duplicates the functionality of mysql_real_escape_string without using mysql. You do have to make sure that this function works exactly as mysql_real_escape_string does or you could open yourself to security problems.
I'd also ask whether you should be reconsidering your design if your script is making so many string escaping calls that it's become significant. How have you discovered that these calls are the problem? Have you profiled your code? If you haven't, you could well be barking up the wrong tree.
I've never had the need to do it, but it seems like a perfectly reasonable thing to do.
I would be very careful that your local mysqld versions and configuration match each other as well as the real server as a mismatch might cause very interesting problems.
