Google I_O_Talk_Speed_TracerAttended my first Google I/O this year and truth be told I wasnt sure what to expect. My goal was to learn a bit more of Architecture, performance, and HTM 5. Looking back at day 1, I came away feeling good that I actually made it to the event given that I felt like just heading into work.
These are my notes for the first day. The below were the talks I chose to attend and created a quick PowerPoint Deck for a portalble version of the notes.
My Schedule:
1. Measure in milliseconds redux: Meet Speed Tracer [ My Notes: Powerpoint Deck Download ]
2. Beyond JavaScript: programming the web with native code
3. Architecting for performance with GWT
4. Developing With HTML5
5. GWT Linkers target HTML5 Web Workers, Chrome Extensions, and more
Stay tuned for tomorrows deck.
I started to get the HTML5 itch a few weeks ago so I started to look around the web to feed my appetite for all things HTML 5. Turns out info is pretty hard to come by. Not sure when your reading this but its been tough to find adequate examples of what IS and what ISNT implemented yet since it all depends on the browser your using. Anyway. So im going to jot down my notes on using HTML5’s Web Database here by creating a few examples.
Quick Agenda
1. What is HTML 5.
2. What you need to get started.
3. The tool to view the DB
4. How to create AND connect to a DB.
5. How to create a table.
6. How to insert/update/delete records into a table.
7. How to list records in a table.
Let get the ball rollin’ now…buhahah
What is HTML 5.
HTML 5 is a collection of new tags, (list here) and along with the new tags it provides a tool set to store data on the user’s machine using javascript, yes Javascript (Web database API here).
What you need to get started.
For the example you’ll need at least Chrome 4. Of course you can use any browser you wish but YOU NEED TO BE SURE HTML 5 WEB DATABASE IS SUPPORTED.. I strongly recommend you download and install Google’s Chrome browser, so far it’s great. Click here for download link.
Thats all you need, oh! and you’ll need some HTML and Javascript know-how.

Figure 1.0 - Chrome Developer Tools
The tools
If you don’t have Chrome installed skip this section. This section will show the visual tool Chrome supplies developers to view not only the database but other neat things about your page.
Load the web page your going to test on. In my case its http://localhost then click on the “Control Page” document icon on the far-top-right corner of your browser . Select Developer > Developer Tools. (Figure 1.0)
You should now see a window as shown in Figure 1.2 (minus the DB). If you do not see the information displayed on Figure 1.2 click on “Storage” on the top menu. The “Storage” window contains a nice little DATABASE list on the left along with other items specific to that page. At the moment there’s no databases so you wont see anything. This is just the place where you’ll be able to work with the DB
How to create AND connect to the DB
Let’s create a database. Our database will have the name, “test_database” and will be our initial 1.0 version. (Note: the database name is case sensitive)
dbObj = null;
function connectToDB(){
dbObj = openDatabase('test_database', '1.0',
'Test Database', 1024*1024*3);
}
connectToDB();
1. openDatabase(’name of db’, ‘version’, ‘database description’, total bits table will use, call back function)
The callback function is used to create the table structure if present. In this example we’ll create the tables later. Also note that the size of the database is dependent on the amount of free space the user has available.

Figure 1.2 Developer Tool Database
It is also recommended that the site only take up to 5 mbs of space. The spec also mentions the user will be prompted when the site requests additional space. (
quote)
Once you run the above javascript on your sandbox, pull up the Chrome Developer tool, you should now see the database (Figure 1.2)
How to create a table.
Were going to add a table. We’re going open a connection to the database again as shown in the first example and then use the SQLTransation object to execute a CREATE statement.
dbObj = null;
function connectToDB()
{
dbObj = openDatabase('test_database', '1.0',
'Test Database', 1024*1024*3);
}
connectToDB();
//Create the table method
createTable = function()
{
dbObj.transaction(function(SQLTransaction){
SQLTransaction.executeSql(
"CREATE TABLE userinfo (id INTEGER PRIMARY KEY, item1 TEXT)", [],
function(){ alert('I am a successfull callback function!'); },
function(){ alert('Oh no! I am a sad error callback function'); } );
});
}
createTable();
Copy the above javascript, place into your file, and refresh the page. You will now have the table ‘userinfo’ in our database. If you want to add more tables simple call the method once more with a different CREATE statement. (Figure 1.3).
Some explaining…
SQLTransaction has 2 methods, transaction() (Read/Write) and readTransaction() (Read only). We use the transaction method when we need to read AND write. The readTransaction() has only ‘read only’ functionality and best used for SELECT SQL statements.
To execute the SQL statements we use the executeSql() method. A parameter explanation is shown below.
executeSql(’SQL Statement’, [], success callback function, error callback function) . The [] contains values for each ? used within the SQL statement. “INSERT INTO userinfo (item1) VALUES (?)” will replace the ? with the the content to save for the specific column. It’s also recommended to use this feature to code against SQL Injection attacks. (quote)
How to insert/update/delete records into the DB
At this point UPDATE, INSERT, as well as DELETE statements use the same process as the previous example. We use the SQLTransaction.transaction() method as well as the executeSql() method.
The next example will insert a record into our database table, ‘userinfo’, and we’ll verify the data entered using the Chrome Developer tool. Please note that the below code assumes you already created the table.
dbObj = null;
function connectToDB()
{
dbObj = openDatabase('test_database', '1.0',
'Test Database', 1024*1024*3);
}
connectToDB();
//Insert record into Table.
insertRecord = function(item1)
{
dbObj.transaction(function(SQLTransaction){
SQLTransaction.executeSql("INSERT INTO userinfo (item1) VALUES (?)", [item1],
function(){ alert('Record saved!'); },
function(){ alert('Uh Oh! record not save!'); } );
});
}
var item1 = "your not funny dude..really your not.";
insertRecord(item1);

Figure 1.3 - Verifying our record was inserted.
Pull up your Dev Tools Window again, expand the database by clicking the arrow, and click on the table. The record you just inserted will be displayed on the right as shown in Figure 1.3. Thats great but let’s now focus on retrieving the records to possibly manipulate the data!
How to List records
With data in our database, lets fetch the record we have in the table. To do so we use the read/write SQLTransaction method, readTransaction().
The following code assumes you have the database created, table created, and information stored in the table. If not go back and read the different sections.
dbObj = null;
function connectToDB()
{
dbObj = openDatabase('test_database', '1.0',
'Test Database', 1024*1024*3);
}
connectToDB();
fetchRecords = function(){
dbObj.readTransaction(function(SQLTransaction){
SQLTransaction.executeSql('SELECT id, item1 FROM userinfo', [],
function(SQLTransaction, data){
displayRecords(data); });
});
}
displayRecords = function(data){
var a = document.getElementById("text");
a.innerText = data.rows.item(0).item1;
}
fetchRecords();
In this example we query the table and display the results of the call. We use the SQLTransaction readTransaction() method, SQLTransaction executeSql() method passing in the SQL statement and a call back function displayRecords(). If the SQL SELECT statement successfully ran we pass a SQLResultSet object, ‘data’, to the displayRecords() method. The displayRecords() method fetches the HTMLElement node, ‘text’ and sets the text for the node to be the record fetched item1 value.
Fetching a specific value for a row.
To fetch the record we use the SQLResultSet object’s ‘rows’ attribute which returns a SQLResultSetRowList object. We then use the ‘item()’ method to fetch a specific row in the row list. In this case we fetch the first row and call the objects class property, ‘item1′. Note that each column in the table is represented but a class property.
Conclusion
We covered all the basic features of the HTML 5 web database. Inserting, creating a table, connecting to a DB, and fetching records. Give it a shot, if you have any questions feel free to leave a comment or refer to the W3C page
Armando Padilla
February 26th, 2010 in
PHP Development |
1 Comment
About 2 months ago I sat in on a PHP performance session at work taught by non other than Rasmus Lerdof. Aside from creating PHP he had some really neat stuff to talk about concerning performance. Most of the presentation came from the php.net site, talks.php.net. Take a look at the talks when you have some time.
The question
Anywho…that’s when my benchmarking and optimizing curiosity kicked in. It wasn’t until yet another talk at work concerning the benefits of an MVC framework (Symfony) that I started to think about Zend Framework and its performance out of the box (without caching). So I sat down today and started to benchmark the framework with a simple question in mind, “How does a simple ZF application compare to an application not using it?”
The applications
To answer the question I created 3 web projects. The first web project was a static-HTML only application which displayed “hello world” on the screen, very simple. (For those who just want to see the ab results click here as well as the Xdebug cachegrind output file.)
The second web project was a single PHP file with the below PHP code.
Listing 1.1 – Simple Hello world PHP
<?php echo "hello world"; ?>
The above 2 projects acted as my baselines. it would allow me to determine the overhead ZF introduced into the application.
Finally, the third web project was created using ZF’s Zend Tool and executing the below command.
Listing 1.2 – Zf Project Creation.
> zf create project helloworld_zf
Finally, I replaced the default index.phtml HTML with the simple PHP code shown in Listing 1.1.
Yes some may say that these examples are far too simple, but I wanted to test the Framework’s process to load and what better way to do this than with a very simple example. I also based it off the talk that was given comparing Symfony.
The Hardware & ab command
Here is the set-up.
1. Windows machine running Apache 2.2
2. PHP 5.2.9
3. Zend Framework 1.8.4
4. Pentium 4 3.20 GHz
5. 1Gbs of RAM
I used the Apache Benchmark, ‘ab’, tool which comes included with all Apache installation and ran the below command 3 times.
Listing 1.3
> ab -n 1000 -c 5 http://localhost/index.[html|php]
The results, for me, were very surprising. I have included all the ab outputs.
Observations
HTML ONLY – Reading 1
Concurrency Level: 5
Time taken for tests: 2.344 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 352000 bytes
HTML transferred: 83000 bytes
Requests per second: 426.67 [#/sec] (mean)
Time per request: 11.719 [ms] (mean)
Time per request: 2.344 [ms] (mean, across all concurrent requests)
Transfer rate: 146.67 [Kbytes/sec] received
HTML ONLY – Reading 2
Concurrency Level: 5
Time taken for tests: 2.375 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 352000 bytes
HTML transferred: 83000 bytes
Requests per second: 421.05 [#/sec] (mean)
Time per request: 11.875 [ms] (mean)
Time per request: 2.375 [ms] (mean, across all concurrent requests)
Transfer rate: 144.74 [Kbytes/sec] received
HTML ONLY – Reading 3
Concurrency Level: 5
Time taken for tests: 2.344 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 352000 bytes
HTML transferred: 83000 bytes
Requests per second: 426.67 [#/sec] (mean)
Time per request: 11.719 [ms] (mean)
Time per request: 2.344 [ms] (mean, across all concurrent requests)
Transfer rate: 146.67 [Kbytes/sec] received
Observations:
1. Roughly 0.0117 seconds per request.
2. Up to 424.79 requests satisfied per second.
Basic PHP – Reading 1
Concurrency Level: 5
Time taken for tests: 2.609 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 267000 bytes
HTML transferred: 81000 bytes
Requests per second: 383.23 [#/sec] (mean)
Time per request: 13.047 [ms] (mean)
Time per request: 2.609 [ms] (mean, across all concurrent requests)
Transfer rate: 99.93 [Kbytes/sec] received
Basic PHP – Reading 2
Concurrency Level: 5
Time taken for tests: 2.609 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 267000 bytes
HTML transferred: 81000 bytes
Requests per second: 383.23 [#/sec] (mean)
Time per request: 13.047 [ms] (mean)
Time per request: 2.609 [ms] (mean, across all concurrent requests)
Transfer rate: 99.93 [Kbytes/sec] received
Basic PHP – Reading 3
Concurrency Level: 5
Time taken for tests: 2.625 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 267000 bytes
HTML transferred: 81000 bytes
Requests per second: 380.95 [#/sec] (mean)
Time per request: 13.125 [ms] (mean)
Time per request: 2.625 [ms] (mean, across all concurrent requests)
Transfer rate: 99.33 [Kbytes/sec] received
Observations:
1. There seems to be a 100 request (roughly) drop when supporting PHP.
2. Requests per second satisfied = 382.47 (a drop of 42.32 requests or 9% drop)
3. Time per request = 13.073 or 0.0130 seconds per request (Increase of 11%)
Out of the box ZF 1.8.4 – Reading 1
Concurrency Level: 5
Time taken for tests: 68.297 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 197000 bytes
HTML transferred: 11000 bytes
Requests per second: 14.64 [#/sec] (mean)
Time per request: 341.484 [ms] (mean)
Time per request: 68.297 [ms] (mean, across a
Transfer rate: 2.82 [Kbytes/sec] received
Out of the box ZF 1.8.4 – Reading 2
Concurrency Level: 5
Time taken for tests: 70.281 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 197000 bytes
HTML transferred: 11000 bytes
Requests per second: 14.23 [#/sec] (mean)
Time per request: 351.406 [ms] (mean)
Time per request: 70.281 [ms] (mean, across all c
Transfer rate: 2.74 [Kbytes/sec] received
Out of the box ZF 1.8.4 – Reading 3
Concurrency Level: 5
Time taken for tests: 69.656 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 197000 bytes
HTML transferred: 11000 bytes
Requests per second: 14.36 [#/sec] (mean)
Time per request: 348.281 [ms] (mean)
Time per request: 69.656 [ms] (mean, across all c
Transfer rate: 2.76 [Kbytes/sec] received
Observations:
Framework not only has a slower response time but also satisfies less requests per second. Am I doing something wrong???? This cant be correct.
1. Request per second = 15.24 a change of 367.23 requests per second or a drop of 96% between trivial PHP and a ZF power app.
2. Time per request (time taken to satisfy 1 request) = 328.49 ms or 0.328 seconds a change of .315 seconds or an increase of 23%
Conclusion
Even though my benchmarking techniques might be flawed, taking a base line reading with no HTML as well as a very simple PHP script web project allowed me to at least compare.
Based on these figures (if correct) Zend Framework has a HUGE overheard. But this should not discourage any would be ZF coder because there are caching techniques which were not used such as using APC and the benefits of a good network admin
Also the benefits of using any framework far outweigh the drawbacks in my personal opinion. Where else can you get code which has been tested by the best and packed to contain methods for many of our typical coding requests.
Armando Padilla.