Update more PR comments

Signed-off-by: AlvarVG <alvigo92@gmail.com>

Author: AlvarVG

_posts/2026-01-08-measuring-debezium-server-performance-mysql-streaming.adoc

@@ -26,7 +26,7 @@ as incorporating them would significantly increase the complexity of the test ca
 Measuring software performance is important. It directly affects reliability, scalability, cost efficiency and user trust. It is a prerequisite for making informed engineering decisions. 
 Performance measurement transforms software from a black box into an understandable, predictable and optimizable system. It is well known that:
 
-'What is not measured cannot be controlled, predicted or reliably improved'
+_"What is not measured cannot be controlled, predicted or reliably improved"_
 
 Going beyond sayings and proverbs, performance measurement provides you with evidence to inform and drive architectural decisions. 
 Specifically, performance testing can help you by providing information that enables you to:
@@ -41,24 +41,23 @@ Specifically, performance testing can help you by providing information that ena
 [id=debezium-server]
 == Debezium Server
 
-Apart from performance tests, another great unknown in the CDC community is *Debezium Server*. If you are reading this, you probably know something about Debezium and CDC.
+Apart from performance tests, another great unknown in the CDC community might be *Debezium Server*. If you are reading this, you probably know something about Debezium and CDC.
 But let me introduce you to Debezium Server. 
 Debezium Server is a standalone runtime for Change Data Capture that captures database changes using Debezium and delivers them directly to configurable sinks without requiring Kafka or Kafka Connect.
 It addresses a common gap in CDC architectures: situations where Kafka Connect, Kubernetes, or large distributed platforms introduce unnecessary operational complexity. 
 It enables teams to adopt CDC with minimal infrastructure while still benefiting from Debezium’s mature and proven connectors.
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/debezium-server-architecture.png" style="max-width:70%;" class="responsive-image" alt="Debezium Server Architecture">
+<div class="imageblock centered-image">
+    <img src="/assets/images/debezium-server-architecture.png" class="responsive-image" alt="Debezium Server Architecture">
+</div>
 ++++
-*Debezium Server architecture*
-====
 
 Debezium Server is built on top of the Debezium Engine, packaging it into a production-ready application that can run as a single JVM process.
 It runs as a single process and although Kafka is not required, it preserves the core CDC guarantees: 
-- Exactly-once offset management (per connector)
-- Ordered event delivery per table
+
+- At-least-once offset management (per connector)
+- Ordered event delivery per table (depends on the connector)
 - Snapshotting and streaming of the changes in the database
 - Rich metadata about transactions and schemas
 
@@ -72,28 +71,24 @@ We have called these two instances _Observed_ and _Observer_ (in order to separa
 (the software piece generating the load). In the Observed instance, we have a single Kafka container (although it is not really necessary and another software can be used),
 Debezium Server, and MySQL. 
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/benchmark_architecture_blueprint.png" style="max-width:70%;" class="responsive-image" alt="Benchmarking architecture">
+<div class="imageblock centered-image">
+    <img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/benchmark_architecture_blueprint.png" class="responsive-image" alt="Benchmarking architecture">
+</div>
 ++++
-*Benchmarking architecture*
-====
 
 As per the preceding description, we are using several software pieces, most of which are already known, except for Yahoo! Cloud Serving Benchmark (YCSB). The YCSB tool, which was created by the Yahoo
 team and released into open source as of 04/23/2010, developed to evaluate the performance of different cloud serving stores. This is the link to their GitHub project: https://ycsb.site[https://ycsb.site].
 
-If you want to reproduce this scenario, it is quite simple. Go to debezium-performance[ADD_REPO_URL_HERE] repo, clone it and cd into the infrastructure-automation folder and then run terraform apply. 
+If you want to reproduce this scenario, it is quite simple. Go to debezium-performance[ADD_REPO_URL_HERE] repo, clone it and cd into the infrastructure-automation folder and then run `terraform apply`. 
 This will automatically create the EC2 instances, provision them with ansible (copy files and install docker) and start the scenario.
 Logging in Grafana will allow you to see how everything evolves and progresses (inside Grafana you will need to navigate to the MySQL Streaming dashboard).
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/benchmark_completed_scenario.png" style="max-width:70%;" class="responsive-image" alt="Streaming dashboard from a completed scenario">
+<div class="imageblock centered-image">
+    <img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/benchmark_completed_scenario.png" class="responsive-image" alt="Streaming dashboard from a completed scenario">
+</div>
 ++++
-*Streaming dashboard from a completed scenario*
-====
 
 With the technology stack clearly defined and reproducible, we can now focus on how performance will be measured and which metrics will be considered:
 
@@ -105,52 +100,44 @@ With the technology stack clearly defined and reproducible, we can now focus on
 For all the given metrics, we are calculating the average over the duration of the test. This way, we provide a stable value, and any possible spikes that may exist do not affect
 the final result and are included in it. These are a few more detailed panels of the dashboard.
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/cpu_memory_consumption.png" style="max-width:70%;" class="responsive-image" alt="CPU and Memory consumption during one execution">
+<div class="imageblock centered-image">
+    <img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/cpu_memory_consumption.png" class="responsive-image" alt="CPU and Memory consumption during one execution">
+</div>
 ++++
-*CPU and Memory consumption during one execution*
-====
 
 In the picture above, you can see a few of the panels related to the resource consumption. The two on top are related to the CPU usage, which is the calculated percentage of usage for a 4 vCPUs instance.
 And the other ones are the memory consumption in MB throughout the execution. The two on the left represent the evolution over time, and the ones on the right are the all-time average. 
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/throughput_time_evolution.png" style="max-width:70%;" class="responsive-image" alt="Throughput evolution during one execution">
+<div class="imageblock centered-image">
+    <img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/throughput_time_evolution.png" class="responsive-image" alt="Throughput evolution during one execution">
+</div>
 ++++
-*Throughput evolution during one execution*
-====
 
 In this example, we see the Debezium Server throughput from another execution of the test. This throughput chart is split into two parts, which comes from YCSB behavior.
 YCSB executions are divided into two phases: an initial load phase that populates the tables, followed by a workload phase that executes the configured mix of operations. This behavior explains the two distinct phases visible in the throughput charts.
 If the first half keeps the throughput at the set level, we consider the execution successful (OK/1), otherwise if something in the process makes it fail we consider it a failed execution (NOK/0).
 
 The image that follows shows a detailed view of the second phase of the execution, which runs 300 updates per second and 300 inserts per second. 
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/throughput_detailed_view.png" style="max-width:70%;" class="responsive-image" alt="Detailed view of the throughput panel">
+<div class="imageblock centered-image">
+    <img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/throughput_detailed_view.png" class="responsive-image" alt="Detailed view of the throughput panel">
+</div>
 ++++
-*Detailed view of the throughput panel*
-====
 
 [id=results-analysis]
 == Results and Analysis
 
 Let's now examine the results to gain a clear view of how the system behaves under varying levels of load, and
 to identify trends that might not be evident from isolated measurements. If you want to review the detailed analysis, you can view the raw results [ADD_REPO_URL_HERE_RESULTS_FILE]. 
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/debezium_server_streaming_mysql_results.png" style="max-width:70%;" class="responsive-image" alt="Debezium Server streaming results screenshot for MySQL">
+<div class="imageblock centered-image">
+    <img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/debezium_server_streaming_mysql_results.png" class="responsive-image" alt="Debezium Server streaming results screenshot for MySQL">
+</div>
 ++++
-*Debezium Server streaming results screenshot for MySQL*
-====
 
 With the preceding image in mind, let's consider the meaning of each column.
 
@@ -181,13 +168,11 @@ This chart does not follow a single uniform growth pattern solely driven by the
 this behavior is not consistent across all tables. Several tables show relatively high execution times even at lower operation counts, whereas others maintain low durations despite handling more operations.
 This indicates that execution time is strongly influenced by table-specific factors rather than by workload size alone.
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/duration_by_ops_table.png" style="max-width:70%;" class="responsive-image" alt="Duration by operation per second and table amount">
+<div class="imageblock centered-image">
+    <img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/duration_by_ops_table.png" class="responsive-image" alt="Duration by operation per second and table amount">
+</div>
 ++++
-*Duration by operation per second and table amount*
-====
 
 This chart shows the average CPU utilization. It does not scale linearly with the number of operations and varies across tables.
 In the initial table groups, CPU increases as the workload grows, reaching peak values at a mid-range operation count, after which it stabilizes or even decreases despite higher numbers of operations. 
@@ -196,80 +181,67 @@ For subsequent tables, CPU usage remains within a relatively narrow range, with
 CPU utilization is influenced more by table-specific processing characteristics and execution efficiency than by total operation volume alone.
 Other factors - I/O wait, batching or internal optimizations - may play a more significant role in performance at higher workloads. 
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/cpu_by_ops_table.png" style="max-width:70%;" class="responsive-image" alt="CPU usage by operation per second and table amount">
+<div class="imageblock centered-image">
+    <img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/cpu_by_ops_table.png" class="responsive-image" alt="CPU usage by operation per second and table amount">
+</div>
 ++++
-*CPU usage by operation per second and table amount*
-====
 
 The memory consumption remains stable across different operation counts and tables, with no clear relationship to the number of operations executed. Most measurements cluster within a similar range, suggesting a consistent baseline memory footprint largely independent of workload size.
-The chart suggests that memory usage is dominated by structural or configuration-related factors rather than by the volume of operations, and that memory is unlikely to be the primary scaling constraint. 
+The chart suggests that memory usage is dominated by logical database schema or configuration-related factors rather than by the volume of operations, and that memory is unlikely to be the primary scaling constraint. 
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/memory_by_ops_table.png" style="max-width:70%;" class="responsive-image" alt="Memory usage by operation per second and table amount">
+<div class="imageblock centered-image">
+    <img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/memory_by_ops_table.png" class="responsive-image" alt="Memory usage by operation per second and table amount">
+</div>
 ++++
-*Memory usage by operation per second and table amount*
-====
 
 The network usage varies significantly across tables and operations counts, with output traffic consistently higher than input traffic in all cases. In the initial table groups, both input and output volumes increase as the number of operations grows, indicating a clear workload-driven effect on network utilization.
 However, this pattern becomes less consistent in later tables, where network usage remains high or fluctuates despite changes in total operations. This suggests that data transfer is influenced more by table-specific characteristics than by the number of operations.
 
 Overall, this indicates that network utilization is a dominant and variable factor in system behavior, particularly on the output side, and should be considered a potential constraint depending on table structure and data change patterns. 
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/network_by_ops_table.png" style="max-width:70%;" class="responsive-image" alt="Network usage by operation per second and table amount">
+<div class="imageblock centered-image">
+    <img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/network_by_ops_table.png" class="responsive-image" alt="Network usage by operation per second and table amount">
+</div>
 ++++
-*Network usage by operation per second and table amount*
-====
 
 Disk write activity remains relatively stable across most tables and operation counts, indicating a consistent write pattern independent of workload size.
 In contrast, disk read activity is minimal or negligible in the early table groups and becomes more prominent only in later tables, where noticeable spikes appear at specific operation counts.
 One table in particular exhibits a pronounced write peak compared to all others, suggesting an isolated behavior such as increased flushing or checkpointing.
 This behavior is typically observed during log file rotation or log exchanges, where disk activity is driven primarily by the number of log files generated and the overall execution duration, rather than by the volume of operations.
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/disk_by_ops_table.png" style="max-width:70%;" class="responsive-image" alt="Disk usage by operation per second and table amount">
+<div class="imageblock centered-image">
+    <img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/disk_by_ops_table.png" class="responsive-image" alt="Disk usage by operation per second and table amount">
+</div>
 ++++
-*Disk usage by operation per second and table amount*
-====
-
 
 The maximum throughput achieved varies noticeably across tables, indicating different upper performance limits depending on table characteristics.
 Tables 1 and 2 reach the highest values, demonstrating a greater capacity to sustain higher operation rates, while subsequent tables show a gradual reduction in maximum achievable throughput.
 This decrease is not strictly linear, as some tables outperform others despite their position, but it clearly reflects table-specific constraints such as data structure, indexing or processing complexity.
 
 The chart highlights that maximum operations per second are primarily driven by table design and access patterns rather than by uniform system limits, reinforcing the need for table-level performance evaluation.
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/max_ops_by_table.png" style="max-width:70%;" class="responsive-image" alt="Maximum operation per second by table amount">
+<div class="imageblock centered-image">
+    <img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/max_ops_by_table.png" class="responsive-image" alt="Maximum operation per second by table amount">
+</div>
 ++++
-*Maximum operation per second by table amount*
-====
 
 But, *what is Debezium Server's observed upper bound in number of operations per second?* 
 
 In this comparison we can see the relationship between MySQL and Debezium Server throughput. The initial peak observed at the start of the execution is the desired value we are targeting for this execution.
 MySQL fails to keep pace at such high values (1500 operations per second in 1 table). On the Debezium side, the throughput closely mirrors MySQL activity. 
-This correlation confirms that the CDC pipeline is processing database changes efficiently and in near real time, with no apparent backlog or loss. 
-Overall throughput behavior is driven by the database write pattern rather than by downstream processing constraints.
+In the lower panel, you can see that Debezium's internal queue maintains a high and stable capacity throughout the execution, with no indication of saturation or backlog accumulation.
+Overall, the chart confirms that Debezium Server processes MySQL changes efficiently and in near real time, and that the throughput behavior is driven by the database write pattern rather than by downstream processing constraints. 
 
-[.centered-image.responsive-image]
-====
 ++++
-<img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/mysql_vs_debezium_server_throughput.png" style="max-width:70%;" class="responsive-image" alt="MySQL vs Debezium Server throughput comparison">
+<div class="imageblock centered-image">
+    <img src="/assets/images/2026-01-08-measuring-debezium-server-performance-mysql-streaming/mysql_vs_debezium_server_throughput.png" class="responsive-image" alt="MySQL vs Debezium Server throughput comparison">
+</div>
 ++++
-*MySQL vs Debezium Server throughput comparison*
-====
 
 [id=conclusion-recommendations]
 == Conclusion and recommendations