[...] This post was mentioned on Twitter by Eric Snowden, karannnnnnnnnnn3. karannnnnnnnnnn3 said: Learnings from caching with CodeIgniter: We’re using CodeIgniter on Sofanatics as our back-end. One problem we f… http://bit.ly/eZsFZe [...]
Browsing articles from "February, 2011"
One Infinite Tunnel for iPhone/iPod Touch/iPad
One Infinite Tunnel is now available on the AppStore. Get it while it’s hot! And If you like it, please be so kind as to leave a review.
Deep in unexplored space, you’re spaceships controls brake down while exploring a massive underground tunnel complex. With just one engine working to control your tilt, how long can you survive before you smash into the hard rock?
One Infinite Tunnel features gorgeous 3D graphics, “one button” controls and, well, one infinite tunnel. Compete against the world on Game Center and OpenFeint.
One Infinite Tunnel works on all iPhones, iPod Touches and iPads.
Symbian finally rests in pieces
By now you’ve heard the news. Nokia chooses Windows Phone as its primary smart-phone OS and its stock plummets much like a man jumping off that burning platform. Finnish newspapers are concerned whether Elop still has Microsoft stock and some even go as far as to say that Nokia sold itself to Microsoft for 0$. Many say that Elop won’t remain the CEO for long and that Nokia’s days as an innovator are all but gone.
While I understand why especially many finns are so upset about the change of direction, I couldn’t disagree more. Sure it hurts throwing out a OS that Nokia has received billions of R&D money, but guess what? Symbian still sucks and nothing is going to change the fact that with Windows Phone, Nokia is finally on a path to deliver smart-phones that can actually compete in the market.
It’s simple to choose when you have a choice of selling someone else’s beef or your own shit, even if you’ve poured billions into producing that shit. And this is something that people don’t seem to grasp. Symbian is not and was never going to be a competitive OS. So it really wasn’t a choice to start with. What about MeeGo then? Word has it that its development has run into the same problem that I’ve witnessed too many times with Nokia: An army of middle managers trying to push development in different directions either to gain recognition or claim their bonuses. Nokia is doing fine on the hardware side where you have a relatively small team (and relatively few managers) for each product. But when it comes to the OS, where features need to serve the whole company and all of it’s products, the result is a fragmented, slow moving, over managed bloat of compromises. Just pick up a N8 and you’ll notice that while the hardware is excellent, the OS just makes the product frustrating or even unusable.
So I have to salute Elop and Nokia’s board for making this bold move. While it may weaken short-term sales (who wants a phone with a dying OS?), I’m sure it’ll make sense in the long-term. For the first time in many years I’m actually looking forward to see some cool new Nokia devices. Heck, I’ll probably even start developing for Win Phone myself.
1 Comment
Learnings from caching with CodeIgniter
We’re using CodeIgniter on Sofanatics as our back-end. One problem we faced was that our installation didn’t perform well enough. Sure, Amazon’s EC2 is to blame for most of this. If you look at any benchmarks out there, you’ll find that Amazon isn’t the best cloud in regards to speed / €. Nonetheless, our RightScale managed Amazon E2C instances gives us the flexibility to deliver a ha-service that automatically scales according to demand, so changing to dedicated hosting is not really an option for us.
Now, all clouds suffer from slow IO operations, and caching database queries (to Memcached in our case) of course gives you a great speed increase. But once we had cached everything we could we still didn’t have the speed we desired. Our most critical part of our API that gets bombarded very frequently during matches, we could manage to respond to 22.000 hits per minute (367 hits / sec) on one E2C Medium instance. While this really sounds sufficient I wanted to take the opportunity to check where this bottleneck actually came from.
CodeIngiter is a rather small framework and many libraries and helpers required by our app are loaded on demand. For the API call that I tested, CodeIngiter didn’t have to do much. It resolves the Controller for the given URL, does some initialization, calls the controller and instantly returns the result as a full page cache is hit 99.9% of all times. There’s no room for optimization there, and having gone through the way CodeIgniter initialized, it does this in a very efficient manner. So what can we do?
Well, I decided to skip CodeIngiter altogether. For that particular API call (and all other API calls that were hit frequently) we actually didn’t need to know anything about the calling user. We were able to include all the required parameters in the URL and everybody who hit a specific URL would get the same exact response, which was valid for at least a few seconds. So we did an override of CodeIgniter’s output-method send the data to Memcache (every front-end machine has it’s own Memcache-server for super fast look-up) if that specific call was cacheable.
Next, I send all requests to a very simple script that connected to memcache and checked if a valid cached result existed for the URL that was requested. Only if the cache was missed, would the script forward the request to CodeIgniter for execution.
The result? We got from 22.000 hits per minute to 250.000 hits per minute (4166 hits / sec). Now _that_ is a good result.
So what exactly should you take away from this?
If you need super speed, have your cache serve data as upfront as possible. Also keep in mind that PHP files are surprisingly slow to load, even if they don’t execute any or much of it’s code. In our case we were using eAccelerator, so our PHP files didn’t even need to be parsed but still, thats were most of that whopping 1100% speed increase came from.
3 Comments
-
-
A few question and a comment. When you say you run a memcached instance on every machine does that mean a cache miss populates all the frontend machines in the cluster? How do you manage memory in this case, can you actually fit the working set of cacheable pages onto a single machine?
The comment is mainly a nitpick. Your hit counts are so high that the numbers might be more easily comparable if you normalized to seconds instead of minutes. Queries per Second seems to be a common unit, probably a leftover from search engines.
-
Good point, I updated the post to show hits/sec.
All of our memcache servers run independently and have been allocated aroud 200 megs of memory. While this definitely is not your basic memcached setup where you would have one or a cluster of dedicated memcached servers serving all front-end instances this was still the best solution for our case. Our caches expire very quickly (usually in 2 seconds), so the low memory isn’t an issue. And we found that having every front-end instance run it’s own memcache locally gives us a bigger speed increase than what we loose to the fact that every front-end instance has to populate it’s cache independently.
-
Follow me on Twitter!
Other services
[...] This post was mentioned on Twitter by Eric Snowden and flash reseller, Renato Gomes. Renato Gomes said: Symbian finally rests in pieces: By now you’ve heard the news. Nokia chooses Windows Phone as its primary smart-… http://bit.ly/igvKoP [...]