Ian wcre2011

•Download as PPTX, PDF•

0 likes•273 views

SAIL_QU

An Exploratory Study of the Evolution of
Communicated Information
about the Execution of Large Software Systems
Weiyi Shang
Zhen Ming Jiang
Bram Adams
Ahmed E. Hassan
Michael W. Godfrey
University of WaterlooQueen’s University
Mohamed Nasser
Parminder Flora
Research In Motion (RIM)

2
What run-time actions cause the
failure?

Automated profiling & instrumentation
Detail No domain knowledgeLarge scale
3

Communicated information (CI)
Execution
Logs
System
Alerts
Code
Comments
/*
…
*/
StaticDynamic
4
Field experienceDeveloper experience

CI forms basis of Ecosystem of Log Processing
Apps
Workload recoveryAnomaly
detection
Capacity
planning System
monitoring
Performance
analysis
5
Failure
diagnosis

How to keep Log Processing Apps in sync with
CI?
Release 1 Release 2 Release 3
6

Our Study Dimensions
What types of
modifications
happen to CI?
What information is
conveyed by the
short-lived CI?
Quantity Type Content
How does CI
evolve over
time?
7

Case Study Setup
Data
Collection
Log
Abstraction
System
Deployment
time=1, Trying to launch, TaskID=01A
time=$t, Trying to launch, TaskID=$id
Enterprise Application (EA)
8
Log
Events

CI keeps on growing over time
0
20
40
60
80
100
120
140
160
180
0.14.0
0.15.0
0.16.0
0.17.0
0.18.0
0.19.0
0.20.0
0.20.1
0.20.2
0.21.0
releases
#
execution
events
10

…even when system size decreases
# K SLOC # Execution log events
0.19.0 293 113
0.20.0 250 121
11

CI is impacted by re-engineering
0.00%
20.00%
40.00%
60.00%
80.00%
100.00%
0.15.0 0.16.0 0.17.0 0.18.0 0.19.0 0.20.0 0.20.1 0.20.2 0.21.0
Unchanged CI
Large amounts of implementation changes
12

How does CI
evolve over
time?
13
Growing &
changing
Document &
track
What types of
modifications
happen to CI?
What information is
conveyed by the
short-lived CI?
Quantity Type Content

Six types of modification exist
Rephrasing Redundant
information
Adding
information
Deleting
information
Diverging Merging
14

Six types of modification exist
Rephrasing Redundant
information
Adding
information
Deleting
information
Diverging Merging
Hadoop mapred Reduce task fetch n bytes
Hadoop MapReduce task Reduce fetch n bytes
15

Six types of modification exist
Rephrasing Redundant
information
Adding
information
Deleting
information
Diverging Merging
ShuffleRamManager memory limit n MaxSingleShuffleLimit m
ShuffleRamManager memory limit n MaxSingleShuffleLimit
m mergeThreshold Q
16

Six types of modification exist
Rephrasing Redundant
information
Adding
information
Deleting
information
Diverging Merging
Adding task to tasktracker
Adding Map Task to
tasktracker
Adding Reduce Task to
tasktracker
17

Six types of modification exist
Rephrasing Redundant
information
Adding
information
Deleting
information
Diverging Merging
Avoidable
18

Six types of modification exist
Rephrasing Redundant
information
Adding
information
Deleting
information
Diverging Merging
Recoverable
19

Six types of modification exist
Rephrasing Redundant
information
Adding
information
Deleting
information
Diverging Merging
Unavoidable
20

Most modifications can be avoided
9.86%
61.97%
14.08%
7.04% 7.04% 2.82%
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
60.00%
70.00%
80.00%
90.00%
100.00%
redundant
info
rephrasing adding info deleting
info
diverging merging
avoidable recoverable unavoidable
21

How does CI
evolve over
time?
22
Growing &
changing
Document &
track
What types of
modifications
happen to CI?
What information is
conveyed by the
short-lived CI?
Quantity Type Content
6 types
Are mostly
avoidable

Short-lived CI contains implementation details
Hadoop saves output to a machine.
Hadoop assigns a reduce task to a machine.
Map task updates its progress.
Hadoop reads from a local file.
Hadoop Attempt saves its output and reports to
the task tracker.
23
Node name
Local path
Using ipc
Output file name

How does CI
evolve over
time?
24
Growing &
changing
Document &
track
What types of
modifications
happen to CI?
What information is
conveyed by the
short-lived CI?
Quantity Type Content
6 types
Are mostly
avoidable
Implementation-
level details
Fragile
Maintenance
effort

Viewers also liked

Q1_NorthAmericanOfficeReport

John Schenk

I beacon mobile_tea

Giorgio Natili

Mark kalpakis

Mark Kalpakis

Hygiene and disease prevention in Allah Dad Khan

Mr.Allah Dad Khan

Top 8 liaison nurse resume samples

MichaelLearns012

Correct PH Determinants

Jamory

Top 8 property adjuster resume samples

STEPHEN D RESUME

P1141218183

Character steps to improve character

athletebuilder

PATTANAIK

nabakishore pattanaik

Publication

hippodromecasino

Viewers also liked (13)

Q1_NorthAmericanOfficeReport

I beacon mobile_tea

Mark kalpakis

Hygiene and disease prevention in Allah Dad Khan

Top 8 liaison nurse resume samples

Correct PH Determinants

Top 8 property adjuster resume samples

STEPHEN D RESUME

P1141218183

Character steps to improve character

PATTANAIK

Publication

Similar to Ian wcre2011

Trivento summercamp masterclass 9/9/2016

Stavros Kontopoulos

Icse2013 shang

SAIL_QU

2015-09-16 IoT in Oil and Gas Conference

Mark Reynolds

Trivento summercamp fast data 9/9/2016

Stavros Kontopoulos

Greenplum for Internet Scale Analytics and Mining - Greenplum Summit 2018

VMware Tanzu

The Connected Data Imperative: Why Graphs? at Neo4j GraphDay New York City

Neo4j

Addresses streaming data challenges in sampling rates, cache maintenance, deductive reasoning, and the surrounding Semantic Web framework. Using a fixed-size cache, the challenge is to identify and preserve assertions within a stream. Deductive reasoning will continuously be performed over the cache to draw relevant conclusions as quickly as possible. The use of a cache differentiates our work from state-of-the-art works in deductive stream reasoning in that the cache enables us to temporarily store propositions that are no longer in the stream window.

Streaming HYpothesis REasoning

William Smith

This demo was presented at DEBS'13 on July 1, 2013 in Arlington, Texas, USA. The full paper and more information is available at: http://msrg.org/papers/DEBS13Mades Abstract: Application performance monitoring (APM) is shifting towards capturing and analyzing every event that arises in an enterprise infrastructure. Current APM systems, for example, make it possible to monitor enterprise applications at the granularity of tracing each method invocation (i.e., an event). Naturally, there is great interest in monitoring these events in real-time to react to system and application failures and in storing the captured information for an extended period of time to enable detailed system analysis, data analytics, and future auditing of trends in the historic data. However, the high insertion-rates (up to millions of events per second) and the purposely limited resource, a small fraction of all enterprise resources (i.e., 1-2% of the overall system resources), dedicated to APM are the key challenges for applying current data management solutions in this context. Emerging distributed key-value stores, often positioned to operate at this scale, induce additional storage overhead when dealing with relatively small data points (e.g., method invocation events) inserted at a rate of millions per second. Thus, they are not a promising solution for such an important class of workloads given APM's highly constrained resource budget. In this paper, to address these shortcomings, we present Multilayered, Adaptive, Distributed Event Store (MADES): a massively distributed store for collecting, querying, and storing event data at a rate of millions of events per second.

MADES - A Multi-Layered, Adaptive, Distributed Event Store

Tilmann Rabl

Bhawani prasad data integration-ppt

Bhawani N Prasad

Data integration ppt-bhawani nandan prasad - iim calcutta

Bhawani N Prasad

Flink Forward San Francisco 2022. Being in the payments space, Stripe requires strict correctness and freshness guarantees. We rely on Flink as the natural solution for delivering on this in support of our Change Data Capture (CDC) infrastructure. We heavily rely on CDC as a tool for capturing data change streams from our databases without critically impacting database reliability, scalability, and maintainability. Data derived from these streams is used broadly across the business and powers many of our critical financial reporting systems totalling over $640 Billion in payment volume annually. We use many components of Flink’s flexible DataStream API to perform aggregations and abstract away the complexities of stream processing from our downstreams. In this talk, we’ll walk through our experience from the very beginning to what we have in production today. We’ll share stories around the technical details and trade-offs we encountered along the way. by Jeff Chao

Squirreling Away $640 Billion: How Stripe Leverages Flink for Change Data Cap...

Flink Forward

DataOps: Control-M's role in data pipeline orchestration

pzjnjr6rsg

Your data is in Prometheus, now what? (CurrencyFair Engineering Meetup, 2016)

Brian Brazil

How Apache Spark fits into the Big Data landscape

Paco Nathan

Health & Status Monitoring (2010-v8)

Robert Grossman

Big Data: hype or necessity?

Bart Vandewoestyne

Presenter: Guru Sattanathan, Systems Engineer, Confluent Event-driven architectures have been around for many years, much like Apache Kafka®, which first open sourced in 2011. The reality is that the true potential of Kafka is only being realised now. Kafka is becoming the central nervous system of many of today’s enterprises. It is bringing a profound paradigm shift to the way we think about enterprise IT. What has changed in Kafka to enable this paradigm shift? Is it not just a message broker, and how are enterprises using it today? This session will explore these key questions. Sydney: https://content.deloitte.com.au/20200221-tel-event-tech-community-syd-registration Melbourne: https://content.deloitte.com.au/20200221-tel-event-tech-community-mel-registration

EDA Meets Data Engineering – What's the Big Deal?

confluent

The future Proof Financial: Fintech

Martijn Zoet

Systems analysis and design (abe)

International University of Management

The big data era is characterized by the ever-increasing velocity and volume of data. In order to store and analyze the ever-growing data, the operational footprint of data stores and Hadoop have also grown over time. (As per a recent report from IDC, the spending on big data infrastructure is expected to reach $41.5 billion by 2018.) The clusters comprise several thousands of nodes. The high performance of such clusters is vital for delivering the best user experience and productivity of teams. The performance of such clusters is often limited by slow/bad nodes. Finding slow nodes in large clusters is akin to finding a needle in a haystack; hence, manual identification of slow/bad nodes is not practical. To this end, we developed a novel statistical technique to automatically detect slow/bad nodes in clusters comprising hundreds to thousands of nodes. We modeled the problem as a classification problem and employed a simple, yet very effective, distance measure to determine slow/bad nodes. The key highlights of the proposed technique are the following: # Robustness against anomalies (note that anomalies may occur, for example, due to an ad-hoc heavyweight job on a Hadoop cluster) # Given the varying data characteristics of different services, no one model fits all. Consequently, we parameterized the threshold used for classification The proposed technique works well with both hourly and daily data, and has been in use in production by multiple services. This has not only eliminated manual investigation efforts, but has also mitigated the impact of slow nodes, which used to get detected after several weeks/months of lag! We shall walk the audience through how the techniques are being used with REAL data.

Finding bad apples early: Minimizing performance impact

Arun Kejariwal

Similar to Ian wcre2011 (20)

Trivento summercamp masterclass 9/9/2016

Icse2013 shang

2015-09-16 IoT in Oil and Gas Conference

Trivento summercamp fast data 9/9/2016

Greenplum for Internet Scale Analytics and Mining - Greenplum Summit 2018

The Connected Data Imperative: Why Graphs? at Neo4j GraphDay New York City

Streaming HYpothesis REasoning

MADES - A Multi-Layered, Adaptive, Distributed Event Store

Bhawani prasad data integration-ppt

Data integration ppt-bhawani nandan prasad - iim calcutta

Squirreling Away $640 Billion: How Stripe Leverages Flink for Change Data Cap...

DataOps: Control-M's role in data pipeline orchestration

Your data is in Prometheus, now what? (CurrencyFair Engineering Meetup, 2016)

How Apache Spark fits into the Big Data landscape

Health & Status Monitoring (2010-v8)

Big Data: hype or necessity?

EDA Meets Data Engineering – What's the Big Deal?

The future Proof Financial: Fintech

Systems analysis and design (abe)

Finding bad apples early: Minimizing performance impact

More from SAIL_QU

In-app advertisements have become a major revenue for app developers in the mobile app economy. Ad libraries play an integral part in this ecosystem as app developers integrate these libraries into their apps to display ads. However, little is known about how app developers integrate these libraries with their apps and how these libraries have evolved over time. In this thesis, we study the ad library integration practices and the evolution of such libraries. To understand the integration practices of ad libraries, we manually study apps and derive a set of rules to automatically identify four strategies for integrating multiple ad libraries. We observe that integrating multiple ad libraries commonly occurs in apps with a large number of downloads and ones in categories with a high percentage of apps that display ads. We also observe that app developers prefer to manage their own integrations instead of using off the shelf features of ad libraries for integrating multiple ad libraries. To study the evolution of ad libraries, we conduct a longitudinal study of the 8 most popular ad libraries. In particular, we look at their evolution in terms of size, the main drivers for releasing a new ad library version, and their architecture. We observe that ad libraries are continuously evolving with a median release interval of 34 days. Some ad libraries have grown exponentially in size (e.g., Facebook Audience Network ad library), while other libraries have worked to reduce their size. To study the main drivers for releasing an ad library version, we manually study the release notes of the eight studied ad libraries. We observe that ad library developers continuously update their ad libraries to support a wider range of Android versions (i.e., to ensure that more devices can use the libraries without errors). Finally, we derive a reference architecture for ad libraries and study how the studied ad libraries diverged from this architecture during our study period. Our findings can assist ad library developers to understand the challenges for developing ad libraries and the desired features of these libraries.

Studying the Integration Practices and the Evolution of Ad Libraries in the G...

SAIL_QU

Studying the Dialogue Between Users and Developers of Free Apps in the Google...

SAIL_QU

Improving the testing efficiency of selenium-based load tests

SAIL_QU

Studying User-Developer Interactions Through the Distribution and Reviewing M...

SAIL_QU

Studying online distribution platforms for games through the mining of data f...

SAIL_QU

Understanding the Factors for Fast Answers in Technical Q&A Websites: An Empi...

SAIL_QU

Investigating the Challenges in Selenium Usage and Improving the Testing Effi...

SAIL_QU

Mining Development Knowledge to Understand and Support Software Logging Pract...

SAIL_QU

Which Log Level Should Developers Choose For a New Logging Statement?

SAIL_QU

Towards Just-in-Time Suggestions for Log Changes

SAIL_QU

The Impact of Task Granularity on Co-evolution Analyses

SAIL_QU

A Framework for Evaluating the Results of the SZZ Approach for Identifying Bu...

SAIL_QU

How are Discussions Associated with Bug Reworking? An Empirical Study on Open...

SAIL_QU

A Study of the Relation of Mobile Device Attributes with the User-Perceived Q...

SAIL_QU

A Large-Scale Study of the Impact of Feature Selection Techniques on Defect C...

SAIL_QU

Studying the Dialogue Between Users and Developers of Free Apps in the Google...

SAIL_QU

What Do Programmers Know about Software Energy Consumption?

SAIL_QU

Threshold for Size and Complexity Metrics: A Case Study from the Perspective ...

SAIL_QU

Revisiting the Experimental Design Choices for Approaches for the Automated R...

SAIL_QU

Measuring Program Comprehension: A Large-Scale Field Study with Professionals

SAIL_QU

More from SAIL_QU (20)