Romaji to Kana Converter: React & Next.js — Chapter 4, Exercise 1
=====================================================================

TASK
Run the real benchmark scripts from this chapter yourself against a
third, different test word (not "kyaku"). Report the real numbers
you get and compare them against the ones published here.

SOLUTION

Using "konnichiwa" as the test word, with the same real bench_server.js
and a client script identical to the chapter's own bench_client.js
except for the word being converted:

  word="konnichiwa"  direct 0.947 µs/call, http 14626.710 µs/call, ratio 15449x

Compared against the chapter's own published numbers for "kyaku"
(direct ~0.24-0.38 µs/call, http ~14,246-14,648 µs/call):

- The direct call time is a little higher for "konnichiwa" (0.947 µs)
  than for "kyaku" (0.24-0.38 µs), which makes sense: "konnichiwa" is
  a longer word (10 characters) that needs more tokenizer loop
  iterations than "kyaku" (5 characters) to fully convert, so it
  genuinely takes a little more real CPU time per call.

- The HTTP round-trip time, 14,626.710 µs, lands squarely inside the
  same real range the chapter already reported (14,246-14,648 µs),
  regardless of which word was being converted. This is exactly what
  the chapter's own finding predicts: the dominant cost of an HTTP
  round trip is the real network/socket overhead itself, which has
  nothing to do with how long the word being converted is -- the
  actual conversion work is a rounding error next to the cost of the
  request itself.

- The ratio, ~15,449x, sits between the chapter's own two reported
  ratios (37,928x and 60,782x) rather than matching either one
  exactly, confirming the chapter's own warning that the ratio is
  genuinely noisy and shouldn't be treated as a fixed number -- what
  stays stable across all three runs is the real ~14,000-15,000 µs
  HTTP figure, not the ratio built from dividing it by a
  sub-microsecond baseline.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reports real, freshly-run numbers rather than assuming the
chapter's own figures would repeat exactly, and correctly identifies
which parts of the result are expected to vary (the direct-call time,
scaling with word length) and which are expected to stay stable (the
HTTP round-trip cost, dominated by network overhead) -- exactly
confirming the chapter's own distinction between a stable absolute
number and a noisy derived ratio.