MySQL Persistent Connections

Persistent Connections is a property of the connector and is used if it is set up.  It is otherwise invisible to the user.  Most MySQL servers will be idling at only 10 or 15 connections per second.

http://php.net/manual/en/mysqli.quickstart.connections.php

A process that hits MySQL 10-15 times a second? Why on earth do you need to hit it that many times?

1. If it's the same process, you don't need to do anything special - just make a connection and keep querying.

2. If you're trying to poll the database for new information, you might want to consider using triggers / UDFs to execute scripts at the correct times instead of polling:
http://www.mysqludf.org/

That way, nothing runs until the database actually HAS a change and it will fire a script at exactly the right time.

Otherwise, all your polling could negatively impact the database's ability to handle the rest of the normal traffic.

it's a google cloud SQL database. Google sent me some docs on the google proxy so I think that will do the same thing.

I'm less in agreement that 15 connections per second is nothing, and I'm not quite certain by the wording so far whether you're talking about 15 queries per second or 15 individual connections. When you execute a PHP script, it's starting a single process for running that code, and that one process can make a single connection to the database and then perform multiple queries over that one connection.

Fifteen connections from a single process usually either means disconnecting and reconnecting (which is not likely what you're trying to do, since the disconnection, re-connection, and authentication alone would likely take more than 100 milliseconds), OR it can mean async processing with multiple connections.

Fifteen connections / second is pretty bad, in my opinion. It means you're sucking up 15 connections that could otherwise be available for other users/processes, and it gets you that much closer to the max connection limit.

Fifteen queries per second over one connection is different, though. It's still bad, in my opinion, but it honestly depends on what you're doing with each query. What tables you're querying, table types, table sizes, indexes, concurrent other activity, query caching, etc... all play a factor here. In addition, unless every query returns in less than ~50 or so milliseconds, you might not be able to achieve 15 queries per second with a single process.

Overall, 15 queries per second for polling purposes is usually the start of bad long-term performance. Polling databases is usually bad news unless you're doing it infrequently (e.g. once every 15 seconds is still pretty quick in terms of reaction time).

And I also second the idea that persistent connections are bad, and upvote Ray's link to the wiki page that talks about why.

Confirmed with google the google proxy makes a direct connection so that should be my solution. Still have to set it up.

I think you're talking about Cloud SQL Proxy, and yes, it makes a direct connection to the database, but it's more of a layer in front of the same code... if your code is sitting remotely outside of Google's cloud, then you still have to connect to the proxy from the remote code. I don't understand how the proxy would change the original question...

I interpret the "15" in this question to mean something like "Fifteen hits per second to my web site, each with a need to talk to MySQL."  It might make sense, if the site is mostly read and less write, to use a cache.  This can offload MySQL work.  If that's not the correct interpretation, please tell us some more about this app.

I ended up creating a process to send the jobs out to 3 servers to lesson the load. All appears to be ok now.