require #{kcore}

hacks, devops, music, meme's, life, et.al @ amura

[kirannarasareddy]

rails conf india 2017!

so i spoke at the indian edition of ruby annual conference here at kochi. more info on the conference here. wonderfully managed by emerging technology trust. 

anyone wanting to ask or know more, please feel free leave your comments below. as promised you can find my talk here.

later aligator! 

[kirannarasareddy]

a balancer to manage your background jobs in rails!

well well, hello again! today seems to be a good day to post something - its been exactly 2 years since i started this blog & i think I have just the right hack that should help quite a bunch of you guys. 

I know most of you rails developers must've heard (and used as well) about Sidekiq. Its the best option for people who want reliable background processing ability in their applications. Sidekiq is extremely simple to setup and get started (requiring just redis as its datastore). Now lets assume a hypothetical situation - you have two type of tasks that you want to put in background mode - email notifications & daily report computations which are really long running reports. It's usually normal if you run both of them in the "default" queue when you are just getting started and it works as well without any issues.

Fast forward a few months -  your app has grown and so has the time taken for the report computation job to finish (with more data comes more computation cycles!). What this in-turn leads to is - your workers are occupied in generating these long running reports, whereas the jobs for email notifications are getting queued. Its okay if the emails aren't time sensitive; but if they are (like password reset email), then its an issue. You can obviously keep on spawning more workers, but it isn't scalable. Sidekiq to the rescue (not resque:P) here again! - you can just go ahead and create a different queue for your long running reporting jobs. What you are essentially doing is - creating 2 sets of workers; one who just keep on sending emails and the other who just work on generating reports. This way you can keep on scaling each set of workers individually depending on their individual load. you are sorted and happy!

Fast forward a few more months - your app is showing huge spikes during certain hours during which you are seeing lot of user activity leading to huge outflow of emails. your current set of workers are quite sufficient to handle the usual email flow, but during these peak hours, they just aren't enough. This leads to 2 things - users experiencing delayed responses from you and your redis might overflow due to large number of jobs being queued & stored if its size is relatively small( worst case scenario; but trust me it happens! personal experience:P) you can obviously spawn more workers for the time being, but you even have to kill them after the spike because well - they are idle doing nothing but eating your resources and increasing your infra bills.

We faced this very issue in our product (Sell.Do) wherein we saw huge temporary spikes for couple of minutes for which we could clearly see the need for more workers to handle the flow. During the initial days it was okay to manually write a script which would login to the server and spawn more workers. But it isn't really viable on a recurring basis for couple of reasons - what about weekends? and also major being we hackers hate doing stuff manually when it can be automated. and guess what - i wrote a sidekiq queue balancer which does this automatically for me!

It essentially uses a set of sidekiq apis & checks for size of a particular queue and its latency; compares it with healthy set of values expected for that queue (you might be okay if latency for welcome emails is upto 10mins, but password reset emails need to be sent within 60seconds). If it finds any mismatch - it spawns new workers which start draining your queue. Once the queue is within healthy limits, the manager again removes those extra workers and maintains a minimum set of workers which you have configured. cool right?

You can find the gist for it here. The library is still very young- there are many changes, optimisations (moving the config of queue meta data to an yml file etc) to be done. Feel free to write back if you have any doubts or need more help understanding it!

catch up soon! kcore out

[kirannarasareddy]

when mongoid .first slows you down

"How soon not now, becomes never" - says Martin Luther and it perfectly describes my procrastination and ignorance towards getting back at writing. so here it is. 

we use mongodb as the datastore for our product (sell.do). coming from an activerecord background (yes rails, yayy!!), most of us almost blindly use {model}.first/last to find our expected result and it (almost always) works without any issues. and then suddenly one fine day you start experiencing degraded response times in production and your good friend newrelic points out that your database is the culprit (well its you :P). 

indexing and pro-active database profiling is of utmost importance for any application. given our dataset size (our largest collection has > 22 million documents), we had made sure we covered our queries (read more about query coverage here) with good indexes and expected blazing fast performance but no :\

on closer examination, we noticed that mongoid quietly inserts a "$orderby"=>{:_id=>1} whenever we did User.where(******).first (or lack of better resource name). wow, where did this come from? (existing bug raised with mongo) well you don't really care about it initially but trust me sorting (specially when not required) can lead to lot of slow long running queries when you have huge collections. on digging further, we found that in version 2.4 the optimizer can't use the indexes we set, if a $sort or $orderby is mentioned in the query but not specified in the index. changing our query pattern to User.where(******).limit(1).entries.first avoided the unnecessary sort operation (which we didn't really need anyways) and started using the index again. 

... and the world was back to normal :P

ps: here's quick way to analyse the queries in rails console. Thanks Steve McHail!

# This initializer adds a method, show_mongo, when running a rails console. you can include it in a file in your config/initializers folder. When active, all # moped commands (moped is mongoid's mongodb driver) will be logged inline in the console output. # If called again, logging will be restored to normal (written to log files, not shown inline). # Usage: #     > show_mongo if defined?(Rails::Console)    def show_mongo        if Moped.logger == Rails.logger            Moped.logger = Logger.new($stdout)            true        else            Moped.logger = Rails.logger            false        end    end    alias :show_moped :show_mongo end

[kirannarasareddy]

#stoploss - knowing when to stop

we humans have this uncanny tendency to continue doing-something / hold on to something / someone that is close to our hearts. somewhere deep down, we  feel that we can solve the problem at hand if we just attempt it one more time. well, if you see since kindergarden, we have been taught not to accept defeat, or give up easily - with proverbs (try and try till you succeed) and tales (king arthur and spider), et.al

not to sound narcissist, but i do think that we need to learn to draw the line somewhere. be it a computer science problem that you are solving, or you are trying to make it work with someone you care [ won't elaborate on relationships  given their complexity. lets accept it - we tend to think more from our heart and not our brains in these situations. no logic applies there! ]

knowing when to stop is equally important as knowing that you need to work harder to solve the task at hand. Stock brokers call it stop loss, silicon valley vc's call it pivoting. experience will be your friend here. you wont get it right the first time, but with each attempt, you will learn to gauge yourself better, know your limits.

there is and always will be the risk / fear which will make you think you are not pushing yourself to the best of your abilities. i say you should, every single time; push till it hurts, but no more than that. whenever you are stuck, take a break; step back, analyse, see what can you do better, take help from your colleagues, friends, family. live to fight another day. 

learn to stop. learn to let go.

PS: not a seasoned writer; please excuse brevity and grammar 

[kirannarasareddy]

wit is educated insolence

Aristotle

[kirannarasareddy]

#letsgetstarted

been a while since the idea of penning my thought(s) was lurking around at the back of my mind. after much contriving, here it comes.

about me: during weekdays, you can find me hacking things at amura, with my headphones on. weekends are mostly spent strumming some strings, having gourmet brunches and going on long drives. when not in office, you will find me helping friends with their startups - tech, validation of ideas, monetisation (and sometimes their hot-fixing their personal websites as well)

what you can expect: quick hacks in ruby, databases, nosqln', devops,  music, memes, my 2 cents about dealing with people (the fun part!) and some interesting facts as well.

what you shouldn't expect: revolutionary inventions (trust me everything you need is already out there. learn to look around. this might help), solution to global warming, tips to avoid ebola, intergalactic stories.

stick around; you might find something useful for yourself. 

btw, while narrowing down on tumblr, found a bunch of simple yet beautiful blogging sites out there which you might want to take a look at (svbtle, ghost et.al )