TechTalk
29 Dec, 2009
Investigating Message Queueing systems
Posted by Bhavin Turakhia | (6) Comments
In my constant quest for creating scalable systems and architecture a robust message queuing system was the missing link. I have begun reviewing some of the available options. This is a rough list of some of the interesting links I came across during this process -
- http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes - A detailed comparison of queuing systems and their advantages and disadvantages. Covers RabbitMQ and Apache qpid and several others. The most comprehensive list of message queueing systems I found
- http://stackoverflow.com/questions/731233/activemq-or-rabbitmq-or-zeromq-or - A list of links comparing various queueing systems
- http://www.unlimitednovelty.com/2009/04/twitter-blaming-ruby-for-their-mistakes.html - A detailed critique on how twitter selected its message queue implementaions with comments from the developers at twitter and why they wrote their own queue. Do read the comments. They have a ton of meat
- http://www.zeromq.org/whitepapers:brokerless - An interesting paper on brokerless message queues and the advantages thereof
- http://gojko.net/2009/03/16/qcon-london-2009-upgrading-twitter-without-service-disruptions/ - Talks a bit about how twitter uses a messaging framework at the backend
- http://blog.evanweaver.com/articles/2009/03/13/qcon-presentation/ - Evan Weaver’s talk on scaling twitter
25 Dec, 2009
The evolution of push email
Posted by Bhavin Turakhia | (11) Comments
I have been meaning to compile research on push technologies and the evolution of push email since a while. A conversation with ramki on how gmail offers push email using Microsoft Direct Push triggered my research and here is a summarized compilation of my findings
Blackberry
Blackberry works by downloading your email to its NOC. Whenever it finds a new mail it pushes it out to your cellphone. This is why Blackberry requires you to subscribe to a specific blackberry plan through your Telco. If you have a blackberry plan, your Telco forwards your registration to Blackberry and whenever you are online, Blackberry knows how to find you. Whenever the Blackberry NOC downloads a new mail from your mail servers it pushes the mail out to your cellphone through your Telco. This last bit is proprietary and presumably requires support from the Telcos end. Since a data-push is made to your cellphone only when there is data to be pushed, your battery life is conserved
References
Microsoft AUTD
This was the earlier version of Microsoft’s push technology. Basically Microsoft Exchange (or any mail server) is configured to simply send out a special SMS to your cellphone number each time new data needs to be pushed to your cellphone, and your cellphone is not currently connected. This SMS does not get displayed in your inbox, but rather triggers the mail application (or any other applicable app) in the background to sync with the server. This mechanism requires the use of an SMS gateway and/or possible support from your Telco to be able to send out these type of SMSes.
References
Microsoft Direct Push
This is the latest version of Microsoft’s push technology. It sounded esoteric, but upon close investigation it turned out to be a fancy microsoft name for a technology that has existed for nearly a decade viz. Comet. The way this works is as follows -
- The application on your mobile (lets say your email client) makes a Comet HTTP request to an http server. Along with this request it sends the server a timeout value – say T=15 minutes
- If in the next 15 minutes the server receives a new mail, the server immediately sends an HTTP response with a status that results in the client syncing with the server and then once again issuing a long poll http request
- If in the next 15 minutes the server receives no new mail, the server must at the end of 15 minutes send an empty status response to the client, upon receiving which, the client once again initiates a new HTTP request
- Since this method requires a poll to the server every ‘x’ minutes it typically consumes more battery than Blackberry but the difference should not be too high
- Since the Telco en route may have its own enfroced timeout values on any http connections, it may disconnect a long-running HTTP connection
- Therefore the actual timeout time must be negotiated between the client handset and the server during bootstrapping by attempting higher and higher timeout values until the highest value that the Telco permits is discovered
- The HTTP connection may also get dropped due to network failures and switch-overs. Clients can detect this at the TCP/IP level and re-attempt connections. I am not entirely sure about this part, but the HTTP client presumably also uses TCP Keep alive internally to ensure the TCP connection remains alive
- One may want to lookup the actual port numbers and protocol implementation of Microsoft Direct Push, since it is likely that most Telcos support Microsoft Direct Push and therefore if one was to emulate their push service on the same server port it is likely that Telcos would let the long-running HTTP connection persist
- The advantage of this method is it does not require any special Blackberry plan
References
- How Direct Push really works - http://www.techatplay.com/?p=11
- Comparison between Direct Push and Blackberry - http://www.techatplay.com/?p=13
- What uses lesser traffic – Microsoft Direct Push or Blackberry – http://www.rysavy.com/Articles/Rysavy_Wireless_EMail.pdf
- http://en.wikipedia.org/wiki/Comet_(programming)
- http://www.emansio.com/ – A push email product for windows mobile
- http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html – Overview on TCP Keep Alive
Misc References
- A detailed guide on Direct Push - http://www.techatplay.com/?p=8
- Definition of Push email - http://www.techatplay.com/?p=32
- A detailed list of all the push technologies out there – http://en.wikipedia.org/wiki/Push_e-mail
-
http://en.wikipedia.org/wiki/Lemonade_Profile
- Another interesting push email technology that uses IMAP notify and IDLE – http://en.wikipedia.org/wiki/Lemonade_Profile
10 Dec, 2009
A detailed primer on building cross platform mobile applications
Posted by Bhavin Turakhia | (9) Comments
I finally had a few hours today morning to wrap up my study on comparison of mobile application platforms that allow developing cross-device applications easily using familiar technologies. Here is a quick braindump of all the links and resources I went through -
Rhomobile
- Google TechTalk on Rhodes - http://www.youtube.com/watch?v=T2pztOky_L0
- http://rhomobile.com/products/rhodes/
- http://www.ultrasaurus.com/sarahblog/2009/07/cross-platform-mobile-apps-with-rhomobile/
- http://www.rhohub.com/
- Notes
- Dual licensed. Though license is cheap – $500
- Code is written in html and ruby
(though a python interpreter would have gotten more smileys from me
) - interesting approach – uses the native browser component of the cellphone itself to render the html and a web server to host the app – so javascript support will be random based on the phone browser support
- sqlite support
- Supports iphone, windows mobile, blackberry, android, Symbisn etc
- Basically rhodes runs a mini ruby web server and an html rendering engine all in 2.3MB
- Supports native capabilities like camera, gps, PIM data, SMS etc
Phone gap
- http://phonegap.com/
- Check the video on their site
- Notes
- Fully open source and free
- Code written in html+javascript
- Supports iphone, blackberry and android
Pyxis Mobile
- http://pyxismobile.com/platform/technical-overview/
- Build one configuration and deploy to BlackBerry, iPhone, and Windows Mobile all at the same time
- Skinning, scripting, localized languages, complex workflow management, push, hotkeys, mapping & LBS, camera support, signature capture, GUI calendar, disambiguation, hotkeys, and much more
Titanium Mobile
- http://www.appcelerator.com/products/titanium-mobile/
- This is an upcoming mobile platform by appcelerator
- I am quite familiar with the company since we already use their Titanium Desktop and have two fulltime contributors to it
Quick Connect
Comparison sites and articles
- http://blog.twinapex.fi/2009/09/30/cross-platform-mobile-application-development-and-payment/
- http://en.wikipedia.org/wiki/Mobile_development
- http://www.infoworld.com/d/open-source/building-native-mobile-applications-open-source-mobile-platforms-735
- http://www.infoworld.com/d/mobilize/iphone-development-tools-work-way-you-do-309
- http://news.cnet.com/8301-1035_3-10202598-94.html
- http://www.slideshare.net/inouemak/rhodes-and-phone-gap
- http://techboise.com/multi-platform-mobile-development-and-quickconnect
Some others
14 Nov, 2009
RAM Speed
Posted by Bhavin Turakhia | (6) Comments
To test the speed of RAM, I got Ramki to run a small program that writes a set of bytes into memory a billion times and ran 4 instances of it on a dual proc quad core machine. Below are the results of running four instances of the program simultaneously.
Result
output.1: User time (seconds): 545.99
output.1: System time (seconds): 1.33
output.1: Elapsed (wall clock) time (h:mm:ss or m:ss): 9:07.38
output.1: Involuntary context switches: 820
output.2: User time (seconds): 250.90
output.2: System time (seconds): 1.18
output.2: Elapsed (wall clock) time (h:mm:ss or m:ss): 4:12.12
output.2: Involuntary context switches: 378
output.3: User time (seconds): 250.30
output.3: System time (seconds): 1.15
output.3: Elapsed (wall clock) time (h:mm:ss or m:ss): 4:11.49
output.3: Involuntary context switches: 373
output.4: User time (seconds): 563.62
output.4: System time (seconds): 1.31
output.4: Elapsed (wall clock) time (h:mm:ss or m:ss): 9:25.00
output.4: Involuntary context switches: 845
Observations
- The write speed was between 0.25 seconds per million writes to 0.55 seconds
- Output.2 and .3 took half the time as that of .1 or .4
- Don’t have a specific theory on why 2 of the cores did better than the other two
- No processor affinity was set, and the processes were being scheduled on random processors after every context switch.
- Seemingly the processes were accessing RAM simultaneously. In my limited knowledge that could mean a few things – Multi-channel FSB (Dual) and additionally while oneprocess was computing stuff the other processes could access the FSB. The program was using lrand48 to generate a random number to write data to random locations so as to ensure that we do not rely too much on the L1/L2 cache
Some reading
4 Nov, 2009
Obese Footers :)
Posted by Bhavin Turakhia | (7) Comments
Fat footers are no longer an emerging trend and have rapidly become a standard navigation paradigm. This short post contains a bunch of useful links I gathered while researching “fat footers” (try and say that 5 times in rapid succession
) -
- http://ui-patterns.com/collection/fat-footer
- http://www.seopher.com/articles/the_7_best_fat_footers_used_on_high_profile_sites
- http://bluhalo.wordpress.com/2008/01/17/our-top-ten-fat-footer-sites-revealed/
- http://www.onethingnew.com/category/weekend-web-developer/
Feed your footers away!!
31 Oct, 2009
My Ideal layered distributed clustered redundant self healing Filesystem
Posted by Bhavin Turakhia | (4) Comments
This is a collection of notes on the features that my dream filesystem would support -
- multi-Layered storage – ability to support layers of slower to faster disks and move data at block and/or file level between them atomically, keeping the most frequently read data on the fastest disks. If there is block level support for this it would be a boon for databases, where frequently accessed pages could be kept in faster SSDs and less frequently accessed pages would be stored on slower SATA drives
- Distributed – ability to have multiple clients participate and access a single virtual storage device
- Replicated – each file (or block) is replicated ‘n’ times using master-master sync/async replication
- No FSCK
- Self-healing
- Compression – native support for compression at file or block level (ideally the former)
- Ability to access the file in its compressed form (useful where we can send out a compressed byte stream to the client and the uncompression is handled at the client)
- Snapshot capability
- Parity based RAID without write penalties (like Raid-Z)
ZFS supports many of the above features.
29 Sep, 2009
Writing a Wordpress Plugin
Posted by Bhavin Turakhia | (7) Comments
I was just reading up on building wordpress plugins andthe simplicity and architecture impressed me enough to quickly pen down a short post. Now it does not make any sense to pen down a detailed HowTo since the documentation on the wordpress site is adequate and self-explanatory. However here are some quick notes -
- Start off by reading – Writing a Plugin – it lays down the framework of creating a plugin and defines what your plugin should be called, file names, structure and even a header for your plugin
- Next review – Plugin API – which describes the simple yet powerful Hooks, Filters and Actions mechanism provided by Wordpress to plugin developers
- Hooks are provided by WordPress to allow your plugin to ‘hook into’ the rest of WordPress; that is, to call functions in your plugin at specific times, and thereby set your plugin in motion.
- There are two kinds of hooks – Actions and Filters
- Actions are the hooks that the WordPress core launches at specific points during execution, or when specific events occur. Your plugin can specify that one or more of its PHP functions are executed at these points, using the Action API.
- Filters are the hooks that WordPress launches to modify text of various types before adding it to the database or sending it to the browser screen. Your plugin can specify that one or more of its PHP functions is executed to modify specific types of text at these times, using the Filter API.
I like the architecture – it allows any plugin developer to modify pretty much any functionality provided within Wordpress. Many application platforms can be modeled around this same event-based plugin architecture providing powerful extensibility to plugin developers.
21 Sep, 2009
Checking in my 22″ LCD keyboard and mouse
Posted by Bhavin Turakhia | (6) Comments
I am a stickler w.r.t productivity and one of my biggest bones with travelling is the loss of efficiency on my 12.1″ Lenovo X 200. It is the most mobile laptop ever, and I have often been caught carrying it around in one hand whilst typing with another – without breaking a sweat – but when I am sitting in my hotel room, on one of my trips, I miss my regular IBM qwerty keyboard, Logitech mouse and multiple 22″ screens (I use 4 simultaneous monitors at work). I figure I lose atleast 35% in terms of speed and efficiency on these trips.
I have gone through several iterations to remedy this situation – including carrying a projector (uncomfortable), buying a head-visor (resolution became an issue amongst other things), and researching foldable monitors, until I finally realized the only way was to lug my 22″ screen and keyboard/mouse assembly alongwith me.
I figured there are likely others like me – and there must be a product that makes this easy. Given my travel schedule for the next few weeks, I figured it is high time I took a look around, and sure enough, within a few minutes of Googling I came across this baby -
http://www.casesbypelican.com/monitorlcd.htm

They also have a 24″ version that carries just the LCD – http://www.casesbypelican.com/1690-30-lcdmonitor.htm
I am getting mine as we speak. Meanwhile, a few other links I came across are -
17 Aug, 2009
A Compendium of solutions for scaling a Data Store
Posted by Bhavin Turakhia | (5) Comments
Achieving infinite scalability on your data store is the holy grail of scaling an application. App servers are typically stateless and therefore a cinch to scale. This document serves as a comprehensive compendium on my thoughts and research on scaling a data store.
Requirements
- Inifinite Scalability
- High Availability (0% downtime)
- Data Redundancy
- High Performance
- Storage Flexibility – ability to store any type of data
- Query Flexibility – ability to perform simple gets, range based gets, range based updates, and possibly complex joins
Features that a solution must have to deliver the above Requirements
- Replication – Each unit of data should be copied to multiple nodes so that if an underlying node crashes there is no data loss
- Partitioning – Data should be divided across multiple nodes based on specific keys so that the data layer is infinitely scalable
- Online node addition – Solution should support adding new nodes online, with automated data distribution upon new node addition
- Load Balancing – Queries should be load balanced between nodes
- Persistence – Should have a data persistence layer so that data is not volatile
- Caching – Should support flexible in-memory caching for increased retrieval speeds
- Tree based Indexing – To support range based queries ideally one may need tree type indexes for keys on which range queries maybe made
- Provides BigTable – Googles implementation of a scalable database
- BigTable is not an RDBMS, but has a fairly flexible API that supports creative data fetching methods
- BigTable is distributed and self-balancing – scaling is no longer the application developers problem
- You will need to host your application on Google’s App Engine
- Your application needs to use the BigTable API for data storage
- MySQL NDB Cluster is a master-master, self-partitioned, replicated storage engine that technically seems to provides all the features listed above
- It also offers access via SQL or a high-performant native NDB API
- It seems like the holy grail of database scaling
- It however stores indexes entirely in memory – and has lesser flexibility w.r.t persistence
- I could not find much material on the performance of an NDB Cluster
- HyperTable is an opensource BigTable clone and provides essentially the same features as described in the BigTable whitepaper
- It is supported by Baidu, Zvents and Rediff
- Voldemort is a big, distributed, persistent, fault-tolerant hash
- Developed and used by Linkedin
- Java based API
- Reasonably performant (10-20k ops on commodity hardware)
- Maintains replicated copies of data over multiple nodes and automatically handles server failures
- Does not support range based querying
- Tokyo Tyrant is a layer on top of Tokyo Cabinet – a highly performant, persistent data strore (site claims over 2 million qps)
- Tokyo Tyrant itself claims to deliver upwards of 58,000 qps
- It supports multiple language bindings (Java, Perl, PHP etc)
- Supports various data structures – hash, tree, B+tree, array, table etc
- Supports caching
- Tokyo Tyrant does not support active-active master-master replication, thus failing out on redundancy. It also does not support data partitioning out of the box
- Postgres is an extremely mature RDBMS
- Using PL/Proxy one can abstracte horizontal partitioning concerns out of the database layer and into an abstracted underlying layer
- Using Slony or Continuent one can ensure that multiple copies of any set of rows exist at any given point in time (Synchronous or Async replication)
- PGBouncer provides a light-weight connection pooler for PL/Proxy
- Together this will satisfy all our requirements above
- You may club Voldemort or memcached or redis with this to provide a caching layer
- Postgres also has hooks for connecting to memcached that make cache population and invalidation easier
- The BigTable paper – http://labs.google.com/papers/bigtable.html
- A powerpoint that touches upon bigtable, gfs etc - http://cbcg.net/talks/googleinternals/
- Condor – a specialized workload management and job queue system – http://www.cs.wisc.edu/condor/description.html
- Notes on Jeff Dean’s talk at Univ of Washington on BigTable – http://andrewhitchcock.org/?post=214
- Video on bigtable – http://video.google.com/videoplay?docid=7278544055668715642&q=bigtable
- A blog post walkthrough of the bigtable paper – http://hnr.dnsalias.net/wordpress/2008/10/bigtable-googles-distributed-data-store/
- A description of Paxos – http://en.wikipedia.org/wiki/Paxos_algorithm
- Project Boxwood – Microsoft Research project for a scalable data layer – http://research.microsoft.com/en-us/projects/boxwood/default.aspx
- http://code.google.com/appengine/
- Campfire video introducing app engine – http://www.youtube.com/watch?v=3Ztr-HhWX1c
- Getting started guide – http://code.google.com/appengine/docs/python/gettingstarted/
- Using the datastore – http://code.google.com/appengine/docs/python/gettingstarted/usingdatastore.html
- http://neo4j.org/
- http://wiki.neo4j.org/content/Main_Page
- http://wiki.neo4j.org/content/Neo_Performance_Guide
- http://wiki.neo4j.org/content/FAQ
- http://dist.neo4j.org/neo-technology-introduction.pdf
- http://wiki.neo4j.org/content/Getting_Started_Guide
- http://wiki.neo4j.org/content/Getting_Started_In_One_Minute_Guide
- http://www.slony.info/
- http://www.slony.info/documentation/
- https://developer.skype.com/SkypeGarage/DbProjects/PlProxy
- https://developer.skype.com/SkypeGarage/DbProjects/PgBouncer
- http://www.continuent.com/solutions/overview
- http://www.continuent.com/images/stories/pdfs/tungsten%20overview%20white%20paper.pdf
16 Aug, 2009
Infinitely Scalable Infrastructure and RDBMSes
Posted by Bhavin Turakhia | (1) Comments
Since the last several months I have been spending part of my time on conceptualizing an abstracted infrastructure layer that is highly scalable and can be leveraged by any application without having to worry too much about it. I have researched and continue to research conventional and unconventional techniques – partitioning, clustering, replication, shared-nothing architectures, grid computing and so on. This article represents a sliver of my thoughts concerning scalability and RDBMSes -
The holy grail of scalability is to be able to scale your data store. And as data stores go, RDBMSes seem to be the predominant choice (though that is changing – refer http://bit.ly/2lnRet). RDBMSes by their very nature, due to the features they provide (ACID compliance, Transaction safety etc) tend to be difficult to easily scale. This has resulted in the recent mushrooming of data storage options that are feature-poor but scalable out of the box (eg Voldemort, HyperTable etc)
I wanted to chronicle the list of features that a standard RDBMS provides, that we take for granted, so that I have a reference of the features that one may have to compromise on w.r.t application development in favor of easier scalability -
- Range based selects and updates – Being able to fire queries on a table specifying a range of values (eg where age >35). Typically RDBMSes use B+ Tree based indexes which support range based row selection. This in turn allows one to fire range based queries.
- Transactions – In an RDBMS one can perform multiple operations within a transaction and ensure that all of them or none of them go through. This ensures data integrity
- B+ tree indexes
- Foreign key relationships and referential integrity
- Joins and nested selects
- Aggregations (sum, avg etc)
- Advanced scripting using non-native languages (java etc)
- Stored procedures (allow encapsulation of business logic in the database layer)
- Triggers









