Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lab.md has lab report #51

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 10 additions & 12 deletions labreports/LAB.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,9 +15,9 @@ GitHub: [YOUR_HANDLE](https://github.com/YOUR_HANDLE)<br/>
{
"data": {
"mutateAccount": {
"id": "a10db030-ded8-4397-a78f-30b79d3497ab",
"name": "MY NAME",
"email": "MY EMAIL"
"id": "0ea03032-e61a-482b-bd7c-aa576441c109",
"name": "Gage Sapp",
"email": "gs1226@messiah.edu"
}
}
}
Expand All @@ -26,24 +26,22 @@ GitHub: [YOUR_HANDLE](https://github.com/YOUR_HANDLE)<br/>
# Step 3: Signup for and configure New Relic
- The chosen name of your New Relic ```app_name``` configuration
```
app_name: ['<YOUR APP NAME>']
app_name: ['CisLab']
```

# Step 4: Exercising the application / generating performance data

_Note: No lab notes required._

# Step 5: Explore your performance data
* What are your observations regarding the performance of this application?
* Is performance even or uneven?
* Between queries and mutations, what requests are less performant?
* Among the less performant requests, which ones are the most problematic?
2. apdex score .18, throughput .567 rpm, avg web transaction time 13.2 seconds, and error rate 0.00%.
3. Apdex Resp. time Throughput Error Rate CPU usage Memory
0.18 13,200 ms 1 rpm 16.00 % 9 % 150 MB

5. For the first query Middleware: <anonymous> was the slowest component. For the second query loadOrderById was the slowest component. For the third query Remainder was the slowest component. I picked the three slowest queries and then the slowest components from them. I mean for single queries it doesn't seem to be doing too poorly although it could be much quicker. The longer queries are ones where the Id of the thing being searched is not a primary key, or at least thats what it seems like. When you are searching attributes of things instead of keys. Queries are less performant, problematic ones are just the ones with more search results especially if searching attributes.

# Step 6: Diagnosing an issue based on telemetry data
* Within the transactions you're examining, what segment(s) took the most time?
* Using New Relic, identify and record the least performant request(s).
* Using the Transaction Trace capability in New Relic, identify which segment(s) in that request permiatation is/are the most problematic and record your findings.
* Recommend a solution for improving the performance of those most problematic request(s) / permiatation(s).
* For me the "Everything query" took the longest and the slowest component of that was "remainder". I do not know how the database is setup or how the tables are connected so I would probably look at that and make sure that everything is connected in a way that makes sense and in as little steps as possible.

# Step 7: Submitting a Pull Request
_Note: No lab notes required._
Expand Down
96 changes: 54 additions & 42 deletions package-lock.json

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion package.json
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@
"graphql": "^14.0.2",
"lodash.startcase": "^4.4.0",
"lokijs": "^1.5.5",
"newrelic": "^4.9.0",
"newrelic": "^4.13.1",
"uuid": "^3.3.2"
},
"devDependencies": {
Expand Down