The Architecture of Stack Overflow - Dev Sum 2014

The Architecture of Stack Overflow - Dev Sum 2014

3fd9e5b2c59170ec3d74dde30d233fa4?s=128

Marco Cecconi

May 21, 2014
Tweet

Transcript

  1. 3.
  2. 4.
  3. 6.
  4. 10.
  5. 11.

    web servers load balancers redis search database http(s) http rest

    http protobuf sql sql protobuf tag engine
  6. 12.
  7. 23.
  8. 24.

    Network Level Caches (CDN, etc.) Server Level Cache (HttpRuntime.Cache) Site

    Level Cache (Redis) SQL Server Database Cache (384 gigs of RAM!) Solid State Disk
  9. 25.
  10. 26.
  11. 27.
  12. 28.
  13. 29.

    Too Many Allocations This is really the most basic thing

    that can go wrong. Too Many Pointers If you create a data structure that is a large mesh of pointers you'll have two problems. First, there will be a lot of object writes […] and, secondly, when it comes time to collect that data structure, you will make the garbage collector follow all those pointers and if necessary change them all as things move around. […] But if you create such a structure on a transitory basis, […], then you will pay the cost much more often. http://msdn.microsoft.com/en-us/library/ms973837.aspx#dotnetgcbasics_topic2
  14. 30.

    Too Many Allocations This is really the most basic thing

    that can go wrong. Too Many Pointers If you create a data structure that is a large mesh of pointers you'll have two problems. First, there will be a lot of object writes […] and, secondly, when it comes time to collect that data structure, you will make the garbage collector follow all those pointers and if necessary change them all as things move around. […] But if you create such a structure on a transitory basis, […], then you will pay the cost much more often. http://msdn.microsoft.com/en-us/library/ms973837.aspx#dotnetgcbasics_topic2
  15. 31.
  16. 32.
  17. 33.
  18. 34.
  19. 36.

    Too Many Allocations This is really the most basic thing

    that can go wrong. Too Many Pointers If you create a data structure that is a large mesh of pointers you'll have two problems. First, there will be a lot of object writes […] and, secondly, when it comes time to collect that data structure, you will make the garbage collector follow all those pointers and if necessary change them all as things move around. […] But if you create such a structure on a transitory basis, […], then you will pay the cost much more often. http://msdn.microsoft.com/en-us/library/ms973837.aspx#dotnetgcbasics_topic2
  20. 37.

    Too Many Allocations This is really the most basic thing

    that can go wrong. Too Many Pointers If you create a data structure that is a large mesh of pointers you'll have two problems. First, there will be a lot of object writes […] and, secondly, when it comes time to collect that data structure, you will make the garbage collector follow all those pointers and if necessary change them all as things move around. […] But if you create such a structure on a transitory basis, […], then you will pay the cost much more often. http://msdn.microsoft.com/en-us/library/ms973837.aspx#dotnetgcbasics_topic2
  21. 38.
  22. 39.
  23. 42.

    ...this is what you are actually doing! IRepository<Order> repository =

    new ValidatingOrderRepository ( new SecurityRepository<Order> ( new LoggingRepository<Order> ( new CachingRepository<Order> ( new NHibernateRepository<Order> () ) ) ) ); Order order = repository.Get(35);
  24. 48.

    Few projects :-) Few lines of code :-) Awesome community

    to help :-D Eeek! very few tests :-S
  25. 52.
  26. 53.
  27. 54.
  28. 56.
  29. 57.
  30. 58.
  31. 62.

    • Performance is a feature • Always. Be. Shipping. •

    Use your circumstances. • Open source your libraries • 3 obscenely big monitors. KEY TAKEAWAYS
  32. 63.