How to interprete MySQL profile output for tuning external MySQL server

I have recently upgraded a Drupal site to multi-webhead environment and am trying to tune MySQL with InnoDB engine. I notice SELECT queries are faster on production than on staging, but UPDATE queries are slower on production.

• Staging: On a virtual machine with LAMP stack on it.
• Production: Double webheads with load balancer. Dedicated MySQL server and a second hot stand-by DB server.

My system admin tells me that the latency is due to 1) remote DB connection and 2) binary logging for data replication between two DB ser开发者_StackOverflowvers.

I am new to InnoDB and multi-server environment. I'd like to see if the output from MySQL profile confirms my server settings, or if there is any more room for further optimization of production MySQL server.

This is what I ran from staging and production databases. I modified the output with number columns side by side for comparison. Note that the query runs faster on production on every rows in the table except one with status "end". Is "end" phase where binary logging is performed?

mysql> SET profiling = 1;
mysql> UPDATE node SET created = created + 1 WHERE nid = 100;
mysql> SHOW profile;
+----------------------+----------+------------+
| Status               | Staging  | Production |
+----------------------+----------+------------+
| starting             | 0.000100 | 0.000037   |
| checking permissions | 0.000014 | 0.000006   |
| Opening tables       | 0.000042 | 0.000017   |
| System lock          | 0.000007 | 0.000004   |
| Table lock           | 0.000009 | 0.000003   |
| init                 | 0.000076 | 0.000030   |
| Updating             | 0.000062 | 0.000022   |
| end                  | 0.000031 | 0.002159   |
| query end            | 0.000006 | 0.000003   |
| freeing items        | 0.000010 | 0.000003   |
| closing tables       | 0.000009 | 0.000002   |
| logging slow query   | 0.000005 | 0.000001   |
| cleaning up          | 0.000004 | 0.000001   |
+----------------------+----------+------------+
| Total                | 0.000385 | 0.002288   |
+----------------------+----------+------------+

You're on the money. The "end" state will include binary logging.

For the end state, the following operations could be happening:

• Removing query cache entries after data in a table is changed
• Writing an event to the binary log
• Freeing memory buffers, including for blobs

http://dev.mysql.com/doc/refman/5.5/en/general-thread-states.html