It started with too many processes
A great proof of how valuable NeverBlock is happend just a little while ago. Alsaha.com is one of the oldest forums in the middle east. Lately, I helped rebuild the whole thing and move it to Ruby on Rails while I was at eSpace, my previous employer.
A great proof of how valuable NeverBlock is happend just a little while ago. Alsaha.com is one of the oldest forums in the middle east. Lately, I helped rebuild the whole thing and move it to Ruby on Rails while I was at eSpace, my previous employer.
Many web users rely on sites like Alsaha.com for following commentary on breaking news, thus during such events the daily page views can jump from a couple hundred thousands to millions. Add to that the fact that there are some (unavoidable) slow database operations that must be done online for the administrators.
Initially we had different web server instances for the normal users and administrators to avoid stalling Rails processes on long running queries. All in all, since we had a capable back end, we coupled it with a formidable number of Rails processes as front end servers. This was the only way back then to exploit our back end's conncurency. Needless to say, this army of front end processes consumed lots and lots of memory.
Enter NeverBlock
After the initial production testing in meOwns.com, we thought of the gains we can get from using it with Alsaha, so we planned for the move and were able to drastically reduce the Rails instances count. We only use 4 now and this is for utilizing the CPU cores rather than concurrency. Those 4 processes serve all the user and administrative content. Thanks to NeverBlock, no one has to wait for the other.
The Real Test
There was a very important news item lately that resulted in a traffic spike in the order of millions of page views in a few hours. Thankfully, the NeverBlock setup easily accomodated that without noticeable degradation (actually there was some degradation attributed to a bug in the logging logic, that was quickly discovered and fixed). The small 4 instances kept up with the load even though some slow operations were running on them while they were serving loads of quick ones to lots of users.
Conclusion
I am grateful to have written code that turned out to be useful to others. I hope this would be a pattern.
Enter NeverBlock
After the initial production testing in meOwns.com, we thought of the gains we can get from using it with Alsaha, so we planned for the move and were able to drastically reduce the Rails instances count. We only use 4 now and this is for utilizing the CPU cores rather than concurrency. Those 4 processes serve all the user and administrative content. Thanks to NeverBlock, no one has to wait for the other.
The Real Test
There was a very important news item lately that resulted in a traffic spike in the order of millions of page views in a few hours. Thankfully, the NeverBlock setup easily accomodated that without noticeable degradation (actually there was some degradation attributed to a bug in the logging logic, that was quickly discovered and fixed). The small 4 instances kept up with the load even though some slow operations were running on them while they were serving loads of quick ones to lots of users.
Conclusion
I am grateful to have written code that turned out to be useful to others. I hope this would be a pattern.
Oldmoe: this is interesting, I am sure Neverblock is a fine piece of code that I am really want to explore its potential. I have some questions, First, I know that it requires ruby 1.9, does that means that Alsaha.com is running on ruby 1.9?! Second, you mentioned 4 instances/processes, do you mean 4 instances of physical/virtual application servers, or 4 processes of mongrel/thin?! if so can you give any figures on how much ram or request time you gained using Neverblock. I mean any benchmarks related to a real application like Alsaha. Thanks, and keep up the good work!
@Ibrahim: Alsaha is running on 1.8, we are using Aman Gupta's poor man's fibers for 1.8 and an older version of NB :(. The 4 are 4 Thin instances I believe that each one is able to handle 12 simultaneous connections. The processes themselves are fatter because of the multiple contexts, may be up to 50% but the application can now handle more concurrent load at around 25% of the memory that was originally used by the front end processes.
The memory savings are a recurring pattern, one which I expect to be more profound with the move to Ruby 1.9 and proper fibers.
That's amazing, I really want to test this setup. we're currently running ruby 1.8, and rails 2.3, do you think it will be straight forward to use Neverblock. I mean, should i expect incompatibilities, or is it a drop in replacement. I know for example that Neverblock require MysqlPlus, does it requires any more dependencies?
It depends a bit on your setup, but generally it should be transparent. But the issue is, this will help you with your lengthy queries. If all your queries are fast then there is little value in introducing it. That's partially due to the overheads with 1.8. I'd recommend it fully if you are on 1.9 though.
Wow! Thank you! I always wanted to write in my site something like that. Can I take part of your post to my blog? Please come visit my site Newark Business Directory when you got time.
finds. Your outfits are always super cute too! Very inspirational. Please come visit my site Durham Business Directory when you got time.