Shotbeak.com
msgbartop
On Air: Student, aspiring web entrepreneur and musician.
msgbarbottom

05 Oct 09 Why is my tweekly.fm so late?

Tags:

I am seeing more and more people complaining that their Tweekly.fm isn’t working only to see their profiles updated later. A trend I see is that people revoke access, because they think their Tweekly.fm isn’t working, but it was working, the people only had to wait.

The problem with Tweekly.fm at the moment is that it has become slightly too big for what it was in the beginning. It has almost 11 000 users now and the script is taking about 5 hours to send. That means that tweets are spread out, by the order in which you signed up, over 5 hours. So you might think that your Tweekly.fm isn’t working, but you should just be patient… for now.

I’m currently in the process of speeding up the script. If push comes to shove, I can always optimise the script, parallelize it, add more computing power, but in the end, it’s actually a “broken” system. Down the line, it will eventually become too much. If I went all “start-up” on this, I could perhaps do it, but Tweekly.fm is a hobby project that I must manage.

So, I’m thinking of ways of changing the way Tweekly.fm works. With the new redesign, it should work perfectly. My main idea is making Tweekly.fm “manual”. Click a button and a tweet will be sent, just as it is now. If you want to auto-tweet, you must make a donation and then be able stipulate at what time your tweekly.fm tweet should run. This way, I can spread out the tweets and gather more money to pay for faster servers.

For now, I think it is a win-win situation.

Tell me what you think.

P.S. Advertising could also pay for the servers. 400k pageviews. 22k unique visitors. 400k alexa. You know you want to. ;)

Become a share-bear:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • muti
  • Reddit
  • Slashdot
  • StumbleUpon
  • Tumblr
  • TwitThis
Similar Posts:
  • xpaulbettsx
    Instead of batching all of the tweets up into one giant weekly cronjob, instead randomly pick a day of the week for each user (or better yet, a random time), and evenly bucket them - this way your server is running more often, but it won't have nearly as many users to deal with on each invocation. It'll also be way more predictable.

    Another thing you could do is switch the service to using Amazon EC - this fits much better with your burst model, so that you can reserve 10-20 machines for the update, then drop them all later.
  • Thanks for the comment. That is one of the ways I'm looking to solve it all. Blog post coming sometime this week detailing what I want to do, to fix Tweekly.fm.
blog comments powered by Disqus