Hi everyone
I'm pleased to announce that Aaron Schulz is taking on a new role in Wikimedia Foundation's Platform Team: Senior Performance Engineer.
Aaron works on MediaWiki internals -- components that every user-visible feature depends on, but which are rarely user-visible themselves. The impact of Aaron's work on the reliability and performance of MediaWiki is felt by many, but fully known to few, so I'd like to use this occasion to highlight some of this work.
Aaron is the primary author of MediaWiki's file handling backend, job queue, its integration with Redis key-value database and the OpenStack's Swift distributed filesystem -- just to name a few of the more significant (and relatively recent) components. In addition to these things, Aaron has designed a heavily-used set of generic mechanisms for enabling concurrent access to shared resources, for breaking up big computations into smaller units of work, and for distributing those units of work across a cluster of machines that can execute it. Aaron's code plays an important supporting role in most (if not all) significant MediaWiki functionality.
Aaron's move to performance recognizes the critical role he has already played in this area, and reflects our evolving understanding of how important that work is. We are constantly striving to make the experience of using MediaWiki snappy so that editors can do their work without waiting on the software to acknowledge their actions. To meet these standards, we need to tackle performance in (at least) two areas:
1. Using data to provide a picture of how users experience the site, identifying where users encounter latency, quantifying how it impacts their engagement, and using this information to drive optimizations to the code, paying particular attention to client-side network and computational load. In making this a focal point, we are heeding Steve Souders' Performance Golden Rule: "80-90% of the end-user response time is spent on the frontend. Start there." [1] Our goal here is to ensure that the visual display of information and the reactivity of the user interface exhibit the kind of immediacy that is needed for users to focus on and engage with content.
2. Building a well-integrated set of services that, when used in the most obvious way, allows it to do as many things as possible, as fast as possible, while remaining resilient to changes in site activity. The vast majority of visits to our site never reach the backend of our stack, but the minority that do involve really critical site functions, such as all editor activity. We want the MediaWiki ecosystem to have not only the capacity to sustain current levels of activity, but to be an enabler of growth by making it possible for many more people to contribute in new ways. To meet this challenge, we need MediaWiki to be increasingly parallel, and to provide efficient, concurrent access to a rich variety of content types and storage layers.
This split maps neatly to Ori and Aaron's respective skill-sets and experience, which makes for an effective partnership. Having Aaron formally move to a performance role both recognizes the work Aaron is already doing, and it lays the groundwork for a process for meeting performance challenges that leverages their diversity of expertise.
Please join me in thanking Aaron for taking on this role!
Rob
[1] Steve Souders is formerly Head Performance Engineer at Google and "Chief Performance Yahoo!" at Yahoo. Performance Golden Rule:
http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/
Yay! Congrats, Aaron!
Does this mean we can buy you a laptop that isn't audible from Canada? ;).
On 7 April 2014 17:40, Rob Lanphier robla@wikimedia.org wrote:
Hi everyone
I'm pleased to announce that Aaron Schulz is taking on a new role in Wikimedia Foundation's Platform Team: Senior Performance Engineer.
Aaron works on MediaWiki internals -- components that every user-visible feature depends on, but which are rarely user-visible themselves. The impact of Aaron's work on the reliability and performance of MediaWiki is felt by many, but fully known to few, so I'd like to use this occasion to highlight some of this work.
Aaron is the primary author of MediaWiki's file handling backend, job queue, its integration with Redis key-value database and the OpenStack's Swift distributed filesystem -- just to name a few of the more significant (and relatively recent) components. In addition to these things, Aaron has designed a heavily-used set of generic mechanisms for enabling concurrent access to shared resources, for breaking up big computations into smaller units of work, and for distributing those units of work across a cluster of machines that can execute it. Aaron's code plays an important supporting role in most (if not all) significant MediaWiki functionality.
Aaron's move to performance recognizes the critical role he has already played in this area, and reflects our evolving understanding of how important that work is. We are constantly striving to make the experience of using MediaWiki snappy so that editors can do their work without waiting on the software to acknowledge their actions. To meet these standards, we need to tackle performance in (at least) two areas:
- Using data to provide a picture of how users experience the site,
identifying where users encounter latency, quantifying how it impacts their engagement, and using this information to drive optimizations to the code, paying particular attention to client-side network and computational load. In making this a focal point, we are heeding Steve Souders' Performance Golden Rule: "80-90% of the end-user response time is spent on the frontend. Start there." [1] Our goal here is to ensure that the visual display of information and the reactivity of the user interface exhibit the kind of immediacy that is needed for users to focus on and engage with content.
- Building a well-integrated set of services that, when used in the
most obvious way, allows it to do as many things as possible, as fast as possible, while remaining resilient to changes in site activity. The vast majority of visits to our site never reach the backend of our stack, but the minority that do involve really critical site functions, such as all editor activity. We want the MediaWiki ecosystem to have not only the capacity to sustain current levels of activity, but to be an enabler of growth by making it possible for many more people to contribute in new ways. To meet this challenge, we need MediaWiki to be increasingly parallel, and to provide efficient, concurrent access to a rich variety of content types and storage layers.
This split maps neatly to Ori and Aaron's respective skill-sets and experience, which makes for an effective partnership. Having Aaron formally move to a performance role both recognizes the work Aaron is already doing, and it lays the groundwork for a process for meeting performance challenges that leverages their diversity of expertise.
Please join me in thanking Aaron for taking on this role!
Rob
[1] Steve Souders is formerly Head Performance Engineer at Google and "Chief Performance Yahoo!" at Yahoo. Performance Golden Rule:
http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Congratulations, Aaron!
Dan
On 7 April 2014 17:40, Rob Lanphier robla@wikimedia.org wrote:
Hi everyone
I'm pleased to announce that Aaron Schulz is taking on a new role in Wikimedia Foundation's Platform Team: Senior Performance Engineer.
Aaron works on MediaWiki internals -- components that every user-visible feature depends on, but which are rarely user-visible themselves. The impact of Aaron's work on the reliability and performance of MediaWiki is felt by many, but fully known to few, so I'd like to use this occasion to highlight some of this work.
Aaron is the primary author of MediaWiki's file handling backend, job queue, its integration with Redis key-value database and the OpenStack's Swift distributed filesystem -- just to name a few of the more significant (and relatively recent) components. In addition to these things, Aaron has designed a heavily-used set of generic mechanisms for enabling concurrent access to shared resources, for breaking up big computations into smaller units of work, and for distributing those units of work across a cluster of machines that can execute it. Aaron's code plays an important supporting role in most (if not all) significant MediaWiki functionality.
Aaron's move to performance recognizes the critical role he has already played in this area, and reflects our evolving understanding of how important that work is. We are constantly striving to make the experience of using MediaWiki snappy so that editors can do their work without waiting on the software to acknowledge their actions. To meet these standards, we need to tackle performance in (at least) two areas:
- Using data to provide a picture of how users experience the site,
identifying where users encounter latency, quantifying how it impacts their engagement, and using this information to drive optimizations to the code, paying particular attention to client-side network and computational load. In making this a focal point, we are heeding Steve Souders' Performance Golden Rule: "80-90% of the end-user response time is spent on the frontend. Start there." [1] Our goal here is to ensure that the visual display of information and the reactivity of the user interface exhibit the kind of immediacy that is needed for users to focus on and engage with content.
- Building a well-integrated set of services that, when used in the
most obvious way, allows it to do as many things as possible, as fast as possible, while remaining resilient to changes in site activity. The vast majority of visits to our site never reach the backend of our stack, but the minority that do involve really critical site functions, such as all editor activity. We want the MediaWiki ecosystem to have not only the capacity to sustain current levels of activity, but to be an enabler of growth by making it possible for many more people to contribute in new ways. To meet this challenge, we need MediaWiki to be increasingly parallel, and to provide efficient, concurrent access to a rich variety of content types and storage layers.
This split maps neatly to Ori and Aaron's respective skill-sets and experience, which makes for an effective partnership. Having Aaron formally move to a performance role both recognizes the work Aaron is already doing, and it lays the groundwork for a process for meeting performance challenges that leverages their diversity of expertise.
Please join me in thanking Aaron for taking on this role!
Rob
[1] Steve Souders is formerly Head Performance Engineer at Google and "Chief Performance Yahoo!" at Yahoo. Performance Golden Rule:
http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Awesome, congrats Aaron!
On Mon, Apr 7, 2014 at 5:50 PM, Dan Garry dgarry@wikimedia.org wrote:
Congratulations, Aaron!
Dan
On 7 April 2014 17:40, Rob Lanphier robla@wikimedia.org wrote:
Hi everyone
I'm pleased to announce that Aaron Schulz is taking on a new role in Wikimedia Foundation's Platform Team: Senior Performance Engineer.
Aaron works on MediaWiki internals -- components that every user-visible feature depends on, but which are rarely user-visible themselves. The impact of Aaron's work on the reliability and performance of MediaWiki is felt by many, but fully known to few, so I'd like to use this occasion to highlight some of this work.
Aaron is the primary author of MediaWiki's file handling backend, job queue, its integration with Redis key-value database and the OpenStack's Swift distributed filesystem -- just to name a few of the more significant (and relatively recent) components. In addition to these things, Aaron has designed a heavily-used set of generic mechanisms for enabling concurrent access to shared resources, for breaking up big computations into smaller units of work, and for distributing those units of work across a cluster of machines that can execute it. Aaron's code plays an important supporting role in most (if not all) significant MediaWiki functionality.
Aaron's move to performance recognizes the critical role he has already played in this area, and reflects our evolving understanding of how important that work is. We are constantly striving to make the experience of using MediaWiki snappy so that editors can do their work without waiting on the software to acknowledge their actions. To meet these standards, we need to tackle performance in (at least) two areas:
- Using data to provide a picture of how users experience the site,
identifying where users encounter latency, quantifying how it impacts their engagement, and using this information to drive optimizations to the code, paying particular attention to client-side network and computational load. In making this a focal point, we are heeding Steve Souders' Performance Golden Rule: "80-90% of the end-user response time is spent on the frontend. Start there." [1] Our goal here is to ensure that the visual display of information and the reactivity of the user interface exhibit the kind of immediacy that is needed for users to focus on and engage with content.
- Building a well-integrated set of services that, when used in the
most obvious way, allows it to do as many things as possible, as fast as possible, while remaining resilient to changes in site activity. The vast majority of visits to our site never reach the backend of our stack, but the minority that do involve really critical site functions, such as all editor activity. We want the MediaWiki ecosystem to have not only the capacity to sustain current levels of activity, but to be an enabler of growth by making it possible for many more people to contribute in new ways. To meet this challenge, we need MediaWiki to be increasingly parallel, and to provide efficient, concurrent access to a rich variety of content types and storage layers.
This split maps neatly to Ori and Aaron's respective skill-sets and experience, which makes for an effective partnership. Having Aaron formally move to a performance role both recognizes the work Aaron is already doing, and it lays the groundwork for a process for meeting performance challenges that leverages their diversity of expertise.
Please join me in thanking Aaron for taking on this role!
Rob
[1] Steve Souders is formerly Head Performance Engineer at Google and "Chief Performance Yahoo!" at Yahoo. Performance Golden Rule:
http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Dan Garry Associate Product Manager for Platform Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
you guys are going to kick butt together! congrats! :) On 7 Apr 2014 17:40, "Rob Lanphier" robla@wikimedia.org wrote:
Hi everyone
I'm pleased to announce that Aaron Schulz is taking on a new role in Wikimedia Foundation's Platform Team: Senior Performance Engineer.
Aaron works on MediaWiki internals -- components that every user-visible feature depends on, but which are rarely user-visible themselves. The impact of Aaron's work on the reliability and performance of MediaWiki is felt by many, but fully known to few, so I'd like to use this occasion to highlight some of this work.
Aaron is the primary author of MediaWiki's file handling backend, job queue, its integration with Redis key-value database and the OpenStack's Swift distributed filesystem -- just to name a few of the more significant (and relatively recent) components. In addition to these things, Aaron has designed a heavily-used set of generic mechanisms for enabling concurrent access to shared resources, for breaking up big computations into smaller units of work, and for distributing those units of work across a cluster of machines that can execute it. Aaron's code plays an important supporting role in most (if not all) significant MediaWiki functionality.
Aaron's move to performance recognizes the critical role he has already played in this area, and reflects our evolving understanding of how important that work is. We are constantly striving to make the experience of using MediaWiki snappy so that editors can do their work without waiting on the software to acknowledge their actions. To meet these standards, we need to tackle performance in (at least) two areas:
- Using data to provide a picture of how users experience the site,
identifying where users encounter latency, quantifying how it impacts their engagement, and using this information to drive optimizations to the code, paying particular attention to client-side network and computational load. In making this a focal point, we are heeding Steve Souders' Performance Golden Rule: "80-90% of the end-user response time is spent on the frontend. Start there." [1] Our goal here is to ensure that the visual display of information and the reactivity of the user interface exhibit the kind of immediacy that is needed for users to focus on and engage with content.
- Building a well-integrated set of services that, when used in the
most obvious way, allows it to do as many things as possible, as fast as possible, while remaining resilient to changes in site activity. The vast majority of visits to our site never reach the backend of our stack, but the minority that do involve really critical site functions, such as all editor activity. We want the MediaWiki ecosystem to have not only the capacity to sustain current levels of activity, but to be an enabler of growth by making it possible for many more people to contribute in new ways. To meet this challenge, we need MediaWiki to be increasingly parallel, and to provide efficient, concurrent access to a rich variety of content types and storage layers.
This split maps neatly to Ori and Aaron's respective skill-sets and experience, which makes for an effective partnership. Having Aaron formally move to a performance role both recognizes the work Aaron is already doing, and it lays the groundwork for a process for meeting performance challenges that leverages their diversity of expertise.
Please join me in thanking Aaron for taking on this role!
Rob
[1] Steve Souders is formerly Head Performance Engineer at Google and "Chief Performance Yahoo!" at Yahoo. Performance Golden Rule:
http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org