I’ve never used python except for a couple of occasions where I had a play on some CLI batch processes to see how I coped in a language I didn’t know.
I have been looking for another open-source to get involved with again before I go to /dev/fort this August. The obvious choice for this was spacelog.org.
Continue reading →
Posted in Development
Tagged django, python
Lindsey and Alex have gone away for a couple of days, leaving me with some alone time to work on hacking projects.
Alex’s Mobile: the wood work has been assembled, and now needs some varnishing before I put all the electronics in. The electronics has been moved from a breadboard to full soldered vero board.
On the Contraptor front, last night I built all the linear bearings, linear rails and sliding elements and almost completed all the shaft mounts.
Tuesday’s are normally London Hacker Space meetups, but tonight, I shall forgo the cheese and booze and carry on working at home.
I’ve added a new section to my projects pages, and put a page in place for the baby mobile I’m creating for Alex.
I’ve back dated a load of the updates, as I’d been meaning to post blog entries about the work, but hadn’t gotten round to it.
So far I have a 3d design worked out a working prototype circuit and a full breadboard circuit also designed.
I’ll try and put up some full photo’s soon and maybe even some video of the prototype.
I got word from the Contraptor team the other day.
My Contraptor kit has been shipped, and should be with me shortly.
The team had some issues with the initial run of kits, so I’m getting a Beta set, and they will ship me a corrected version, when they get the fabrication issues sorted out, at their cost. (Kudos to them, thanks guys!)
Today Facebook launched their new privacy settings and forced all their users to update their settings.
We noticed at Yahoo! that we were started to get lots of timeouts from Facebook’s APIs that we use on the Yahoo! homepage.
I’ve not heard anything official from Facebook yet, so this next part is all speculation.
I suspect that as a user updates their privacy settings, as forced to the first time they hit facebook.com now, Facebook flags that users account is dirty (something changed) and purges the cache of the users stream data.
Now that the cache is empty for a particular user, when a friend of that user views Facebook, the backend servers must go back to the master data source and confirm permissions on what is visible before it is displayed.
That is fine when you have a few users updating their permissions, if however you force ALL your users to do this, you site rapidly becomes overwhelmed, as you effectively removed your cache. This effect is known as “The Thundering Herd”.
As the load increases, due to all extra requests for data that would normally be handled by caches, you start to get race conditions as requests return and try to populate the cache. Also as the load increases, requests start to take longer as connections are kept open while backends are queried. Because connections are being kept open, the server stops handling requests, as there are no more connection slots and you start to get errors as clients can no longer connect.
How do you prevent this. Don’t push changes that require you whole userbase to update their records at once. Stage the release, starting with 1% until you can guage how much load it will generate on your servers. Then you can safely ramp up your change safely.