e-Business will be using Online’s News and Pring‘s Reach to distribute news to millions of Pakistanis. Now Pringers can subscribe to news and customize topics of interest, creating a personalized newspaper.

“Pring enables us access to unprecedented reach in Pakistan and with Online’s extensive coverage; this is a winning combination.” says Mohsin Baig, CEO of Online News International. “At Pring we continually strive to bring Pakistanis closer together by connecting people and communities with news and timely information. This collaboration is another step in this direction”, said Dr Muqtaza Shah CEO of e-Business.

Dr. Muqtaza Shah, CEO of e-Business with Mohsin J Baig, Editor in Chief Online Int'l News Network

The question whether there should be more provinces in Pakistan or not has been a subject of heated discussions in political circles and the media. We at Pring thought its time to use Pring and conduct polls to gauge public opinion and bring it to the foreground. Pringers could participate in the poll by replying to keywords and answering questions on this issue, e. g. “Kia ap ke khayal mein Pakistan mein mazeed soobay bannein chaheyain?”

We invited more than 20 thousand Pringers to participate and respond to these questions. On the issue of creating a Sirayeki province 51% people voted in favor of the idea whereas 49% people voted against it. Mubashir Luqman on his famous talk show “Khari Baat Luqman ke Saath” on Dunya TV shared the results of the polls with his viewers.

The show starts with a 2 minute segment on Pring Polls

You can also review the survey report:

Geo News Crime reporting section has started an initiative to fight street crime using citizen reporting platform powered by seenreport. If you or anyone around you had been a victim ...
1 video

While the array of cloud platforms (Platform as service) has increased significantly recently, its still a hard job to find the perfect host for your website. The obvious advantages of cloud platforms over dedicated servers start with cost and extend to ease of maintenance. For instance, on EC2 it takes about 30 min or less to fire a new server instance and the Amazon’s ability to charge its customer on per hour basis, makes EC2 a very attractive option. AutoScale is another great add-on to EC2 platform and lets the consumer automate the computing power usage based on user load.

We recently did an extended research on available cloud platforms for a client. The requirements were however no straight forward. Client’s top priorities were ability of platform to scale automatically, ease of maintenance, and performance of infrastructure. Then, to make the task challenging and exciting, the client wanted a geographical fail-over ability in case of a disaster. Amazon alone had 2 major outages in year 2011 so users are quite concern about business continuity in time of a disaster.

We evaluated many options starting from Amzon EC2, RDS, Heroku, Bluebox, RackSpace, High Velocity, Xeround etc and concluded that only one provider will not be able to answer all questions from our client. So we divided the architecture into App layer and DB layer and choose different hosts for each layer. In such a division the biggest concern is network latency but interesting fact is most cloud platforms are built over EC2 with additional wrapping so within EC2 network latency is not huge at all. We ran some test with Heroku (app) and Xeround (DB) and found network latency to be less than half a sec per transaction.

You can find below a presentation we put together after our analysis of different cloud hosts. There is a slide that links to a Google spreadsheet with calculation of estimated cost for our proposed infrastructure. Feel free to drop a comment to correct me or ask me

Presentation:

A common goal every website or online service provider share is to have maximum visitors or server hits possible. That, of course, does not include  spam or denial-of-service attack on the server. While more traffic or hits means more business, it also generates the need to ensure the scalability and load capacity of the server. Interestingly, most engineers haste in order to test the load capacity of the server and put tons of loads the very first day and expect to see great results. Guess what? the server either gets non-responsive (meaning probably crashed) or it did take the load but the engineer did not know they over-killed the hardware and received a shockingly high server invoice at end of month.

Clearly one nor want too small a server muscle, neither too big and expensive of a server. To look eye-to-eye with the load creep, there is need of a strategy. Here is part I of my kung-fu attempt to chop it down. I would like to keep it high level and at a strategic level. In part II I will discuss specific details of

our recent optimization exercise on Rails. I must disclaim that server tuning or optimization is a big topic with tons of material available and what follows is my experience working with load testing and optimization of a Ruby on Rails server for a messaging engine project.

Before You Start Optimizing and Scaling:

a) Size the Beast: Estimate your target load on server. I prefer a number like transactions per min rather than transactions per second. Per seconds is much smaller a number when you have heavy processing and a normal transaction spans over a few seconds. It is also important to clearly define what a transaction means in your system, does a single DB hit counts for a transaction or entertaining a user request end-end counts for a transaction?

b) Benchmark Response Times: The goal of optimization and scaling should not be solely handling more load on the server, but also serving requests within a decent response time. A server handling tons of loads but keeping the user waiting for longer period will soon put the CEO out of business

c) Choose an appropriate load generation mechanism: This could be a free tool like JMeter or SOAPUI who can can create massive HTTP hits on the server. The flexibility these tools provide is quite nice ranging from configuring exact load to put on server using multi-threading and ability to attach a data pool to vary request data. You can also write your own code to generate a load if the request structure is complex. In our case, we used both.

Places to look for Optimization:

a) Starting with code optimizations. Hotspots are DB calls, third party web service calls and parsing large JSONs, XMLs etc. I have experienced that using an async approach of DB writing and JSON/XML parsing (wherever possible) greatly improves system performance and user experience. We optimized one of our routines by 800% using asynchronous DB writing

b) Application server threads: Application server request threads should always maintain appropriate ratio with hardware muscle. You don’t want to do too much or too less parallel request handling on application server. Too much will lead to CPU or Memory starvation and too less means you have getting an oversize server invoice month end. With out pretty standard request size, we have enabled 50 maxClients for Apache on standard EC2 XLarge instance and hitting about 50% of CPU capacity

c) Caching: Caching saves us from disk and notwork latency by reusing already fetched data. Caching is also available at multiple levels starting from Web serer caching, SQL caching provided by standard RDBMS and third party caching such as Memcached

d) DB Indexing: This is not something super latest or cutting-edge and has been in use for a while, but, there is a catch. Normally we create DB indexes on tables whom we hit the most in searching etc. However, if there are massive CUD operation (Create, Update and Delete) on the table as well then indexes will really slow them down because it updates the B-trees every time

Guide Yourself in Load Testing:

a) A cyclic approach is what works. Run more than one tests while recording them. I have found it useful to create a simple spreadsheet that records details and results of every test run. I suggest to record basic information like hardware profile, change in settings/hardware from previous test, load put on server, throughput of the server, exceptions/crashed, and duration of test

b) Its important to bring one change at a time to the system – let it be DB index, memcached, or more memory attached to the system If we bring more than one changes to the system for test run then it will be hard to determine the adverse or positive affect of a change independently

c) Profile your system: We recorded following information during the tests. CPU, memory and disk usage using Munin, system throughput using NewRelic and system response times using JMeter

c) Do not forget longevity tests: While we run many short duration tests it is important to run 10 hour or a day long tests as well to figure out if there are any dormant memory leaks that might crash the system in a few days time

Below is my attempt to picture the optimization process in a simple flow chart:

In part II I will discuss specifics of our recent load testing exercise on Rails

We at tossdown have a confession to make. While busily scurrying around town (and well other cities of the country too) like madmen and women trying to make tossdown the king of all eatout portals in the country, we unfortunately assumed the role of the long-familiar step mom of the movies who almost always ends up ignoring her step child, which in our case was our poor little blog.  This we desperately needed to get out of the system because a guilty conscience is just not cut out for this sort of grueling work. To the tossdown team, if you are all reading this, you are free to collectively sigh with relief!! We have officially been given penance. Its time to get down to some serious scribbling because there is  just so much to write about and well lets just say we don’t want another episode of the horrible step mom creeping up now do we….?!

A lot has been happening. Facebook, with its complete invasion of our lives, has been the perfect little boy scout by helping tossdown cross the street and get down to some serious interaction with the public. By introducing new and tempting competitions, we have opened the gateway to our ever-excited, hyper younger generation that is always looking for ways to satiate their hunger for “FUN” & “FOOD”.  Our discount privilege cards have gathered a pretty decent (modesty is one of our greatest virtues if you haven’t noticed already) number of restaurants among the city’s better if not best eateries. Tossdown events at schools, colleges, expos, shopping malls etc. have given a great boost to our portal. This of course is a really small list of our current happenings and the rest of the ‘Top-Secret’ stuff shall be disclosed when the time is right. After all, with such teeth-clenching , aggressive competition these days, its better to secretly tip-toe around the market until you’re absolutely ready to pounce with your new found strategy and ideas.

I think its time we introduced you to our tossdown team. How does that sound? Alright in the coming issues be sure to catch the tossdown team hard at work and well in our jargon, hard at food. We’ll keep  you loyal tossdowners updated with all that is happening in the big, beautiful world of “Food & Eating out”!!

Till next time,

Happy eating and before you go, here’s a penny for your thoughts:

Next time you eat out and decide to leave a big portion of your meal untouched because you’re either watching your weight, or you’re out with friends who would make fun of your massive appetite, think twice. Its better to grab a doggy bag on your way out and hand it over to the nearest deserving and hungry person, than wasting all that good food . I learnt this from an expert and so should you;)

If you recall the online/offline debates 5-6 years back when SOA (Service Oriented Architecture) was the buzzword around Silicon Valley, at least I were of the opinion that SOA was more of a marketing gimmick than a technology leap. Most of the money marketing SOA was put by tech giants like IBM, Microsoft, TIBCO, Amazon etc. Though I still believe that SOA classifies as a philosophy of Software Architecturing, am I becoming a fan every passing day. I remember the first lesson of programming I had twelve years back ‘not to re-invent the wheel’. SOA is a perfect example of why ‘reusing the wheel’ is a great idea, engineering-wise and business-wise.

We were recently challenged at work to design and develop a next generation multi-media messaging system for a fortune corporate. The requirements were very interesting. Starting with cross platform support i.e. iPhone, Andriod, BB, WP7 and Web, the system was also required to record live audio and video and send as real-time attachments. The diaspora of media support in different mobile platforms is quite big thus the need of inter-format media encoding. Additional features were PUSH notifications upon message receive, and coupling with client’s proprietary LDAP. We planned a stage-wise release that is starting from a group of hundred users to acceptance-test the system, we targetted a 2nd release to 10K users and then eventually to full scale i.e. 30K users. the anticipated load on the system was 30 TPS resulting from 4-5 new message check calls from every user per second.

During the design phase of the system, we faced the question of choosing between non-SOA approach (do-it-yourself) versus a services based architecture for features like media encoding, PUSH messages and file storage. Though the decision of not doing-it-yourself means lesser control, lesser customization, dependency on a third company but thanks to SOA buzz created many years ago, plenty of smart people have founded SAAS companies that cater to most users needs of media encoding, storage and notifications. So our engineering team and client decided smartly and chose the SOA approach. We evaluated different options and settled with Encoding.com for media encoding, UrbanAship for notifications and S3 for media storage. One of the reason of choosing Encoding.com was its capability of solid integration with S3 storage.

The decision of following an SOA approach helped us in many ways. First and far-most we saved so much time. Rather setting up our own server for solutions like ffmpeg and then handling scaling and reliability, we shipped all the media encoding burden on encoding.com’s shoulders. Although they do have some scalability and video rotation issues but overall they have solid services to offer. PUSH notifications are generally not fully relied upon, but UrbanAship has been pretty solid delivering notifications. As I think of the time and effort we have saved in building our next generation messaging system by choosing an SOA architecture, its quite amazing. Not tp mention the savings in cost of development for the client!

As we move forward and add new interesting features to our system, we want to build upon the already ‘handy’ SOA architecture. Our next targets are addition of great Analytics for system usage. We have boiled down the list of available services to Google Analytics and Flurry. The range of analysis provided by both are quite interesting and we are inclined to use one of these SAAS providers than building our own analytics solution.

Historically, we’ve kept updates, comments and private messages to 140 characters. This was because an SMS is 160 characters long, your username takes upto 15 characters etc. But things have moved on fast since then; almost all handsets support “SMS concatenation” which means they can send and receive long SMS by stitching single messages together. It works pretty well.

Starting today, you can now send updates as much as 420 characters long! This gives you ample space for those thoughts when 140 just won’t do.

The other main reason we wanted to increase this limit was the answer to the question “what do you do if you have something longer to say?” In the online world, you write a blog post and you share the shortened link. But what about all those users who don’t have access to the Internet or a smartphone? Pring was designed from the ground-up to support SMS and it is important for us that every feature we launch works well over SMS. Short messages work well for sharing links, commenting and chatting; long messages are useful for conveying larger thoughts.

We hope you enjoy our update and that you keep sending us your feedback.

Until next time, Happy Pringing!

by @Nash

Another major milestone for yellO was it’s magazine which had been in the making for almost 2 years and with our Government’s permission in place to finally publish, we launched our first issue in February 2011.

The magazine which is a reflection of the website contains blogs, user comments, reviews, business listings and classified ads. The Content section is further divided into Spotlight, where we focus on a business or person, which is doing good for the society. Finally there’s a Celebrity Q&A section, which features a celebrity interview and events section.

However, my most favourite part is the yellO Map associated with the business listings. Its like a game; you find a business you like, check the coordinates given with it and then find those coordinates on the map to know exactly where that business is situated in that area. The business listings contain the business address and phone number.

Although, after distributing 10,000 copies in Phase 1, 2, 4, 5 and 7 of DHA, we can safely say that the FREE classifieds are the highlight of the magazine. It has never been done before that anyone lets you post classified ads in their magazine for free of charge, but yellO does it.

Here’s something a fan said about the magazine on yellO’s facebook page

Kanwal Tariq: i got a copy too n i keep it on my bedside 4 quick reference. Thanx. Looking 4wd 4 march’s issue ?

And just in case you didn’t get our first issue, you can read it online.