I typically will not write about anything non-technical but I will make an exception this time. Why-oh-why is it like pulling teeth when dealing with the iPhone App Developer Program support. I get the feeling that when I call and wait my turn in the phone queue, all I am getting to talk to is a receptionist who is going to “escalate the matter”. When asked how long it will take to get a response back, I am told that it will take a week to a week and a half. This is a VERY simple matter. All I want to know is how many downloads my app has had. Shouldn’t this automatically, programmatically for that matter, be turned on in the iTunesConnect portal by default when an app goes live? If that was the case, I could be writing a blog post about how awesome the developer program is, but no, I am stuck here writing in frustration.

Having dealt with Apple support for a Macbook Pro a couple of times, the iPhone Developer support seems like a bunch of amateurs who have no idea what’s going on. As an AAPL share holder, I am glad that the general public does not have to deal with the iPhone Developer support, as it would turn people away in droves.

If anyone with power to help in this situation is reading this post please feel free to contact me at rswarthout [at] gmail [dot] com.

You’re deep in the jungle when suddenly a silly little monkey starts laughing at you. Better show him who’s boss and slap that monkey! Similar to the classic arcade game “Whack A Mole” this game is both funny and easy to play. Exciting features test your speed and coordination and you try to slap every monkey you see. Extra points if you catch him while he is stealing bananas. Guaranteed to be more fun than a… barrel full of monkeys.

Features:

• Multi-touch game play
• Endless Levels
• 3 independent difficulty settings
• Sound Control
• Top Score Board

Here are a few screen shots of what this will look like:

Be sure to let me know what you think about this game.

Run #1:

11409 fetches, 20 max parallel, 45636 bytes, in 600.011 seconds
4 mean bytes/connection
19.0146 fetches/sec, 76.0586 bytes/sec
msecs/connect: 0.211857 mean, 39.668 max, 0.029 min
msecs/first-response: 1050.65 mean, 2662.53 max, 323.514 min
HTTP response codes: code 200 — 11409

Run #2:

11141 fetches, 20 max parallel, 44564 bytes, in 600.005 seconds
4 mean bytes/connection
18.5682 fetches/sec, 74.2727 bytes/sec
msecs/connect: 0.206869 mean, 30.293 max, 0 min
msecs/first-response: 1076.17 mean, 2317.13 max, 350.16 min
HTTP response codes: code 200 — 11141

Run #3:

11183 fetches, 20 max parallel, 44732 bytes, in 600 seconds
4 mean bytes/connection
18.6383 fetches/sec, 74.5533 bytes/sec
msecs/connect: 0.201182 mean, 24.691 max, 0.03 min
msecs/first-response: 1071.81 mean, 2448.18 max, 366.686 min
HTTP response codes: code 200 — 11183

Results Analysis

• Average requests per second: 18.7043
• Average requests completed: 11,244

These results can be compared to the previous post on this topic.

I used MySQL 5.0.45, PHP 5.2.4 for this benchmarking. You can download the same sample MySQL database that is used for this set of benchmarking by visiting http://dev.mysql.com/doc/#sampledb. In the list of example databases, choose the one named ’sakila’.

For each connection type I will run three tests to see compensate for variations in tests. I will be using http_load to do the benchmarking of the connection file. To view each of the connection files, download the file bundle at the end of this post.

Below is the benchmark command with the options used for each run.

./http_load -verbose -parallel 20 -seconds 600 urls.txt

The urls.txt file contains the following:

http://127.0.0.1/mysql_connection_bench_{CONNECT_TYPE}.php

Between each benchmark run I will restart both Apache and MySQL.

Results for the standard MySQL functions in PHP using mysql_connect.

Run #1:

11024 fetches, 20 max parallel, 44096 bytes, in 600.007 seconds
4 mean bytes/connection
18.3731 fetches/sec, 73.4925 bytes/sec
msecs/connect: 0.22087 mean, 48.992 max, 0.03 min
msecs/first-response: 1087.74 mean, 2880.95 max, 355.012 min
HTTP response codes: code 200 — 11024

Run #2:

10895 fetches, 20 max parallel, 43580 bytes, in 600.004 seconds
4 mean bytes/connection
18.1582 fetches/sec, 72.6328 bytes/sec
msecs/connect: 0.219867 mean, 48.58 max, 0.031 min
msecs/first-response: 1100.1 mean, 2623.47 max, 369.341 min
HTTP response codes: code 200 — 10895

Run #3:

11134 fetches, 20 max parallel, 44536 bytes, in 600.003 seconds
4 mean bytes/connection
18.5566 fetches/sec, 74.2264 bytes/sec
msecs/connect: 0.217796 mean, 42.036 max, 0.03 min
msecs/first-response: 1076.59 mean, 3079.73 max, 270.734 min
HTTP response codes: code 200 — 11134

Results for the standard MySQL functions in PHP using mysql_pconnect.

Run #1:

10982 fetches, 20 max parallel, 43928 bytes, in 600.025 seconds
4 mean bytes/connection
18.3026 fetches/sec, 73.2103 bytes/sec
msecs/connect: 0.216663 mean, 69.795 max, 0 min
msecs/first-response: 1091.52 mean, 3166.82 max, 254.36 min
HTTP response codes: code 200 — 10982

Run #2:

11002 fetches, 20 max parallel, 44008 bytes, in 600.001 seconds
4 mean bytes/connection
18.3366 fetches/sec, 73.3465 bytes/sec
msecs/connect: 0.20555 mean, 47.176 max, 0.031 min
msecs/first-response: 1089.51 mean, 2953.82 max, 414.826 min
HTTP response codes: code 200 — 11002

Run #3:

11196 fetches, 20 max parallel, 44784 bytes, in 600 seconds
4 mean bytes/connection
18.66 fetches/sec, 74.6399 bytes/sec
msecs/connect: 0.2013 mean, 22.478 max, 0.03 min
msecs/first-response: 1070.5 mean, 2506.02 max, 448.161 min
HTTP response codes: code 200 — 11196

Results for non-persistent connections with PDO_MYSQL.

Run #1:

10995 fetches, 20 max parallel, 43980 bytes, in 600.008 seconds
4 mean bytes/connection
18.3248 fetches/sec, 73.299 bytes/sec
msecs/connect: 0.203731 mean, 17.309 max, 0.029 min
msecs/first-response: 1090.44 mean, 2852.34 max, 358.45 min
HTTP response codes: code 200 — 10995

Run #2:

10971 fetches, 20 max parallel, 43884 bytes, in 600.002 seconds
4 mean bytes/connection
18.285 fetches/sec, 73.1398 bytes/sec
msecs/connect: 0.21357 mean, 32.036 max, 0 min
msecs/first-response: 1092.36 mean, 3515.71 max, 456.688 min
HTTP response codes: code 200 — 10971

Run #3:

11161 fetches, 20 max parallel, 44644 bytes, in 600.001 seconds
4 mean bytes/connection
18.6016 fetches/sec, 74.4065 bytes/sec
msecs/connect: 0.20571 mean, 31.679 max, 0.031 min
msecs/first-response: 1073.96 mean, 2539.06 max, 351.236 min
HTTP response codes: code 200 — 11161

Results for persistent connections with PDO_MYSQL.

Run #1:

10347 fetches, 20 max parallel, 41388 bytes, in 600.006 seconds
4 mean bytes/connection
17.2448 fetches/sec, 68.9793 bytes/sec
msecs/connect: 0.253049 mean, 96.354 max, 0 min
msecs/first-response: 1158.52 mean, 2596.78 max, 282.647 min
HTTP response codes: code 200 — 10347

Run #2:

11106 fetches, 20 max parallel, 44424 bytes, in 600.008 seconds
4 mean bytes/connection
18.5098 fetches/sec, 74.0391 bytes/sec
msecs/connect: 0.226898 mean, 51.29 max, 0.03 min
msecs/first-response: 1079.29 mean, 2393.4 max, 311.85 min
HTTP response codes: code 200 — 11106

Run #3:

10978 fetches, 20 max parallel, 43912 bytes, in 600.029 seconds
4 mean bytes/connection
18.2958 fetches/sec, 73.1831 bytes/sec
msecs/connect: 0.210895 mean, 30.339 max, 0 min
msecs/first-response: 1091.98 mean, 3455.6 max, 373.751 min
HTTP response codes: code 200 — 10978

Results Analysis

• mysql_connect
  • Average requests per second: 18.3626
  • Average requests completed: 11,017
• mysql_pconnect
  • Average requests per second: 18.4330
  • Average requests completed: 11,060
• PDO_MySQL non-persistent
  • Average requests per second: 18.4038
  • Average requests completed: 11,042
• PDO_MySQL persistent
  • Average requests per second: 18.0168
  • Average requests completed: 10,810

Basically what the numbers above shows us is that in an isolated environment it makes no difference which connection type you are going to use. My past experience in live heavily trafficked environment says that using non-persistent connections is better than using persistent connections. Where this difference comes shows itself the most is when an apache thread will hang and still hold the persistent connection to mysql preventing other apache processes from connecting. By tweaking your apache and mysql settings you can achieve very good performance with non-persistent connections.

Source files for this benchmarking test.

One of the the nice things about SVN is that it keeps track of who changes what line and what changes they made on that line. SVN bases the username it stores on who committed the file. The trick in getting a PHP frontend to SVN to work correctly is that the user that apache is running as needs to be the user who is performing the commit action. To do this and make it work in a multiple user environment I have setup apache to proxy through requests to a specific URL to another instance of apache running as the needed user. In this setup you will need to have mod_proxy either loaded or compiled into your apache setup.

For example a request sent to http://rswarthout.svn.dummydomain.com would be routed through a proxy in apache to another instance of apache at http://127.0.0.1:8001. This internal address will handle the apache requests and pass it back to the web facing apache server instance.

The apache virtual host config below is for the web facing apache instance:

<VirtualHost 12.34.56.78:80>
ServerName rswarthout.svn.dummydomain.com
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8001/
ProxyPassReverse / http://127.0.0.1:8001/
<VirtualHost>

You will need to start a seperate instance of apache and pass it the config file to run. The config file below will start apache and have it listen on IP 127.0.0.1 only on port 8001.

Listen 127.0.0.1:8001

LoadModule php5_module modules/libphp5.so
AddType application/x-httpd-php .php

DocumentRoot “/home/svn.dummydomain.com/public_html”

<Directory “/home/svn.dummydomain.com/public_html”>
Options -Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>

User rswarthout
Group rswarthout

DirectoryIndex index.php index.html

php_admin_value include_path “.:/home/svn.dummydomain.com/:/usr/share/pear”

In the above apache config you will see that I am setting the include path for PHP as well in the last line. This is not a requirement but it is good practice to only have files accessible through apache that need to be. To start a seperate instance of apache with the above config run the following command.

/path/to/apache/httpd -f /path/to/above/config/file.conf

That is all for this piece of the puzzle. Next time I will begin to explain the PHP side of the puzzle. When this puzzle is broken up into its smaller pieces it is quite easy to work through.

1. Return a blank page
2. Try loading the page forever

Prior to finding this bug, our apache settings for mod_deflate looked like…

AddOutputFilterByType DEFLATE text/html text/css text/xml text/plain application/x-javascript

Now it looks like…

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.[0678] no-gzip
BrowserMatch \bMSIE\s7Â !no-gzip !gzip-only-text/html

Making these changes seemed to have fixed the issue. Now when a page is loaded in IE6, any external javascript file will not be gzipped and their page load will be slower. I suppose that is punishment for not upgrading to IE7 or getting Firefox.