The 'what we had and what we did and how it worked' structure worked well. As mentioned above some contentious ideas (my main takeaway was 'don't use a framework') and it might have been good to explore some of the broader pro's and con's.
A very good subject and slightly controversial when most would turn to a framework for every project - this just highlights how a framework isn't always the right solution.
Certainly a thought inducer but did come away wondering: "why not slim, silex or yaf?"
Interesting talk, well delivered. Was nice to get an insight into how a big company solves their performance issues. I think the approach is a little extreme for most and may come at the cost of easily readable, maintainable code but when speed is everything I can see it being useful.
Thought the start of the talk perhaps didn't flow as well as it could have but got a lot better as things got going. Interesting talk, highlighting just how much of an overhead frameworks can have. Was good to see examples from a real world problem and would like to see talks on other backend and front end areas to see what else was done to speed things up.
I nice peek inside the doors of a company that have to deal with real scaling and performance issues. I would liked to know a little bit more about the framework and what it can do. Good presentation style - glad I went.
Good talk and confirms what I thought about the performance overhead of using frameworks. Especially liked the bit about being presented with a Swiss Army Knife to chop down a tree when all you need for the job is an axe.
This was both interesting and controversial talk at the same time. I loved the part where the challenge gets to the level where you need to limit your caching because it's too slow. And of course everyone can relate to the part "less code runs faster".
What I missed though, was a defense of the chosen solution in comparison to alternatives (e.g. Varnish cache the page for 1 second - that serves 1499 requests off the cache).
Also, while cache was mostly disregarded, the use of NoSQL in the middle was in fact a data cache. Then if you are caching data, why render the view on every request? Why not cache the rendered view?
In summary, this gave a lot of topics for discussion afterwards. But I think this may be somewhat irrelevant or even distracting for people who are not aiming for 10ms responses.
Good talk. Dan tells you that pretty code isn’t always good code. Also, the code samples and war stories reminded me of a past life working for an online gambling company in their web department!
It was nice to find out about the different challenges faced when trying to get 1000's requests per second, and possible solutions.
I found it odd that they didn't move to a NoSQL solution but it was interesting to see the thinking behind some of the decisions made.
Great case study, interesting talk, some information and practices that can be taken away into everyday despite the talk being about a very specific problem. Without sounding too much like a manager I would love to have seen some metrics on how effective the rebuild was in terms of $$$!
Interesting talk would be good to know in more detail how Dan build's his stats and graphs used in the presentation (I do remember a question on this, but can't remember the answer).
Interesting talk and it would be good to know, in more detail, how Dan builds his stats and graphs used in the presentation (I do remember a question on this, but can't remember the answer).
It was interesting to see the approaches that had been taken to rethink the architecture with a completely performance-focused mindset. Obviously a very specific case study, but there were things that could be taken from this and applied to other similarly performance-driven applications. The speaker seemed to grow into the talk after a slightly disjointed introduction.
Cheers for the feedback guys; much appreciated. I'll try and answer some of the questions that have come up here.
1s varnish cache: Would only save 1499 requests if they were all identical (they aren't). Most pages are personalised to some degree and some things arent cacheable at all (account queries, betslip, login, API requests etc) so the effectiveness of the cache would be extremely limited.
Readability/Maintainability: On the contrary! We've found the stripped down, simple approach has made everything much more readable, maintainable, flexible and quicker to write.
Other frameworks: For sure there _may_ be a framework out there that would be a good fit in terms of raw performance but we only assessed a limited number before giving up. Also how a framework scales is a bit of an unknown and not something that is widely talked about. We probably wouldn't find out that a framework scales badly until it's too late. We weren't willing to gamble the future of our products on this.
Mongo is a cache: Depends on your definition. It is not a traditional time-based cache as the data in it is always bang up to date. I consider it as an optimisation to our order of execution!
$$$: Can't go into specifics but the project has realised a full return on investment 12 months after starting (not finishing!) the project
Stats: A combination of JMeter, log files, Splunk and Graphite
The presentation was in a different style to many of the others I attended, but was all the more beneficial for it. The we-had-a-problem-and-developed-a-solution was a nice real-world demonstration of how to approach a problem and then find a better/best solution.
The reasoning behind design decisions too was helpful, as usually they're presented as as "do this because I say so".
Comments
Comments are closed.
Really interesting talk, some good (if not contentious) ideas, will be implementing some on my own projects.
The 'what we had and what we did and how it worked' structure worked well. As mentioned above some contentious ideas (my main takeaway was 'don't use a framework') and it might have been good to explore some of the broader pro's and con's.
Interest talk, good speaker.
A very good subject and slightly controversial when most would turn to a framework for every project - this just highlights how a framework isn't always the right solution.
Certainly a thought inducer but did come away wondering: "why not slim, silex or yaf?"
Overall a good subject well delivered.
Interesting talk, well delivered. Was nice to get an insight into how a big company solves their performance issues. I think the approach is a little extreme for most and may come at the cost of easily readable, maintainable code but when speed is everything I can see it being useful.
Thought the start of the talk perhaps didn't flow as well as it could have but got a lot better as things got going. Interesting talk, highlighting just how much of an overhead frameworks can have. Was good to see examples from a real world problem and would like to see talks on other backend and front end areas to see what else was done to speed things up.
I nice peek inside the doors of a company that have to deal with real scaling and performance issues. I would liked to know a little bit more about the framework and what it can do. Good presentation style - glad I went.
Good talk and confirms what I thought about the performance overhead of using frameworks. Especially liked the bit about being presented with a Swiss Army Knife to chop down a tree when all you need for the job is an axe.
This was both interesting and controversial talk at the same time. I loved the part where the challenge gets to the level where you need to limit your caching because it's too slow. And of course everyone can relate to the part "less code runs faster".
What I missed though, was a defense of the chosen solution in comparison to alternatives (e.g. Varnish cache the page for 1 second - that serves 1499 requests off the cache).
Also, while cache was mostly disregarded, the use of NoSQL in the middle was in fact a data cache. Then if you are caching data, why render the view on every request? Why not cache the rendered view?
In summary, this gave a lot of topics for discussion afterwards. But I think this may be somewhat irrelevant or even distracting for people who are not aiming for 10ms responses.
Good talk. Dan tells you that pretty code isn’t always good code. Also, the code samples and war stories reminded me of a past life working for an online gambling company in their web department!
It was nice to find out about the different challenges faced when trying to get 1000's requests per second, and possible solutions.
I found it odd that they didn't move to a NoSQL solution but it was interesting to see the thinking behind some of the decisions made.
Great to learn about how other companies go about solving these issues.
Great case study, interesting talk, some information and practices that can be taken away into everyday despite the talk being about a very specific problem. Without sounding too much like a manager I would love to have seen some metrics on how effective the rebuild was in terms of $$$!
Fascinating case study and well presented.
Interesting talk would be good to know in more detail how Dan build's his stats and graphs used in the presentation (I do remember a question on this, but can't remember the answer).
Interesting talk and it would be good to know, in more detail, how Dan builds his stats and graphs used in the presentation (I do remember a question on this, but can't remember the answer).
It was interesting to see the approaches that had been taken to rethink the architecture with a completely performance-focused mindset. Obviously a very specific case study, but there were things that could be taken from this and applied to other similarly performance-driven applications. The speaker seemed to grow into the talk after a slightly disjointed introduction.
Cheers for the feedback guys; much appreciated. I'll try and answer some of the questions that have come up here.
1s varnish cache: Would only save 1499 requests if they were all identical (they aren't). Most pages are personalised to some degree and some things arent cacheable at all (account queries, betslip, login, API requests etc) so the effectiveness of the cache would be extremely limited.
Readability/Maintainability: On the contrary! We've found the stripped down, simple approach has made everything much more readable, maintainable, flexible and quicker to write.
Other frameworks: For sure there _may_ be a framework out there that would be a good fit in terms of raw performance but we only assessed a limited number before giving up. Also how a framework scales is a bit of an unknown and not something that is widely talked about. We probably wouldn't find out that a framework scales badly until it's too late. We weren't willing to gamble the future of our products on this.
Mongo is a cache: Depends on your definition. It is not a traditional time-based cache as the data in it is always bang up to date. I consider it as an optimisation to our order of execution!
$$$: Can't go into specifics but the project has realised a full return on investment 12 months after starting (not finishing!) the project
Stats: A combination of JMeter, log files, Splunk and Graphite
HTH
Dan
Very interesting talk, great to hear the reasoning and the process you've followed to get to where you are.
The presentation was in a different style to many of the others I attended, but was all the more beneficial for it. The we-had-a-problem-and-developed-a-solution was a nice real-world demonstration of how to approach a problem and then find a better/best solution.
The reasoning behind design decisions too was helpful, as usually they're presented as as "do this because I say so".