Poor Google Cloud SQL performance

Question

It's hard for me to perform decent actions with Google Cloud SQL, I do some pretty simple CRUD operations, for example:

public BaseUser getUser(String token) throws SQLException{ Connection conn = DriverManager.getConnection(JDBC_CON_STRING); PreparedStatement ps = conn.prepareStatement(GET_USER_BY_TOKEN_QUERY); ps.setString(1, token); ResultSet rs = ps.executeQuery(); List<BaseUser> users = inflateUser(rs); if(users.size() == 0){ return null; } if(users.size() > 1){ logger.info("DATABASE MAY BE CORRUPTED, THERE MORE THAN 1 USER WITH THE SAME TOKEN"); } ps.close(); rs.close(); conn.close(); return users.get(0); } 

And getting an average response time of 450 ms for each request. + = 150 for openConnection, 150 for work, 150 for closing. See Img. below.

I read google documentation, forums and some blogs and still can't figure out what I'm doing wrong (I have to do something wrong, 450 ms / request is a lot suitable ...)

UPDATE 1: I finally chose the SQL cloud cloud problem, I installed my own local MySQL server, and I have better improvements (80 ms for “insert or update”, then finally select commit.), Hope I can get some tips from google dev. team, I really like the whole Google cloud platform, but it’s just impossible to work with this level of latency = (

UPDATE 2: 2014/05/06 The delay problem is the same as D0 or D16. Trying to insert 10,000 rows (3 varchar and ~ 100bytes blob) takes 32 seconds from the Google ComputeEngine VM due to latency. The duration is the same with 10,000 inserts and one package insert. If I use 64 threads then the duration is up to 3 seconds. I tested using my own mysql jdbc driver.

Any suggestions? Thanks!

Answer 1

Try using the MySQL Connector / J driver in AppEngine, it can improve performance. See https://developers.google.com/appengine/docs/java/cloud-sql/#Java_Connect_to_your_database for the use of the class name and URL.

Rob

Answer 2

I had a problem with GAE + cloud SQL used with php and socket.

The problem was my query, which actually used 3 queries and read thousands of lines, even hard ones, only output a couple.

I found it with HeidiSQL and put EXPLAIN before the select query.

I had to make a connection on the php side so that the load time (checked in chrome devtools, not mysql runtime) of this set of requests fell from 600 ms to 151 ms