D787 Scalability and Performance Optimization is banner number ITSW 6104 and three competency units in the School of Technology, at the graduate level. The catalog describes it as preparing students to analyze real-world systems and make informed decisions improving design, performance and reliability. Informed is the word that sets the standard. Performance work without measurement is guessing, and the competency this course builds is the discipline of measuring first, changing one thing, and measuring again.
Measure, change one thing, measure again
The most common way performance work goes wrong is optimizing the part that was never the constraint. A system has one bottleneck at a time, moving it somewhere else is the usual result of a fix, and finding it requires evidence rather than intuition. Graduate aspects in this course are written to require that evidence, which is why a paper full of sensible-sounding improvements with no baseline is a weak paper.
Vocabulary has to be exact. Latency is how long one operation takes. Throughput is how many complete per unit time. They are related and they are not the same, and improvements to one frequently cost the other, as batching demonstrates. Utilization is how busy a resource is, and it is the number people optimize by mistake, because a resource at high utilization has queuing behavior that makes latency rise sharply rather than smoothly.
Percentiles rather than averages is the second discipline. An average response time hides the experience of the users having the worst time, and in a system where one request fans out to several services the slow tail becomes the common case rather than the exception. Reporting the median with the ninety-fifth and ninety-ninth percentiles is the graduate standard, and reporting only a mean invites the criticism.
Scaling has two directions and they are not interchangeable. Vertical scaling makes one machine bigger, which is simple and finite. Horizontal scaling adds machines, which is effectively unbounded and requires the workload to be partitionable and the state to be handled. Whether a system can scale horizontally is usually a question about state, and answering it is more valuable than any tuning parameter.
Turning scored aspects into measurements and a word budget
Each aspect at WGU is scored on its own and needs a 2. In a performance course the productive mapping is aspect to measurement or aspect to decision supported by one, and any aspect you cannot attach evidence to is the one that will come back.
Budget it. Suppose ten scored aspects and a report of about 2,100 words with charts and tables. Ten into 2,100 gives 210 words apiece. Sort them. Two are baseline and methodology aspects, at 280 each, or 560, because the method is what makes everything after it credible. Two are analysis aspects identifying the constraint, at 300 each, or 600. Two are recommendation aspects with trade-offs, at 300 each, or 600. One covers reliability implications, 200. Three are lighter, framing and chart readings, at 50 each, or 150. That totals 560 plus 600 plus 600 plus 200 plus 150, which is 2,110, on target, with method and analysis carrying more than half the report.
Write the method before you gather anything: what you will measure, under what load, for how long, how many runs, and what you will hold constant. A measurement without a stated method cannot be trusted by a reader, and stating it afterwards from memory usually reveals that something moved.
On the D787 analysis?
Send the aspects and the system description. You get a measurement method, a bottleneck analysis structure and a recommendation frame with trade-offs.
Reading a symptom back to its constraint
| Symptom | Likely constraint | What to measure next |
|---|---|---|
| Latency rises sharply past a load threshold | A resource approaching saturation and queuing | Utilization and queue depth at the suspected resource |
| Throughput plateaus while resources look idle | A serialized section or a connection limit | Lock contention and pool exhaustion |
| Median is fine, tail is terrible | Contention, garbage collection pauses or a slow dependency | Percentile distribution and pause events over time |
| Response time grows with data volume | A missing index or a scan where a lookup was intended | Query plans and rows examined per request |
| One request triggers many downstream calls | A query pattern issuing one call per item | Calls per request, counted rather than estimated |
| Adding machines does not help | A shared resource, or state that prevents partitioning | What every instance contends on |
Each row moves from something a user notices to something you can instrument. That translation is the analytical move the aspects are testing, and the third column is what stops a paper from recommending a fix for a cause nobody confirmed.
Reporting measurements so they can be checked
A measurement is only evidence if a reader could repeat it. Report the environment, the load pattern, the duration, the number of runs and the variation between them. State whether a warm-up period was excluded and why. Where you compare before and after, change one thing between the two, or you cannot attribute the difference to anything.
Charts carry this work when they are built honestly. Label both axes with units, do not truncate an axis in a way that exaggerates a difference, and show the distribution rather than a single bar where the distribution is the point. A table of percentiles next to a chart lets a reader check what the picture claims.
For sources, established texts on performance engineering and capacity planning, published queueing results and documented benchmarks are the strong citations, in APA where your program requires it. Vendor benchmarks are produced under favorable conditions and should be identified as such when used. Where you rely on a scaling law or a queueing relationship, name it and cite it rather than paraphrasing the intuition, since precision about these results is part of what distinguishes graduate work here.
What clears, and what returns
Work at WGU is Competent or Not Competent, and a return costs revision time rather than a mark. In a six month flat rate term that time is the cost, and in an analytical course the fastest route to a first-pass submission is a method written before the data was collected.
Reports that clear establish a baseline, identify a constraint with evidence, change one variable, measure again, and state what the improvement cost elsewhere. They report percentiles. They say what they did not test and what would change their conclusion. They connect the recommendation to the reliability consequences, since a system tuned to run at high utilization has less headroom for a failure.
Returns come from three habits. Recommendations with no baseline, which cannot be evaluated. Averages presented as the performance story. And several changes made at once, which makes attribution impossible and invalidates the comparison the aspect asked for.
Six mistakes that cost D787 students time
- Optimizing without a baseline. Without a before, the after means nothing and no aspect about improvement can be satisfied.
- Changing several things at once. One variable per experiment, or you have measured a combination and learned nothing about its parts.
- Reporting averages. The tail is where users suffer and where fan-out makes rare slowness common.
- Testing on an unrepresentative data set. A query that is fast over a thousand rows tells you nothing about a million, and data volume is often the whole problem.
- Treating caching as a general answer. A cache adds an invalidation problem and a consistency question, and both belong in the trade-off section.
- Ignoring reliability. Running closer to saturation improves efficiency and removes the headroom that absorbs a failure, which is a trade-off the aspects expect stated.
How we work on this course
Support for D787 is method first. Send the scored aspects and the system description and you get a measurement plan with the conditions stated, a bottleneck analysis structure that moves from symptom to instrument, a recommendation frame that names what each improvement costs, chart and table formats a reader can check, and a model report in the register WGU graduate evaluators expect. Where a section of your course is assessed by an objective assessment, our help is preparation only, and objective assessments are proctored: we never sit or assist during one and never ask for or use portal credentials.
Performance reports collapse in length once the method exists, because the analysis writes itself from the measurements. In a six month flat rate term that is the difference between one course and two.
Three questions D787 students ask
Is D787 the same course as ITSW 6104?
Do I need to run load tests against a real system?
Why do percentiles matter more than averages here?
Where D787 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.