Note:This article pertains to the CodePlex SDK initially released late 2009. The Windows Azure team has since then released a newer version of the Azure SDK for PHP on Github. Please refer to the Windows Azure PHP Developer Center for documentation on this more recent version of the SDK.
Please stay tuned and come back here regularly as we are working on refreshing the tutorials to deliver up to date and useful content for our PHP developers.
This is a short post to share the results of a little investigation I did that was inspired by comments on a post I wrote about using SQL Azure for handling session data. The comment was by someone reporting that SQL Azure seemed to be faster than Azure Table Storage for handling session data. My experiments show that SQL Azure and Table Storage have very similar performance when doing single writes (YMMV), so I can't verify or refute the claim. However, I got to wondering which is faster for inserting and retrieving many "rows" of data. I know that Table Storage is supposed to be faster, but I wondered how much faster. So I wrote a two-part PHP script that does the following:
- Connects to SQL Azure.
- Inserts 100 rows to an existing database.
- Retrieves the 100 rows.
Here's the code:
Note: The code above uses the SQL Server Driver for PHP to connect to SQL Azure.
The second part of the script does the equivalent for Table Storage:
- Connects to Azure Storage.
- Inserts 100 entities to an existing table.
- Retrieves the 100 entities.
Here's the code:
Note: The code above uses the Windows Azure SDK for PHP to connect to Azure Storage.
The result of the test was that Table Storage was consistently 4 to 5 times faster than SQL Azure (again, YMMV). The key, however, was to use the $tableStorageClient->startBatch() and $batch->commit() methods with Table Storage. Without using batches, Table Storage opens and closes a new HTTP connection for each write, which results in slower performance than SQL Azure (which keeps a connection open for writes). When using batches with Table Storage, the connection is kept open for all writes.
Note: Many thanks to Maarten Balliauw who, when I was perplexed about the results of my tests without batching (I expected Table Storage to be faster, but because I didn't know about batches for Table Storage, I was not getting the results I expected), suggested I try batching.
The complete script (with set up/tear down of database and Table) is attached in case you want to try for yourself.