Paolo Negri
Opensource enthusiast, developer at wooga
wooga.com
Opensource citizen kind of geek, started a career 10 years ago as a linux sysadmin, then switched to a developer profile following the emerging ruby wave. After admiring the elegance of projects like RabbitMQ or Riak he is now involved in writing distributed apps based on Erlang. He has spoken at a few international conferences and enjoys sharing knowledge and experiences.
Wooga.com
Twitter: @hungryblank
Wooga.com
Twitter: @hungryblank
Paolo Negri is Giving the Following Talks
Designing online games for scale with Erlang
At wooga we build backends for games that have millions of daily users.
In the gaming business we have a write heavy environment, with a high frequency of requests, traffic bursts and distribution across many nodes. These are all problems we need to solve and keep in mind in order to write a system that stands the chance of supporting the required load.
How do you meet the challenge of writing a brand new system with performance in mind? Where should the line between necessary efficiency and premature optimization be drawn? How do you measure performances? How do we generate synthetic load that reflects real usage patterns? How do you know you have enough capacity? How do you combine all the above with safely introducing changes and new features working in a two people team?
We had to answer to all the above questions and we want to share the solutions we found and the problems that we consider still open.
In the gaming business we have a write heavy environment, with a high frequency of requests, traffic bursts and distribution across many nodes. These are all problems we need to solve and keep in mind in order to write a system that stands the chance of supporting the required load.
How do you meet the challenge of writing a brand new system with performance in mind? Where should the line between necessary efficiency and premature optimization be drawn? How do you measure performances? How do we generate synthetic load that reflects real usage patterns? How do you know you have enough capacity? How do you combine all the above with safely introducing changes and new features working in a two people team?
We had to answer to all the above questions and we want to share the solutions we found and the problems that we consider still open.