I’m not that fast any more

“not fast” is better than “slow”, so I think I’m making progress, better than before.

Updates:

• I moved to proxmox which gives me better VM performance so that I can have more VMs for my test, it did take me some time to dig out a usable solution. Now I’m running 4 VMs so I can test fail-over and bootstrap etc.
• I moved to Python since PHP is not that popular now especially in all these new technology, I’m a code-by-sample guy, so while the whole world is writing codes in Java, Ruby, and Python, I don’t have many choices. I picked Python because I don’t want to run things like Tomcat, and built-in web servers does not convince me (I’m talking about Ruby).
• I’ve done some simple tests but dealing with columns, etc., the test environment gives me reasonable performance number – 8ms per read/write.
• I’m still learning Python and its web stuffs, seems not that hard to catch up though. I’m using web.py which seems to be the lightest framework, I may be wrong but I don’t want to dig in more at this moment.

To-do list:

• I need to figure out if Ubuntu is still the way to go for my virtualization environment, I’m worrying proxmox is not a major player in this area so it may ruin my long term plan.
• I need to find out if there is any other better HTTP server, “better” here means: light, support wsgi.
• I’m going to compose some test scripts dealing with super column, which is what I need to use for the statistic project.
• Revisit original design, both schema and work flow may have some changes.

I would like to say, everything is on the track, though I’m not that fast. I will post updates after this thanks giving as I doubt if I will have time coding during the holiday.

Changes …

Here is the deal – I decided to drop PHP and moving to Python, so that I can spend less time on dealing with less-supported PHP (in this nosql wave), I’ve removed PHP from all dev/test environments and wish I won’t come back later.

Actually I’ve made PHP works, but I’m just not feeling well as not many people are using PHP and it seems hard to seek help whenever needed. Also, seems setting up Python with Apache (through wsgi) is not that difficult. It could be a good chance to lear Python as well, though I did some PyS60 a while ago (for Jabber on E90).

BTW, I’ve upgraded all Fedora instances (3 of them) to Fedora 12, so far so good.

Update on research

I’ve deployed Cassandra to my development environment, running on 4 servers with replica 2. I picked the number 4 and 2 because it’s more like a real world thing, and it is the requirement from my friend. I can test fail-over etc later on.

I’ve also composed some scripts to do service stuffs – the script I composed can start/stop/restart Cassandra gracefully, it can also tell status of the node and the cluster, it’s a simple Shell script, I will make it a service under Fedora, and a init.d script under Ubuntu (I’m running only these two platform now). Cassandra was upgrade from 0.4.1 to 0.4.2 days ago, and I used that as a chance to test my deployment stuffs, seems pretty good. I think I just need to be careful with 0.4.x => 0.5.x upgrade since it may break compatibility on configuration and command line.

I’ve converted my PowerBook to a dedicated client machine running Fedora … it’s a pretty old machine and seems Apple does not want to roll out new software (such as JDK 1.6) for it, so I did some survey around and picked Fedora (Ubuntu is not ppc friendly – the support is community based).

And finally I have Thrift/PHP up and running. At the very beginning I was thinking I should use Java as the client but later one found that I have no idea how to develop Java based web application, and since Thrift mentioned it supports all C/C++, Java, Perl, PHP, Ruby, Python pretty well, I should just pick my favorite language to do the test and then let real clients pick what they  want to use (where is my client, BTW? ).

And yes, I confirmed the schema (though Cassandra is schema-less thing), I’m going to test the schema with PHP client today. After that I will have to find a place to hold all my codes/configuration, etc, in a subversion, and based on what I found so far, github.com is the best candidate.

Will update here today or tomorrow.

Symfony and Godaddy

Though problems I’m going to discuss are for symfony 1.2, I guess it applicable to 1.0 and 1.1 as well.

I finally got symfony works on godaddy shared hosting, I guess if I were running any sort of dedicated hosting, these problem could not have happened, as I have full control.

The first problem hit me is PHP version, symfony needs PHP5, and godaddy supports PHP5 – good. However, it seems godaddy’s default PHP is still PHP4 so have to set alias to make sure symfony script is interpreted by PHP5 instead of PHP4:

alias symfony=’/usr/local/php5/bin/php /path/to/symfony-1.2.7/data/bin/symfony’

after this, I got the problem, saying:

/usr/local/php5/bin/php: Symbol `client_errors’ has different size in shared object, consider re-linking

and turned out it was because of mysql client lib problem – I don’t know the detail yet, but seems /usr/local/php5/bin/php and /web/cgi-bin/php5 are both linked to /usr/lib/mysql/libmysqlclient.so.15, which works for /web one but not the /usr one. I did some tests and found /usr/lib/libmysqlclient.so.14.0.0 works perfect with /usr/local/php5/bin/php, so put this into my .bash_profile:

LD_PRELOAD=/usr/lib/libmysqlclient.so.14.0.0

note that /usr/lib/libmysqlclient.so.10.0.0 doesn’t work well as it’s too old to support modern (new) password encrypt/authentication.

By now I can use symfony do the development job, but problem are still there while I’m trying to browse from browser, the first thing is rewrite rules – these lines should be uncommented from web/.htaccess:

RewriteBase /
RewriteCond %{REQUEST_URI} \..+$
RewriteCond %{REQUEST_URI} !\.html$
RewriteRule .* – [L]

then I met the problem (which took me longest time to solve) with error:
Empty module and/or action after parsing the URL “/index.php” (/).
actually I should have got it solve earlier if I search on the web, there is a great article talking about the solution, and my problem got solved just after 1st part of solution mentioned by the blog – adding following lines to “all” section of apps/frontend/config/factories.yml:

request:
  param:
    path_info_key: REQUEST_URI

be careful with intending, original blog seems not doing the right thing and put “request” and “param” in same level, which is wrong.

Alright, by this time you will be able to play with symfony on shared hosting with godaddy.

hmmm … php and apache are still much more easier

I have about 2,600 photos uploaded to one of my web sites, and I compose couple of quick PHP scripts to help me browse them. There is a img.php to resize the photo for different purpose (such as thumb view for listing page, medium size for view online, and full size for downloading), but whenever I try to download the photo, I found it’s tough as it always prompt to save as “img.php.jpeg”.

So, instead of doing any PHP stuff, I changed .htaccess under the folder, let apache do rewrite for me, in couple of minutes everything works like a chime.

These are really simple tasks, I guess it can be done with anything else (lighttpd, python, blar blar), but obviously I’m still familiar with PHP and Apache httpd, guess I should stick on that till something else can be this easy to me, just as years back I switched from qmail to postfix …

Back to PHP

It seems godaddy supports PHP only so I’m thinking of stop learning Python for now even it has better framework. There are some widely used PHP framework that I can take to deploy to godaddy, which is more convenience.

Currently I’m comparing Zend, CakePHP, and Symfony. I guess I won’t try Zend as it sound like too old, and does not support application generation. People mentioned CakePHP lack os real model support, while Symfony is sort of too complicated to start with.

I will focus on CakePHP and Symfony, I get a feeling that I will stick with CakePHP without any reason, but sure I will do serious research on Symfony as well.

Again, I will post my findings here.