On Generating TwitStamps
If you could care less about what kind of technology powers TwitStamp, be sure to check back soon for a sneak peek at the next version!
At the moment of writing, the generation engine behind the scenes at TwitStamp runs 1964 lines of code, including the templates for all the themes. Not bad at all, but that can certainly be improved. That’s a task to be completed before the launch of the next version.
However, that’s for another post. This post is focused on how exactly TwitStamps are generated. First, some hard numbers:
- It takes less than a second of CPU time to generate non-card TwitStamps
- After this, TwitStamps are cached for 15 minutes, creating essentially only minor CPU load and I/O load on the disk. This eliminates a huge amount of our CPU utilization, as the great majority of TwitStamp generations are coming from a small number of stamps requested continuously.
- TwitStamp runs stable with room for growth on a single box with 512MB RAM (around 300MB used at any given time) and around 2% average CPU utilization.
- We serve about 150GB of data per month, mostly TwitStamps.
- We’re running your basic LAMP stack with CentOS, Apache, MySQL, and PHP.
So while we’re not that big, resources are definitely limited and we try to make our code as efficient as possible.
As the request is made to the webserver, Apache internally redirects to the generation code. This code first connects to Twitter via an API wrapper, then determines what type of stamp the user is requesting. If it matches a valid type, it loads in the code for that type. Each type of TwitStamp has unique code, which allows us to easily differentiate between Latest, Single, Card, and soon: Custom. It also allows us to create new types while only modifying several lines of code in the existing codebase.
These types then call the wrapper to pull in a tweet. They then, if applicable, pull in theme variables from additional files (or in the case of custom stamps, from an SQL database). Again, this allows us to create new themes without modifying the existing codebase at all.
From this point on is the secret sauce of TwitStamp. After the necessary information in pulled from the Twitter API, we use a combination of PHP’s built-in GD image library wrapper and our own functions to piece together a TwitStamp, which is then placed in cache and displayed to the user. This is where the most opportunity for refactoring code lies.
Sound confusing? We certainly think so, which is why we’re always looking to improve our code to be both easily maintainable and efficient.
We plan on rewriting the Twitter API wrapper into our own class which will include only the necessary code for pulling data from the API and manipulating it for use in a TwitStamp.
Thanks for supporting TwitStamp, and we hope you’ll find our next post a bit more exciting!
