Ugly, static, non-interactive.
Tons of dynamic content, messaging, real time API and content for the user.
XMLHTTPRquest EventSource WebSocket * SPDY * (http on steroids, 1 connection many asynch calls)
Built for bringing content directly to the user.
Efficiency, Concurrency, Availability.
Low latency Low bandwidth footprint Low memory footprint
High number of concurrent connections True concurrency, all connections have the same weight No loss of latency dues to and expensive connection No loss of latency due to many connections Same performance regardless of number of connections
Isolation Concurrency Failure detection Fault identificiation Live code upgrade (hot deploys) Stable storage
Efficiency requires concurrency Concurrency requires availability etc....
Built for concurrency, gives you all the things for free.
People don't share memory People evolve concurrently People communicate via messages People die, for a reason we can identify The world keeps turning when they do.
Erlang is like real life for processes. Uses the actor model.
Erlang features pattern matching Error handling is straightforward, let it crash. Application design depends on how you want processes to fail. Your system becomes failure-safe, even from your own bugs.
Code is sequential Asynchronous code is hidden by a module API Language is very small and easy to understand Modules are written in a top-down fashion
Its almost the same code for 1 or 2 or 1000 nodes It's the same code to handle local or remote faults or netsplits
Accept connection, request, head, do stuff, respond
Cowboy does this. Accepts connections concurrently in separate processes Requests are handled concurrently. It's efficient.
Tool breaks before you can measure the efficiency of Cowboy. Siege doesn't scale to 1000 connecitons.
Always check your benchmarks, the bottleneck might be in the client or elsewhere.
Can benchmark from many clients. Can spool up to 5k clients in 27s. Can be run on cheap hardware.
Massive number of clients, results stay basically the same. 100% availability.
Erlang is maybe no the best for serving files.
You can use Cowboy with your existing apps. There are tools for Rails and PHP to dispatch requests to cowboy for some things. Experimental.
Erlang and Java scale well for WebSockets. Very low latency for upto 10000 connections.
1 milllion active Cowboy websocket connections on EC2 Takes 20GB of RAM 20kb per connection Latency was the same throughout scaling.
Cowboy has not been optimized yet! Erlang isn't magic.
Erlang release runs on the VM Releases contain applications Applications contain processes
Each connection is its own process Each session is its own process Session is kept inside the process Live events are kept in the session process Cache is internal Very few database and filesystem calls
Design for availability. How do you want the application to fail? Protect core services, let outer layers fail. Results in focused services that do one thing well. Speed and efficiency are a side effect of the design.
this http layer makes calls to services services are live processes, not a model library services can be on any node connection processes wait for replies connections do not prevent other connections from running
Remove bottleneks Distribute responsibility Let it crash! Reduce disk and network access Measure it!
4 profilesrs, 2 debugging interfaces, 3 trace interfaces can peek into running processes tons of stats and more.....
MVC Caches Messaging servers (Erlang does this) Overtime (ha!) app will restart on crash
learnyousomeerlang.com cowboy erlang on irc etc....