Phoenix is a web framework written in Elixir that efficiently manages long connections for scalable real-time applications, inspired by WhatsApp's server architecture. It utilizes Erlang's capabilities for distributed systems and allows each HTTP request to operate in separate, isolated processes, enhancing performance and avoiding resource blocking. The framework facilitates horizontal scaling and offers productivity tools, making it a competitive alternative to frameworks like Node.js and Rails.

1. Phoenix a Rails successor
INTRODUCTION TO ELIXIR AND ITS POWERFUL WEB FRAMEWORK
Tanuj Soni | mail@tanuj.in
1

2. What is Phoenix?
It’s a web framework that is written in Elixir
programing language and runs on Erlang
virtual machine.
2

3. How does it came to existence
Chris Mccord (the creator of Phoenix) was working on a realtime application
in which clients had to open long connections with the server and needed to
have data flowing full duplex mode.
And developing scalable realtime applications was hard because the clients
will maintain long connections with server and will block the resources of the
server till the connection ends.
While he was trying to figure out the problem he heard WhatsApp case.
WhatsApp guys were maintaining 2 Million connections on a single machine.
Blog post describing the case..
http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/
3

4. WhatsApp Server configuration
Intel(R) Xeon(R) CPU X5675 @ 3.07GHz
24 CPU Cores
96 GB RAM
Only 40% of RAM and CPU were utilized…..
4

5. ● It was designed by Ericsson for its
telecommunication systems in 1986.
● It’s Distributed, Fault-tolerant and Hot swappable
language. These features met all telecommunication
requirements.
5

6. ● Elixir is a functional, concurrent, general-purpose programming language
that runs on the Erlang virtual machine (BEAM).
● José Valim is the creator of the Elixir programming language, a R&D
project of Plataformatec. His goals were to enable higher extensibility and
productivity in the Erlang VM while keeping compatibility with Erlang's tools
and ecosystem.
● José added a lot of syntactic sugar to make look similar to Ruby.
Ref- https://en.wikipedia.org/wiki/Elixir_(programming_language)
6

7. 7

8. 8

9. 9

10. 10

11. What is new in that?
Isn't that’s similar to Node or EM Websocket Ruby?
11

12. The difference is about scaling!
● The clock speed of newer CPUs are not getting faster
instead they having multiple cores.
● Ruby and Node both are not able to utilize the
resources in a way these are utilized by Elixir.
● As we have seen the WhatsApp case we know the
Elixir can scale vertically and it scales very well.
12

13. So what happens if we can not further
scale vertically?
13

14. 14

15. We start scaling it horizontally
● If a single powerful machine is not capable, we can simply turn on another
machine and tell this new machine how to find other machines.
● Erlang is distributed so is Elixir as the system is designed around message
passing, the Erlang VM abstracts the message passing in a such a way
that it doesn’t matter if the recipient of the message is in the same
machine or in another node in the same network.
15

16. Scaling vertically by adding more powerful hardware
was a thing of the past. We scaled horizontally, by
adding more commodity hardware. With the coming of
age of mega-core architectures, we have the choice of
either adding more hardware or more cores, or both.
Erlang style concurrency puts Elixir/Phoenix ahead of
the game when it comes to scaling with both
approaches.
16

17. 17

18. 18

19. ● Whenever a socket is initiated a new process is
created to handle it. Don’t worry the are Erlang virtual
machine processes not operating system processes.
● And for every channel that is created within this
channel separate processes are created.
● Erlang VM processes are very isolated that means a
buggy or faulty channel will not affect any other thing
in the system.
● All the processes are concurrent so none of the
process is going to block anything in the system.
19

20. Problem with Node
Despite its asynchronous event model, by nature it is
single threaded. When you launch a Node process, you
are running a single process with a single thread on a
single core. So your code will not be executed in
parallel, only I/O operations are parallel because they
are executed asynchronous. As such, long running CPU
tasks will block the whole server and are usually a bad
way to do things.
20

21. Problem with Rails 5 ActionCable
One of Rails screencast suggested that “You should
not do any processing in action cable channels
because they are not concurrent , if you do they will
block everything.” and that is true.
What Rails actually does is that it puts the actions in a
queue after some time it will be fetched, processed
and broadcasted afterwards.
21

22. This was a brief introduction about
how it came to existence.
22

23. With Elixir Phoenix we can be as
much productive as we were with
Rails best part is that the
developed things are going to be
multiple times efficient.
Let’s see other benchmarks and
features of Phoenix.
23

24. The Road to 2 Million Websocket
Connections in Phoenix
● Phoenix guys started to benchmark the framework developed on a 128GB
RAM and 40 cores.
● And they were able to open 2 Million connections using 80 GB of RAM.
CPUs were ideal as none of the data was flowing.
● They broadcasted a Wikipedia article to 2 million connection and it took
only 3 seconds.
Ref-
http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-
connections
24

25. 25

26. 26

27. How regular applications benefit from
Elixir Phoenix?
Phoenix allocates a separate
dedicated Erlang VM process for
every http request and serves
them concurrently.
27

28. 28

29. ● Data for each request is isolated.
● Garbage Collector is per process based.
● Most of the time it is not required to Garbage collect as once the request is
served the data is scraped, no GC is required and this also saves the CPU
cycles.
● Node, Ruby, Python have global GCs and when the servers starts getting
heavy load the GC starts running very frequently that increases the
response time of requests.
29

30. ● Ref- https://github.com/mroth/phoenix-showdown
30

31. Productivity
➢Short-term Productivity
- Documentation/Guides
- Workflows/Generators
➢Long-term Productivity
- Introspection
- Maintainability
31

32. 32

33. Generators
mix phoenix.gen.html
mix phoenix.gen.json
mix phoenix.gen.channel
These generates highly documented code.
33

34. Some more development addons.
● Live Reloads.
● ES6 as default.
● Pretty error pages.
● Concurrency test tools.
● (HEX) Packages and dependency resolution tool.
● Uses all cores for compiling code.
● Uses all cores to run tests.
● Debuggers: IEx.pry, Debugger(GUI).
34

35. 35

36. Observer Tool
Observer allows us to open multiple windows with information on the whole
system's statistics or even an individual process of that running system.
It makes it easy to identify the bottlenecks of the application just by looking in
to the stats of resources consumed by multiple processes.
We can simulate an error by manually killing process or by killing DB
connection pools.
36

37. Related links
● https://github.com/h4cc/awesome-elixir
● https://hex.pm/
● https://github.com/doomspork/elixir-companies
● http://elixir-lang.org/docs.html
● https://hexdocs.pm/phoenix/Phoenix.html
37

38. Tanuj Soni
mail@tanuj.in
https://www.linkedin.com/in/tanujsoni
38
Contact me on the below details for any question or
suggestion.