Choosing between simple_one_for_one and one_for_one restart strategy in OTP

72 views
Skip to first unread message

David Harris

unread,
May 5, 2014, 6:34:16 PM5/5/14
to erlware-...@googlegroups.com

I'm looking to build system that runs a client for a particular protocol (say for example, FTP) as a supervised Erlang/OTP process. I should have 1000's or even 10's of thousands or more of users. Each client will invariably connect to a different external IP address and at various times execute different protocol functions. In other words, effectively, users operate a client program via my service rather than using their own device. 

I'm not sure whether to use simple_one_for_one or one_for_one as my restart strategy. From what I've read simple_one_fpr_one can more quickly handle lots of users that can be added dynamically but they all have to be a single type of child: one_for_one is more flexible but keeps a record of each child & my concern is that if I have 10,000+ users would a one_to_one supervisor struggle? Or be too slow? 
If my client code all relates to a single protocol but each user is 'doing their own thing', e.g. executing a LIST/CWD, command would that stop me using simple_one_for_one? Obviously each different protocol would need a different supervisor.


Jordan Wilberding

unread,
May 15, 2014, 6:10:52 AM5/15/14
to erlware-...@googlegroups.com
David,

First of all, sorry for the delay in responding, your message was stuck in spam review.

Without knowing a little bit more it is always hard to say what the best answer is, but I can try to provide some guidance and my opinion. I am sure Eric and/or Tristan will chime in, too.

While 10,000+ users certainly is a decent amount, it is by no means huge in the world of Erlang. You should safely be able to handle that with a simple_one_for_one. From the way you described things, you probably just need a connection pool that is connecting to your backend stuff, then a simple_one_for_one app that arbitrates the service.

General principles of distributed systems also apply to Erlang. The most important thing is to keep it simple and not optimize until you need to. The second is to use spikes (http://www.extremeprogramming.org/rules/spike.html) to test your hypothesis. In this case I would write a quick Erlang app as described above and do some load testing with something like Blitz.

Thanks!
Jordan Wilberding


--
You received this message because you are subscribed to the Google Groups "erlware-questions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to erlware-questi...@googlegroups.com.
To post to this group, send email to erlware-...@googlegroups.com.
Visit this group at http://groups.google.com/group/erlware-questions.
For more options, visit https://groups.google.com/d/optout.

Martin Logan

unread,
May 15, 2014, 4:54:35 PM5/15/14
to erlware-...@googlegroups.com
Here is a good article from Tristan on that subject: http://kungfooguru.wordpress.com/2009/08/05/erlang-simple-one-for-one-supervisor/
--
Martin Logan
Erlang & OTP in Action (Manning) http://manning.com/logan

Martin Logan

unread,
May 15, 2014, 4:56:28 PM5/15/14
to erlware-...@googlegroups.com
BTW - if you come from the OO world a simple one for one can be thought of like a factory. You use when you want to create a ton of processes that have the same behavior but different state. 
Reply all
Reply to author
Forward
0 new messages