The Migration From Erlang To Otp A Case Study Of A Heavy Duty Tcpip Clientserver Application

  • 1,857 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,857
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
63
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. The Migration from Erlang to OTP A case study of a heavy duty TCP/IP client/server application Francesco Cesarini [email_address] Mickaël Rémond [email_address]
  • 2. The Product...
    • IDEALX runs in-house customer projects
      • Based on Open Source components
      • develop what is not available
      • release reusable applications on their site
    • Develop an Instant Messaging Server
      • For one of the largest French ISPs
      • Handle 10,000 simultaneous users
      • Based on the Jabber protocol
      • Scaleable during runtime
      • Allow flexible addition of services
  • 3. The Product...
  • 4. Building the Prototype.
    • A team of 4 software engineers
    • Erlang Knowledge
      • All self-taught
      • Had been active in in-house Erlang projects
      • Used the erlang-questions mailing list
    • They had a working prototype in 5 weeks
      • Handled 900 simultaneous users
      • Had performance and reliability problems
    • Delivered to an impressed customer
  • 5. Building the Prototype.
    • Decide to take in external help
      • Code & Architecture review
      • Improve performance
      • Explain OTP behaviours
    • The code review showed
      • Well written code
      • Little use of higher order functions
      • Lots of unnecessary concurrency
      • NO OTP behaviours or design principles!!
  • 6. Building the Prototype. multiplexing multiplexing de-multiplexing de-multiplexing state/error handling users sockets listener sockets
  • 7. How could they miss OTP? How do I apply object oriented design in Erlang? Mickaël Rémond Joe Armstrong You do not need to apply OO design as Erlang has something more powerful called behaviours!
  • 8. How could they miss OTP?
    • The name Open Telecom Platform
      • They were developing XML based products
      • They were developing products for ISPs
      • They were not developing telecom products
    • They did not find the documentation
      • Relations between behaviours not evident
      • No tutorials
    • Found very few OTP examples online
  • 9. To the Rescue!
    • OTP training: 2.5 days
      • Only behaviours were covered
    • Code review: 1 day
    • New system architecture design: 0.5 days
      • No documents necessary
    • ‘ Code rewrite’ examples: 1 day
      • Using higher order functions
      • How to remove deeply nested cases
      • Bit syntax, etc.
  • 10. To the Rescue! multiplexing multiplexing de-multiplexing state/error handling users sockets listener de-multiplexing sockets supervisor simple 1-1
  • 11. To the Rescue!
    • 25 days work from prototype to product
      • Included training, redesign, rewriting, testing
    • Code reduction of 50%
    • Free goodies from OTP
      • Restart strategies, application control, etc.
    • Problems
      • Limit of TCP connections per Unix process
      • One listen socket for many Erlang nodes
      • Windows NT database performance
  • 12. The Moral of the Story.
    • OTP design principles and behaviours fill a gap that existed in pure Erlang
      • Structuring of programs
      • Reuse of Code
      • Methodology
      • Development strategy
    • For some one downloading Erlang/OTP off the web, finding/understanding design principles and behaviours is not obvious/easy.
  • 13. The Moral of the Story.
    • We who work with OTP should promote it better
      • Advantages
      • The gap it fills
      • More and better examples
      • Help existing open source projects
    • Hopefully, this will result in others not doing the same mistake
      • Happy users = Many users
      • Many users = Fun user conferences