Archive for July, 2011
Its a really hard question to answer, especially when you’re creating something new.
After making some changes to become more “compliant” with Facebooks TOS I decided that I’d re-launch our “Who isnt my friend?” (now called “Friend-Watch“) application by simply adding it to my wall, and then doing nothing. Anyone who has followed this blog in the past knows that this app took off all by itself in the past, so it shouldnt be any surprise that I’d like to see if that happens again (if i do nothing to help it).
That was about 4 days ago now, so today I decided to measure my performance. In order to do this I created the following graphs:
The Engatement stats are interesting because without me doing anything, they’re all pointed in the right direction…so i guess we can watch this one for a while longer and see what happens!
What interests me the most is the “System performance” graph. I was trying to answer the question “how do i know if i need more hardware?”. Previously when i wrote this app I had a massive issue with scale. I think that issue is pretty much resolved, but now i need to ask myself “how do i know when i need to scale it?” Thats where this graph came from.
I’ve drawn 3 key details on the “System performance” graph:
- Total audits – This shows how many audits the system has done as to date
- Total audits on day – This shows how many audits the system did on this day
- Total audits per user * 100 – This shows how many times each user was audited on average, multiplied by 100 to blow up any issues so they’re more easily seen
At first i just implemented “total audits” and “total audits on day”. I made the assumption that when i hit the servers limit i would see the “total audits on day” flat line. While i dont think this is an invalid assumption, it would take a few days for me to notice this…not cool. Then i had a better idea, i should measure how many times each user has been audited.
In general the way this application works is pretty simple. We check each users account once every 7 hours (ideally…) based on a queuing system. There are two “worker” processes, so I expect that ideally we should see around 10-12 audits per user per day (which is something like whats happening in reality), but whats most important from a “system health” type situation is that whatever the current level of “audits per user * 100″ is doesnt change too much from the previous day.
I’m sure there are a lot more details we can abstract out, but I just thought this was interesting and worthy of writing. Enjoy
We’re at it all over again! Another crazy idea…only this time, its less crazy.
My friend Mike Curry of Blue74.com and I will be working together on our “Startup for startups”, tech startups to be specific. Having worked in tech companies, we think it makes sense. We regularly come across problems that we cannot find easy solutions to, only to run around inventing solutions to these problems just for ourselves. Recently we have both run into this far too often, so we’ve decided to go ahead and turn these little ideas into one big product, one big product that will be the one stop shop for startup tech companies who need software monitoring solutions.
I know you’re all saying “uh…Nagios?” but thats not where we’re headed with this. Nagios, or a similar tool, is just one key part of a good monitoring solution. Its just as important to have someone react to an issue, have a backup person should they not be available, and for that person (The one who finally responds) to have the ability to get the people they need assistance from on the phone in the shortest period of time possible. For this reason we will integrate with existing monitoring setups and provide an external point of reference, both of which will make sure you are well aware when something goes wrong regardless of where you.
Down time costs money, it costs customers and most of all…it just makes us all look bad. We address these problems in ways the Internet has never seen before, that’s what its all about. Stay tuned for more info.
I’m very sad to say that Facebook has decided that the “Who isnt your friend?” application is a “negative” user experience and decided to ban its app key.
At the end I had some cool features (which i didnt think were negative):
- Detect people who are no longer your friend
- Detect name changes
- Show breakdown of Males, Females and “Unknown” in someones friend list
- Show a users friend list on a map of the world (I was going to go for an affiliate deal here with some travel company and encourage people to visit their friends…)
Detect users who block /unblock their friends– I Removed this feature as i felt it was a bit too negative Detect users who deactivate / reactivate– Also removed for the same reason as above
I’m a bit upset by this, but at the same time i got a lot out of the experience of creating this application, so i feel like i can let it slide (I should note i wrote some pretty nasty emails to Facebook before i came to this conclusion)
For those of you who care, here are the highlights:
- Discovered a lot of quirky Facebook API bugs, and how to work around them
- Managed to turn a process that collected names (at the end i had around 5 million unique names collected) which took over 5 days to refresh them all (for detecting name changes) into a process which could refresh every single name in under 2 hours
- Managed to scale the application such that it didn’t matter how many users started using the app, all I had to do was start up a new server and let the “worker” processes do their thing. They wouldnt get in each others way, they would just lock a user and keep going
- Learned a lot about advertising and monetizing a Facebook application (essentially, unless you have around 2000 daily returning users, don’t expect to make much more than $10 / day)
- and the big one…I managed to get my app to go viral
The day that i completed my major re-write of the back-end code of the app i started graphing the number of users who signed up each day. This was the end result!