8 ms·

I get that. For persistent connections, it's a life saver. But for a synchronous web service, every connection comes and goes quickly. What do you gain from att

I get that. For persistent connections, it's a life saver. But for a synchronous web service, every connection comes and goes quickly. What do you gain from attaching to the console in that situation that you wouldn't get from the rails console?

rdtsc 13y ago
If you only have a socket dispatcher and a quick request processor that servers a page and dies, then that code path is quite minimal. Now you should probably have a supervisor. Your connections could be handled by a connection or socket pool. You could have a database driver. There could be a background processing queue. Now things get interesting, not all those things get torn down and recreated on each request. Even for short lived requests you could attached to a live system and trace one of the short lived requests or set a debug point to see what it does in "slow motion" to so speak. One can use Erlang for quite a bit without touching the distribution (as in distributed nodes across many systems forming a single cluster). Then the shell can help you log in to any other node, transparently. The ability to reload code at runtime is not something many systems can boast. Because that is one case you might touch once you have found the problem, but that is again one thing you can do. You can diagnose loading and system resource utilization as well. If you have a fully-featured system (say downloaded from Erlang solutions) open the shell and type observer:start(). to start the observers. It will launch a GUI window (make sure to have X forwarding if running via SSH). There you can see runtime stats, the application tree, process list, ETS tables. For each application in the tree you can click on the process and see its state.
- phamilton 13y ago
  Thanks! That makes sense. I see it now. For the benefit of other Rails devs looking in: think about debugging issues with unicorn or passenger on a live system without interrupting service. Then think about being able to fix the code without interrupting service. That's powerful. That's not something I do every day, but I can understand why that's powerful.

rdtsc 13y ago

If you only have a socket dispatcher and a quick request processor that servers a page and dies, then that code path is quite minimal. Now you should probably have a supervisor. Your connections could be handled by a connection or socket pool. You could have a database driver. There could be a background processing queue. Now things get interesting, not all those things get torn down and recreated on each request. Even for short lived requests you could attached to a live system and trace one of the short lived requests or set a debug point to see what it does in "slow motion" to so speak. One can use Erlang for quite a bit without touching the distribution (as in distributed nodes across many systems forming a single cluster). Then the shell can help you log in to any other node, transparently. The ability to reload code at runtime is not something many systems can boast. Because that is one case you might touch once you have found the problem, but that is again one thing you can do. You can diagnose loading and system resource utilization as well. If you have a fully-featured system (say downloaded from Erlang solutions) open the shell and type observer:start(). to start the observers. It will launch a GUI window (make sure to have X forwarding if running via SSH). There you can see runtime stats, the application tree, process list, ETS tables. For each application in the tree you can click on the process and see its state.

phamilton 13y ago
Thanks! That makes sense. I see it now. For the benefit of other Rails devs looking in: think about debugging issues with unicorn or passenger on a live system without interrupting service. Then think about being able to fix the code without interrupting service. That's powerful. That's not something I do every day, but I can understand why that's powerful.