bbworld 2009 performance forensics workshop

68
1

Upload: steve-feldman

Post on 23-Jan-2015

1.128 views

Category:

Education


0 download

DESCRIPTION

Forensics is the practice of using scientific and empirical data to explain the cause of an incident. Forensics can applied to the world of software application management from the context of explaining performance and scalability issues. This workshop is designed to introduce application owners how to troubleshoot performance and/or scalability issues using a core set of open source tools. During last year's BbWorld, our presenter introduced a methodology and a teaser of tools to perform forensics. Since that time a slew of new tools and practices have come out and will be covered. This workshop will run through a series of common case studies often seen in the field affecting performance and/or scalability and will demo a series of tools to explain the causes of the issues. The goal of this session is to dissect performance and a scalability issues end to end from client browser/desktop all the way to the server. Foundations of forensics and the methodology used to tool sets will be covered as well.

TRANSCRIPT

Page 1: BbWorld 2009 Performance Forensics Workshop

1

Page 2: BbWorld 2009 Performance Forensics Workshop

Source: http://www.youtube.com/watch?v=-LkusicUL2s

2

Page 3: BbWorld 2009 Performance Forensics Workshop

Did you all get a chance to read that? As a public company we need to have Vista is the only solution built from the ground up on true enterprise

3

our disclosure statement before all presentations. If you have any questions

on what it means please speak with our General Counsel.

Vista is the only solution built from the ground up on true enterprise

technology --- allowing you to ensure that you continue to provide your

faculty and students an outstanding experience

Page 4: BbWorld 2009 Performance Forensics Workshop

4

Page 5: BbWorld 2009 Performance Forensics Workshop

5

Page 6: BbWorld 2009 Performance Forensics Workshop

6

Page 7: BbWorld 2009 Performance Forensics Workshop

7

Page 8: BbWorld 2009 Performance Forensics Workshop

8

Page 9: BbWorld 2009 Performance Forensics Workshop

Source: http://www.flickr.com/photos/turkguy19/1018419391/

9

Page 10: BbWorld 2009 Performance Forensics Workshop

Our session isn’t about crime scene investigation. I’m not going to attempt to

10

talk about digital forensics from a security and fraud perspective. I’m here to

put context around performance and scalability incidents that happen in your

application environments every day, week, month and year. There’s no

reason to assume that performance problems can only be solved by “black

magic”. A rational, evidence-supported process can be used to solve a

performance problem.

The first definition about forensics assumes that “something” occurs in the

form of a crime. For all intensive purposes a crime is considered pre-

meditated. Often crimes such as denial of service, script injection and spam

attacks can cause performance problems. Performance incidents can

happen when they are not necessarily premeditated. They happen because

of failure. Things break…it’s a fact of life.

When breakage or breakdowns occur they are not visibly apparent or

obvious to every set of eyes looking on. This can be problematic when

diagnosis bias is introduced or value attribution is incorrectly established.

Page 11: BbWorld 2009 Performance Forensics Workshop

http://www.flickr.com/photos/wwarby/3297205226/

11

Page 12: BbWorld 2009 Performance Forensics Workshop

12

Page 13: BbWorld 2009 Performance Forensics Workshop

Search Google and you will be amazed how little meaningful information you get by the words “performance forensics” in the

13

information you get by the words “performance forensics” in the context of computers and software. One paper by Bob Sneed from Sun Microsystems (http://www.sun.com/blueprints/1203/817-4444.pdf) is out there, but very little else.

So you will have to trust me in my primitive definition of performance forensics. You might even offer to help make it better.

Performance forensics is like any other forensics process. It begins with collective evidence. If you are lucky and have a lot of tools in place you will have a starting point of data to sift through. More often then not, the data is not there. You are not always lucky to have the data when you need it and/or it might not be in the best format for getting to the root cause of a problem.

Evidence as we will discuss later can be collected after the fact. Techniques such as discrete simulation can be used to re-enact an incident. When that does happen, you have the ability to capture all of the data you want. You simply need to know what data to collect. It’s a circuitous loop of sorts…mainly because you might not know what data to collect to begin with.

It’s like when I look under the hood of my car. I have no idea what I’m looking at…Maybe it’s that smoking gun I’m in search of. Yeah, I guess if I see some kind of corrosive, smoke or leak it might be painfully obvious…but it never is. Not with today’s cars…Computers and software specifically are the same. Rarely is there that smoking gun sitting in front of your face waiting to be found. Thus evidence is

Page 14: BbWorld 2009 Performance Forensics Workshop

Source: http://www.flickr.com/photos/t_squared/152270386/

14

Page 15: BbWorld 2009 Performance Forensics Workshop

15

Page 16: BbWorld 2009 Performance Forensics Workshop

http://www.flickr.com/photos/7563125@N08/2830710184/

16

Page 17: BbWorld 2009 Performance Forensics Workshop

17

Page 18: BbWorld 2009 Performance Forensics Workshop

18

Page 19: BbWorld 2009 Performance Forensics Workshop

19

Page 20: BbWorld 2009 Performance Forensics Workshop

20

Page 21: BbWorld 2009 Performance Forensics Workshop

21

Page 22: BbWorld 2009 Performance Forensics Workshop

22

Page 23: BbWorld 2009 Performance Forensics Workshop

Source: http://farm4.static.flickr.com/3396/3507282396_3756634f01_m.jpg

23

Page 24: BbWorld 2009 Performance Forensics Workshop

Source: http://www.flickr.com/photos/psilver/412264230/

24

Page 25: BbWorld 2009 Performance Forensics Workshop

http://crackerjackonlinemarketing.com/blog/wp-

content/uploads/2008/07/working-woman-with-octopus-hands.jpg

25

Page 26: BbWorld 2009 Performance Forensics Workshop

Source: http://farm2.static.flickr.com/1330/3174009125_ec49351a6d_m.jpg

26

Page 27: BbWorld 2009 Performance Forensics Workshop

27

Page 28: BbWorld 2009 Performance Forensics Workshop

Problems are not always easily identifiable. When I say that I feel off or sick, I leave the listener desiring more information. They might infer that I have a stomach pain, a cold or a

28

listener desiring more information. They might infer that I have a stomach pain, a cold or a headache. It could be that I am tired or I have a broken arm. A more related example that I often hear is that my system is slow. What defines slow? Can you show me? Can I experience the slowness?

Is it always slow every single day and every minute? Are all of the components that make up the physical architecture necessarily slow? Are particular use cases experiencing latency? Do they always experience latency or is it at specific times? Is it specific users who experience latency? Are the users different is some kind of fashion? Does the problem happen after a particular interaction pattern? Does it happen with a particular piece of data?

When a problem is easily identifiable, define a clear, intelligible problem statement. The problem statement is used to aid the investigation so the forensics process can focus on collecting meaningful data to get to root cause analysis.

Narrowing down to a problem statement from the unknown can be an exhaustive effort. Start with questioning (not formal interviewing) in which your goal is to exclusively narrow down the chasm of possibilities. Start with the “Lassie Question: Can you show me?” Experiencing the problem first hand provides basic context. If the problem can’t be reproduced, try to provide supporting clues so that the unpredictable can become more predictable. You can’t necessarily replicate the performance problem at will. Do you have supporting data about your experience? Can you explain what happened to you? Do you know when it happened (smallest time window)? Has it happened before? If so when? Try to get down to the exact minute if possible. Has it happened to anyone else? What were they doing? Did it happen to them at the same time as you?

It comes off like you are asking dozens and dozens of questions, but in reality you are not. You are gathering basic context: Who, What, Where and When.

Be unwilling to announce a problem statement until you have confidence in the development of the problem statement (not the cause of the issue). Remember we are not diagnosing, we are simply collecting and announcing symptoms.

Page 29: BbWorld 2009 Performance Forensics Workshop

29

Page 30: BbWorld 2009 Performance Forensics Workshop

I’m not the creator of this methodology. I’m quite sure that others who are far more knowledgeable on the subject would tell you I’m possibly missing a step or that I am drawing out the process too far. A picture is truly worth a thousand words.

30

would tell you I’m possibly missing a step or that I am drawing out the process too far. A picture is truly worth a thousand words.

I will breakdown each element of the methodology in subsequent slides. I’ve designed a circular visualization for the obvious conclusion that I’ve come to over the years in which the process must revolve in order to come to root cause analysis.

Performance forensics doesn’t necessarily begin with evidence collection. Rather, it potentially begins long before an incident occurs. Let’s take an abstract example such as a person complains about chest pain. The person tells their spouse that at times they have unbearable pains, but eventually it goes away. It doesn’t happen enough and the pain isn’t so severe that it’s worth the time or the effort to go to the doctor. The process of convincing yourself that the symptoms you are experiencing is not what you really have is called diagnosis bias. I will talk about this in greater detail later.

This pain might go on and on for quite some time until it progresses. Analysis could be initiated at any point. More often then not, the complaints go unrealized and forensics is placed on hold. It comes back later on. The question is when. Typically when a terrible even occurs. It could be a heart attack or sadly a loss of life. The forensic engineer is tasked with tracing back why it happened, was foul play suspected and could it have been avoided.

I propose that at any time the methodology can be initiated. No major issue has to occur for performance forensics to begin. Symptoms do not necessarily have to show-up for the process to begin. You can call this what you want, but basically the collection of evidence, interviewing, modeling/visualizing and planning for the future is most commonly referred to as capacity planning. It’s not the much different from what we are trying to accomplish with performance forensics. The key difference is proactive behavior versus reactive behavior.

The methodology begins with the collection of data. We can call this data evidence. Evidence is collected in two ways: intended data collection and simulated data collection. When data is not available, we often go through the process of putting data collectors in place. The thought behind this is that if something happened once, it’s bound to happen again.

Interviewing is incorporated into the methodology. I will discuss techniques for interviewing. Understand that when humans are involved and asked to participate, you run the greatest chance for diagnosis bias and value attribution (two topics I will present in greater detail).

Next I will discuss why modeling and visualizing a problem can be critical at getting to the root cause of a performance issue.

Page 31: BbWorld 2009 Performance Forensics Workshop

31

Page 32: BbWorld 2009 Performance Forensics Workshop

The best analogy to depict the execution model for wait events is the grocery

32

store checkout line. Assume the cashier is the CPU. The customer who is

currently being checked out by the cashier is the running session. The

customers who are waiting in line represent the runnable queue.

If customer1 who is being checked out requires a price check on a product,

customer1 must wait until the price check is completed. Meanwhile, the next

in line, customer2, is immediately checked out by the cashier until the price

check is completed for customer1.

When the price check is completed, the cashier can resume the check out of

customer1. This is the simplest illustration of the wait event execution

model.

Page 33: BbWorld 2009 Performance Forensics Workshop

The best analogy to depict the execution model for wait events is the grocery

33

store checkout line. Assume the cashier is the CPU. The customer who is

currently being checked out by the cashier is the running session. The

customers who are waiting in line represent the runnable queue.

If customer1 who is being checked out requires a price check on a product,

customer1 must wait until the price check is completed. Meanwhile, the next

in line, customer2, is immediately checked out by the cashier until the price

check is completed for customer1.

When the price check is completed, the cashier can resume the check out of

customer1. This is the simplest illustration of the wait event execution

model.

Page 34: BbWorld 2009 Performance Forensics Workshop

34

Page 35: BbWorld 2009 Performance Forensics Workshop

35

Page 36: BbWorld 2009 Performance Forensics Workshop

36

Page 37: BbWorld 2009 Performance Forensics Workshop

37

Page 38: BbWorld 2009 Performance Forensics Workshop

38

Page 39: BbWorld 2009 Performance Forensics Workshop

JConsole on Steroids

39

Great presentation: http://www.javapassion.com/javase/VisualVM.pdf

Another Great Presentation: http://weblogs.java.net/blog/mandychung/archive/VisualVM-BOF-2007.pdf

Page 40: BbWorld 2009 Performance Forensics Workshop

40

Page 41: BbWorld 2009 Performance Forensics Workshop

41

Page 42: BbWorld 2009 Performance Forensics Workshop

42

Page 43: BbWorld 2009 Performance Forensics Workshop

43

Page 44: BbWorld 2009 Performance Forensics Workshop

http://www.stevesouders.com/blog/2009/06/30/firefox-35-at-the-top/

44

http://assets.en.oreilly.com/1/event/29/The%20User%20and%20Business%20Impact%20of%20Server%20Delays,%20Additional%20Bytes,%20and%20HTTP%20Chunking%20in%20Web%20Search%20Presentation.pptx

Page 45: BbWorld 2009 Performance Forensics Workshop

Source: http://www.flickr.com/photos/kaptainkobold/83359336/

45

Page 46: BbWorld 2009 Performance Forensics Workshop

http://www.phpied.com/image-optimization-7-mistakes/

46

Page 47: BbWorld 2009 Performance Forensics Workshop

Using pngrewrite to optimize this image

(http://entropymine.com/jason/pngrewrite/)

Cost Savings: 3KB or roughly 15%

47

Page 48: BbWorld 2009 Performance Forensics Workshop

Using optipng to optimize this image

(http://sourceforge.net/projects/optipng/)

Cost Savings: 4KB or roughly 9%

48

Page 49: BbWorld 2009 Performance Forensics Workshop

Using optipng to optimize this image

(http://sourceforge.net/projects/optipng/)

Cost Savings: 4MB or roughly 47.50%

49

Page 50: BbWorld 2009 Performance Forensics Workshop

http://code.google.com/speed/page-speed/

50

http://developer.yahoo.com/yslow/

http://www.fiddler2.com/Fiddler2/version.asp

Great add-on to Fiddler2 is neXpert

http://videos.visitmix.com/MIX09/T53F

Page 51: BbWorld 2009 Performance Forensics Workshop

Great presentation highlighting differences between tools: http://assets.en.oreilly.com/1/event/29/Website%20Performance%20Analysi

51

http://assets.en.oreilly.com/1/event/29/Website%20Performance%20Analysis%20Presentation.ppt

Page 52: BbWorld 2009 Performance Forensics Workshop

52

Page 53: BbWorld 2009 Performance Forensics Workshop

Source: http://www.flickr.com/photos/pollyann/2877940383/

53

Page 54: BbWorld 2009 Performance Forensics Workshop

54

Page 55: BbWorld 2009 Performance Forensics Workshop

http://www.fiddler2.com/Fiddler2/version.asp

55

Demo videos: http://www.fiddler2.com/Fiddler/help/video/default.asp

Example of use as a reverse proxy: http://blogs.msdn.com/nexpert/archive/2009/06/04/capturing-http-with-fiddler-as-a-reverse-proxy.aspx

Page 56: BbWorld 2009 Performance Forensics Workshop

WebCast of neXpert:http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?E

56

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032398774&EventCategory=5&culture=en-US&CountryCode=US

Page 57: BbWorld 2009 Performance Forensics Workshop

57

Page 58: BbWorld 2009 Performance Forensics Workshop

Can also consider using Microsoft VRTA: http://www.microsoft.com/downloads/details.aspx?FamilyID=119f3477-dced-

58

http://www.microsoft.com/downloads/details.aspx?FamilyID=119f3477-dced-41e3-a0e7-d8b5cae893a3&displaylang=en

Page 59: BbWorld 2009 Performance Forensics Workshop

59

Page 60: BbWorld 2009 Performance Forensics Workshop

Source: http://www.flickr.com/photos/turkguy19/1018419787/

60

Page 61: BbWorld 2009 Performance Forensics Workshop

Easily configured Virtual Machine by cloning VMs using XenCenter

61

Page 62: BbWorld 2009 Performance Forensics Workshop

62

Page 63: BbWorld 2009 Performance Forensics Workshop

63

Page 64: BbWorld 2009 Performance Forensics Workshop

64

Page 65: BbWorld 2009 Performance Forensics Workshop

65

Page 66: BbWorld 2009 Performance Forensics Workshop

66

Page 67: BbWorld 2009 Performance Forensics Workshop

67

Page 68: BbWorld 2009 Performance Forensics Workshop

68