MySQL overhead of calling a Stored Procedure
Percona wrote up a nice article MySQL Prepared Statements explaining pros and cons


  So there are good reasons to use prepared statements:
  
  
  Save on query parsing
  Save on data conversion and copying
  Avoid SQL Injection
  Save memory on handling blobs
  
  
  There are also drawbacks and chewats of using prepared statements:
  
  
  Query cache does not work
  Extra server round trip required if statement used only once
  Not all statements can be prepared. So you can’t use prepared API exclusively you’ll need to fall back to normal API for some statements
  Newer and sometimes buggy code. I had a lot of problems with PHP prepared statements. It is getting better but still it is less mature than standard API
  You can’t use placeholders in place of all identifiers. For example you can’t use them for table name. In certain version it even does not work for LIMIT boundaries
  Inconvenient list handling. Unlike in for example PEAR emulated
  prepared statements there is no nice way to pass list of values to IN
  Harder tracing. Logs were now fixed to include full statement text not
  only “Execute” but in SHOW INNODB STATUS you would still see
  statements without actual values – quite inconvenient for analyses
  


Since what you are experiencing is the expected behavior, you should not use Prepare Statements. You are making many calls to execute a single command. If you simply ran this

stmt = conn.createStatement();
rs = stmt.executeQuery("call sp_one('a','b')");


the complete parsing of the SQL, preparing for execution, and the parameters already being passed in through the SQL statement are all done on the server side with one call.

Please read that Percona blog for more details.