DEV Community: Siswoyo Siswoyo

stress-ng vs sysbench

Siswoyo Siswoyo — Wed, 07 Oct 2026 03:05:35 +0000

stress-ng vs sysbench

A practical guide to two common Linux load-generation tools: what each one does, how they differ, and when to use them.

1. Overview

	stress-ng	sysbench
Primary goal	Stress testing and fault finding	Benchmarking and performance measurement
One-line summary	Designed to break things	Designed to measure things

2. stress-ng

stress-ng loads a system's hardware and kernel interfaces in many different ways. It is a much larger successor to the original stress tool.

Core features

Large set of stressors: 300+ built-in tests, each exercising a specific part of the system.
CPU stress: Many compute methods (integer, floating point, matrix, FFT, bit operations, hashing) via --cpu and --cpu-method.
Memory stress: Virtual memory, cache, memory copy, mmap, page faults, NUMA, via --vm, --cache, --memcpy, --mmap.
I/O and filesystem stress: Disk reads/writes, fsync, file locking, directory operations, via --hdd, --io, --dir.
Kernel interface stress: Syscalls, signals, pipes, sockets, semaphores, message queues, futexes, threads, context switches, scheduler.
Network stress: Socket and protocol-level tests.
Device and driver stress: ioctl, /dev, /proc and /sys interfaces.

Control and configuration

Option	Purpose
`--cpu 4` / `--cpu 0`	Number of workers (`0` = all online CPUs)
`--timeout 60s`	Stop after a set time
`--cpu-ops N`	Stop after N operations
`--cpu-load 50`	Target a CPU utilization percentage
`--class cpu`	Run a group of stressors (cpu, memory, io, scheduler, ...)
`--all`, `--random`, `--sequential`	Permutation modes
`-x`	Exclude specific stressors

Measurement and reporting

Bogo ops: A rough throughput measure, useful for same-machine comparison but not a formal benchmark.
Metrics: --metrics / --metrics-brief for summaries; --yaml or --log-file to save results.
Thermal and perf data: --thermalstat, --vmstat, --perf.
Verification: --verify checks that results are correct, helping catch hardware faults or memory errors.

Common uses

Burn-in and stability testing of new hardware
Checking cooling and thermal throttling
Finding kernel bugs or race conditions
Testing behavior under resource pressure (CPU, RAM, I/O)

Example commands

# Stress all CPUs for 60 seconds with a summary
stress-ng --cpu 0 --timeout 60s --metrics-brief

# 4 CPU workers, 2 VM workers using 1GB each, 1 disk worker
stress-ng --cpu 4 --vm 2 --vm-bytes 1G --hdd 1 --timeout 120s --metrics-brief

# Run every CPU-class stressor in turn
stress-ng --class cpu --sequential 0 --timeout 30s

Caution: stress-ng can make a system unresponsive, overheat, or crash, and some stressors can fill disks or trigger the OOM killer. Use it on test machines or with sensible limits, not carelessly on production.

3. sysbench

sysbench is a scriptable benchmark tool that produces repeatable performance numbers for CPU, memory, disk, threads, and databases.

Core features

CPU: Prime number computation benchmark.
Memory: Read/write throughput tests.
File I/O: Sequential and random read/write tests.
Threads and mutex: Scheduler and locking performance.
Database (OLTP): Workloads for MySQL and PostgreSQL.
Lua scripting: Write custom workloads.

Example commands

# CPU benchmark
sysbench cpu --threads=4 --time=30 run

# Memory throughput
sysbench memory --threads=4 run

# File I/O
sysbench fileio --file-total-size=2G prepare
sysbench fileio --file-total-size=2G --file-test-mode=rndrw run
sysbench fileio --file-total-size=2G cleanup

4. Key Differences

Aspect	stress-ng	sysbench
Purpose	Stress testing, fault finding	Benchmarking, performance comparison
Scope	Very broad (300+ stressors)	Narrow: CPU, memory, file I/O, threads, database
Output	Bogo ops (rough, same-machine only)	Events/sec, latency percentiles, MiB/sec
Database testing	None	Strong (OLTP for MySQL/PostgreSQL)
Correctness checking	Yes (`--verify`)	No, measures speed only
Extensibility	Modify the C source	Lua scripts

5. Which One Should You Use?

Goal	Recommended tool
Burn-in, thermal, or stability testing	stress-ng
Kernel bug hunting	stress-ng
Comparing two servers or VM sizes	sysbench
Measuring the effect of tuning changes	sysbench
Database server performance	sysbench

Using them together

The two tools complement each other:

Run stress-ng to confirm the system stays stable under heavy load.
Run sysbench to record how fast the system actually is.

6. Summary

stress-ng answers: "Does this system survive heavy load?"
sysbench answers: "How fast is this system?"

References:

YAGNI: You Aren't Gonna Need It

Siswoyo Siswoyo — Tue, 29 Sep 2026 06:33:02 +0000

YAGNI: You Aren't Gonna Need It

Don't add functionality until there's a real, present use case for it.

What Is YAGNI?

YAGNI stands for "You Aren't Gonna Need It." It comes from Extreme Programming (XP) and is a core idea in agile development. The principle says developers should implement things only when they are actually needed, not when they merely foresee needing them.

It's easy to think, "We might need this later, so let's build it now." YAGNI pushes back on that habit.

Why Speculative Features Are a Problem

Problem	Explanation
Wasted time	You spend effort building something that may never be used.
Extra complexity	More code means more bugs, more tests, and more to understand.
Wrong guesses	Future requirements rarely match what you predicted.
Maintenance burden	Unused code still has to be updated, refactored, and reviewed.
Slower delivery	Time spent on "maybe" features delays real, valuable ones.

A Simple Example

❌ Violating YAGNI

Requirement: "Save a user's name to a file."

class DataStorage:
    def __init__(self, storage_type="file"):
        self.storage_type = storage_type

    def save(self, data):
        if self.storage_type == "file":
            self._save_to_file(data)
        elif self.storage_type == "database":
            self._save_to_database(data)   # Nobody asked for this
        elif self.storage_type == "cloud":
            self._save_to_cloud(data)      # Or this

    def _save_to_file(self, data): ...
    def _save_to_database(self, data): ...
    def _save_to_cloud(self, data): ...

✅ Following YAGNI

def save_user_name(name, path="user.txt"):
    with open(path, "w") as f:
        f.write(name)

If a database is required later, you can refactor then, with real requirements in hand.

When Should You Add Something?

Ask yourself these questions before building:

Is there a real user story or requirement today?
Is someone actually blocked without this?
Would adding it later be dramatically more expensive? (Usually it isn't.)

If the answers are no, no, and no, don't build it yet.

Common YAGNI Violations

Adding configuration options nobody has asked for
Creating abstract base classes with a single implementation
Building plugin systems for an app with one use case
Adding database columns "just in case"
Supporting multiple languages or currencies before you have international users
Over-engineering APIs with parameters that are never used

What YAGNI Is Not

YAGNI is often misunderstood. It does not mean:

❌ Writing sloppy or unstructured code
❌ Ignoring good design and architecture
❌ Skipping tests, security, or error handling
❌ Refusing to plan at all

The principle applies to features and speculative generality, not to code quality. In fact, YAGNI works best alongside:

Automated tests, which make later changes safe
Refactoring, so you can adapt when needs appear
Continuous integration, for fast feedback
Simple design (see also: KISS)

YAGNI vs. Related Principles

Principle	Focus
YAGNI	Don't build features before they're needed.
KISS	Keep solutions simple.
DRY	Don't repeat yourself; avoid duplicated knowledge.
Premature Optimization	Don't optimize before you've measured a real problem.

Caveat: When Anticipating the Future Is Reasonable

There are exceptions where planning ahead makes sense:

Public APIs or database schemas that are very hard to change later
Security-critical foundations, such as authentication design
Regulatory or contractual requirements that are known and certain

The key word is known. If the need is a certainty rather than a guess, it's a real requirement, not speculation.

Key Takeaways

Build for today's requirements, not imagined future ones.
Every line of code has a cost: writing, testing, and maintaining it.
Simple code is easier to change when real needs emerge.
Combine YAGNI with tests and refactoring so you can evolve safely.
Delaying a decision until you have more information is often the smartest choice.

"Always implement things when you actually need them, never when you just foresee that you need them."
— Ron Jeffries, co-founder of Extreme Programming

Reference:

https://martinfowler.com/bliki/Yagni.html

Architecture Comparison: NGINX Only vs NGINX + API Gateway

Siswoyo Siswoyo — Fri, 08 May 2026 06:54:51 +0000

Overview

This document compares two common microservice architecture patterns to help you decide which approach best fits your use case.

Architecture Diagrams

Option 1 — NGINX Only

Client
   ↓
NGINX
   ↓
Microservices

Option 2 — NGINX + API Gateway

Client
   ↓
NGINX
   ↓
API Gateway
   ↓
Microservices

Comparison by Category

1. Complexity

Aspect	NGINX Only	NGINX + API Gateway
Infrastructure	Simpler	More complex
Number of services	Fewer	Additional gateway service
Configuration	Easier	More layers
Debugging	Easier	Harder
Maintenance	Lower	Higher

Winner: ✅ NGINX Only

2. Performance

Aspect	NGINX Only	NGINX + API Gateway
Request hops	Fewer	More
Latency	Lower	Slightly higher
Resource usage	Lower	Higher
Throughput	Better	Slightly lower

Winner: ✅ NGINX Only

3. Routing

Feature	NGINX Only	API Gateway
Path routing	✅	✅
Load balancing	✅	✅
Header-based routing	Limited	Better
Dynamic routing	Limited	Better
Service discovery	Manual	Better
Canary deployment	Harder	Easier

Winner: ✅ API Gateway

4. Security

Feature	NGINX Only	API Gateway
SSL termination	✅	Usually via NGINX
JWT validation	In every service	Centralized
RBAC	In services	Easier centralized
OAuth2 integration	Harder	Easier
API key management	Limited	Better
Threat protection	Limited	Better

Winner: ✅ API Gateway

Note: If your services already validate JWT, security is already strong — the advantage of an API Gateway in this area may be less significant.

5. Scalability

Aspect	NGINX Only	NGINX + API Gateway
Horizontal scaling	✅	✅
Docker scaling	✅	✅
Kubernetes readiness	Moderate	Better
Service mesh integration	Harder	Easier
Dynamic service registration	Manual	Easier

Winner: ✅ API Gateway (large scale)

6. Observability & Monitoring

Feature	NGINX Only	API Gateway
Access logging	✅	✅
Distributed tracing	Harder	Easier
Request correlation	Manual	Better
Centralized metrics	Limited	Better
OpenTelemetry integration	Harder	Easier

Winner: ✅ API Gateway

7. Rate Limiting

Feature	NGINX Only	API Gateway
Basic rate limit	✅	✅
Per-user limit	Harder	Easier
Per-role limit	Harder	Easier
API quota	Limited	Better

Winner: ✅ API Gateway

8. Development Speed

Aspect	NGINX Only	NGINX + API Gateway
Faster setup	✅	❌
Easier onboarding	✅	❌
Easier deployment	✅	❌
Less code	✅	❌

Winner: ✅ NGINX Only

9. Cost & Resource Usage

Aspect	NGINX Only	NGINX + API Gateway
RAM usage	Lower	Higher
CPU usage	Lower	Higher
Container count	Lower	Higher
Operational cost	Lower	Higher

Winner: ✅ NGINX Only

10. Enterprise Features

Feature	NGINX Only	API Gateway
Circuit breaker	Limited	Better
API aggregation	Harder	Easier
Request transformation	Limited	Better
GraphQL federation	Harder	Easier
Multi-tenant gateway policies	Harder	Easier
Backend-for-Frontend (BFF)	Harder	Easier

Winner: ✅ API Gateway

Summary Scorecard

Category	Winner
Complexity	✅ NGINX Only
Performance	✅ NGINX Only
Routing	✅ API Gateway
Security	✅ API Gateway
Scalability	✅ API Gateway
Observability & Monitoring	✅ API Gateway
Rate Limiting	✅ API Gateway
Development Speed	✅ NGINX Only
Cost & Resource Usage	✅ NGINX Only
Enterprise Features	✅ API Gateway

NGINX Only wins: 4/10
API Gateway wins: 6/10

Recommendation

Choose NGINX Only if you prioritize simplicity, lower resource usage, fast setup, and your current JWT validation per-service is already sufficient for your security needs.
Choose NGINX + API Gateway if you need advanced routing, centralized security, better observability, rate limiting per user/role, and enterprise-grade features — especially at large scale or in Kubernetes environments.

Apache JMeter – Overview and Practical Guide

Siswoyo Siswoyo — Wed, 17 Dec 2025 07:15:33 +0000

What is Apache JMeter?

Apache JMeter is an open‑source performance and load testing tool written in Java. It is widely used to test the performance, scalability, and reliability of applications such as web apps, APIs, microservices, databases, and messaging systems. JMeter simulates real user traffic by generating concurrent requests and measuring how the system behaves under different loads.

Originally designed for web applications, JMeter has evolved into a full‑featured testing platform supporting REST, SOAP, JDBC, FTP, TCP, JMS, Kafka (via plugins), and more.

Why Use JMeter?

Open Source & Free – No licensing cost
Cross‑Platform – Runs on Windows, macOS, and Linux
Highly Extensible – Large ecosystem of plugins
Scalable Testing – Supports distributed (master–slave) testing
CI/CD Friendly – Can be run in headless (CLI) mode

Common Use Cases

Load testing REST and SOAP APIs
Stress testing e‑commerce applications
Performance testing microservices
Database performance testing (JDBC)
Message queue testing (RabbitMQ, Kafka, JMS)
Regression performance testing before release

Core JMeter Concepts

1. Test Plan

A Test Plan is the top‑level container that defines:

What to test
How many users to simulate
How requests are executed
What data to collect

2. Thread Group (Virtual Users)

A Thread Group represents virtual users (threads).
Key parameters:

Number of Threads (Users) – Total concurrent users
Ramp‑Up Period (seconds) – Time to start all users
Loop Count – How many times each user runs the test

Example:

Users: 100
Ramp‑up: 10 seconds → ~10 users start per second

3. Sampler

A Sampler defines the actual request sent to the server.
Common samplers:

HTTP Request (REST, Web)
JDBC Request (Database)
JMS Publisher / Subscriber
TCP Sampler

4. Config Elements

Used to define shared configuration:

HTTP Request Defaults
HTTP Header Manager
CSV Data Set Config (for test data)
User Defined Variables

5. Timers

Timers control delays between requests:

Constant Timer
Uniform Random Timer
Gaussian Random Timer

Used to simulate real user behavior.

6. Assertions

Assertions validate responses:

Response code (200, 201, etc.)
Response body contains expected text
JSON / XPath assertions

Assertions help ensure correctness, not just speed.

7. Listeners

Listeners collect and display test results:

View Results Tree (debugging)
Summary Report
Aggregate Report
Response Time Graph

⚠️ Avoid heavy listeners during large tests.

Key Performance Metrics in JMeter

Load Time – Total time to complete the request
Connect Time – Time to establish connection
Latency – Time until first byte is received
Throughput – Requests per second
Error Rate – Percentage of failed requests
Response Size – Bytes sent/received

These metrics help identify bottlenecks.

Example: E‑Commerce Load Test Scenario

Scenario:

User browses product list
User views product detail
User adds item to cart
User checks out

Thread Group Strategy:

10 users (baseline)
50 users (normal load)
100 users (peak load)
500 users (stress test)

Assertions:

HTTP 200 on browse
Cart response contains product ID
Checkout returns order ID

Running JMeter Tests

GUI Mode (Development Only)

Used for:

Creating test plans
Debugging requests

Non‑GUI Mode (Production / CI)

Recommended for load testing:

jmeter -n -t test.jmx -l result.jtl

Benefits:

Lower memory usage
Faster execution
CI/CD compatible

Best Practices

Use CSV files for test data (users, tokens)
Disable heavy listeners for large loads
Run JMeter in non‑GUI mode for real tests
Monitor server resources (CPU, memory, DB)
Start with small load, increase gradually
Separate functional testing from performance testing

Limitations of JMeter

Not a browser (no real JavaScript rendering)
High load requires tuning or distributed setup
GUI mode consumes high memory

For frontend performance, combine with tools like browser‑based testing.

Conclusion

Apache JMeter is a powerful and flexible tool for performance testing. When used correctly, it helps teams understand system limits, prevent production failures, and improve application reliability. It is especially effective for API‑based systems, microservices, and backend performance validation.

Reference: https://jmeter.apache.org/

Install ISPConfig with Nginx Webserver on Ubuntu 22.04

Siswoyo Siswoyo — Tue, 04 Nov 2025 04:08:03 +0000

Introduction

ISPConfig is a very popular open‑source hosting control panel that lets
you manage websites, email accounts, DNS records, FTP, and more. Using
Nginx as the web server is typically more performant than Apache for
many scenarios (especially static content, reverse‑proxying etc). This
guide shows how to install ISPConfig 3 + Nginx on Ubuntu 22.04, starting
from a fresh system.

Important: This setup assumes a fresh, clean OS install with
minimal/no prior custom configuration. Doing this on a server with
many existing services/configs may lead to conflicts.
(howtoforge.com)

Prerequisites

Before you begin: - A server running Ubuntu 22.04 (64‑bit) with internet
access. - A hostname set correctly (see below). - A public IP address,
reachable, DNS configured (so your hostname resolves). - Ports such as
HTTP (80), HTTPS (443), and the ISPConfig panel port (8080) must not be
blocked. - You'll be logged in as root (or using sudo). - The OS should
be essentially "clean" (no major services already installed or
customised that the auto‑installer will clobber).

Step 1: Log in to the server

sudo -s

Step 2: Configure the hostname and hosts file

Pick a fully qualified domain name (FQDN) for your server such as
server1.example.com. Do not just use example.com.

Edit /etc/hosts:

nano /etc/hosts

and ensure you have a line like:

127.0.1.1   server1.example.com   server1

Edit /etc/hostname:
```
nano /etc/hostname
```
Put only the short hostname (e.g., server1).
Reboot the server:
```
systemctl reboot
```
After reboot, verify:
```
hostname
hostname -f
```
Ensure your DNS provider has an A (and/or AAAA) record for

server1.example.com pointing to your server's public IP.

Step 3: Update the system

apt update && apt upgrade -y

Step 4: Run the auto‑installer for ISPConfig with Nginx

Now is the key part: installing ISPConfig and choosing Nginx as the web
server.

wget -O - https://get.ispconfig.org | sh -s -- --use-nginx --use-ftp-ports=40110-40210 --unattended-upgrades

What the arguments mean

--use-nginx → use Nginx instead of Apache.
--use-ftp-ports=40110-40210 → set passive FTP port range for Pure‑FTPd.
--unattended-upgrades → enables automatic updates/upgrades.

After installation completes

You'll see the generated passwords, e.g.:

[INFO] Your ISPConfig admin password is: <password>
[INFO] Your MySQL root password is: <password>

Ensure you record these.

Step 5: Setting up the firewall

Allow necessary ports through UFW or within ISPConfig UI → System →
Firewall.

TCP ports:

20,21,22,25,80,443,40110:40210,110,143,465,587,993,995,53,8080,8081

UDP:

Step 6: Finalizing

Log into ISPConfig panel:

https://server1.example.com:8080

Step 7: Adding Your Website

Once you are inside the ISPConfig panel, you can start adding new
websites under Sites → Add new site.

Before you add a website: - Ensure your domain name (e.g.,
example.com) is already pointing to your server's public IP
address. - You can check your DNS propagation and record setup using
https://dnschecker.org/.

If your domain is not yet propagated or pointing to the correct IP, the
site might not load correctly.

Steps to add a site:

Go to Sites → Add new website.
Enter your domain name (e.g., example.com).
Choose the IP address of your server (you can leave it as * if you want ISPConfig to use all available IPs).
Set PHP version, SSL (Let's Encrypt), and other options.
Save your configuration.

After saving, ISPConfig will create the Nginx virtual host configuration
automatically.

Step 8: Advanced options

--channel=<stable|dev> → choose branch
--lang=en|de → choose language
--use-php=7.4,8.1 → install specific PHP versions
--no-mail → skip mail server
--no-dns → skip DNS server
--debug → detailed log in /tmp/ispconfig-ai/var/log/ispconfig.log

Example for minimal install:

wget -O - https://get.ispconfig.org | sh -s -- --use-nginx --no-dns --no-mail --use-ftp-ports=40110-40210 --unattended-upgrades

Step 9: Troubleshooting

Rerun with --debug if installation fails.
Check /tmp/ispconfig-ai/var/log/ispconfig.log for details.
Ensure fresh OS install to avoid config conflicts.

Summary

You can now manage websites, email, DNS, databases, and FTP through
ISPConfig 3 with Nginx on Ubuntu 22.04.

Before adding sites, make sure your domain and public IP setup are
verified using DNSChecker.org.

Reference:

The `tree` Command in Ubuntu

Siswoyo Siswoyo — Fri, 10 Oct 2025 08:30:57 +0000

📌 Introduction

The tree command in Ubuntu is a powerful utility that displays the contents of directories in a tree-like structure. Instead of listing files and directories in a flat list (like ls does), it visually represents the hierarchy of directories, making it easier to understand the structure of a file system.

This is especially useful for:

Viewing project structures
Exploring configuration files
Understanding nested directories at a glance

📥 Installation

By default, tree may not be installed on Ubuntu. You can install it using:

sudo apt update
sudo apt install tree -y

To confirm installation:

tree --version

📂 Basic Usage

1. Display current directory structure

   tree

2. Show full path of files and directories

   tree -f

3. Limit depth of directory tree

   tree -L 2

(This shows only two levels deep.)

4. Show hidden files (dotfiles)

   tree -a

5. Print size of files

   tree -s

🎯 Common Options

Option	Description
`-a`	Show all files including hidden ones
`-d`	List directories only
`-L n`	Limit depth of directory tree to `n` levels
`-f`	Print full path for each file
`-s`	Show file size in bytes
`-h`	Show file size in human-readable format
`--du`	Show cumulative directory sizes
`-P`	List only files matching a pattern
`-I`	Exclude files matching a pattern

🔍 Examples

1. Display only directories up to 3 levels

   tree -d -L 3

2. Show file sizes in human-readable format

   tree -h

3. Exclude specific directories (e.g., .git)

   tree -I ".git"

4. Display project structure

   tree -L 2 -I "node_modules"

📑 Example Output

If you run tree -L 2 inside a project folder, you may get:

.
├── README.md
├── package.json
├── public
│   ├── index.html
│   └── favicon.ico
└── src
    ├── App.js
    ├── index.js
    └── components

✅ Conclusion

The tree command in Ubuntu is an essential tool for visualizing directory structures. With its various options, it allows developers, system administrators, and everyday users to quickly understand and navigate complex file systems.

Reference: https://manpages.ubuntu.com/manpages/jammy/man1/tree.1.html

Control Your Android on PC with Vysor

Siswoyo Siswoyo — Wed, 10 Sep 2025 05:03:50 +0000

Managing your Android device directly from your PC can greatly improve productivity, especially if you’re multitasking between your phone and computer. Vysor is a powerful tool that lets you mirror and control your Android device from your Windows, macOS, Linux, or even Chrome browser.

What is Vysor?

Vysor is a screen mirroring application developed by Koushik Dutta. It allows you to:

View your Android screen on your PC.
Control your phone using your keyboard and mouse.
Take screenshots and record your screen.
Drag and drop files between your PC and Android device (Pro feature).

It’s especially useful for developers, customer support agents, or anyone who wants to interact with their phone without constantly switching devices.

Key Features

Simple Setup – Install the app on both your PC and Android device and connect via USB or Wi-Fi.
Cross-Platform Support – Works on Windows, macOS, Linux, and even Chrome.
Keyboard & Mouse Control – Type messages, play games, and navigate apps seamlessly.
File Sharing – Drag and drop files (Pro version).
Screen Recording – Record your Android screen directly from your PC.

How to Use Vysor

1. Install Vysor

Download and install Vysor on your PC from the official website: https://www.vysor.io.
Install the Vysor app from the Google Play Store on your Android device.

2. Install ADB Drivers (Windows Users)

To let your PC communicate with your Android phone, you need ADB (Android Debug Bridge) drivers.

Download the Universal ADB Driver: https://adb.clockworkmod.com
Run the installer and follow the on-screen instructions.
Once installed, reconnect your Android device via USB.
Your PC should now recognize the phone when using Vysor.

💡 Note for Mac/Linux users: You don’t need to install extra drivers; ADB works out of the box.

3. Enable USB Debugging

On your Android device, go to Settings > About Phone > Tap “Build Number” 7 times to enable Developer Options.
Go to Settings > Developer Options > Enable USB Debugging.
Confirm the USB Debugging prompt when connecting your device to the PC.

4. Connect Your Device

Plug your Android device into your PC using a USB cable (Wi-Fi connection available in the Pro version).
Open Vysor on your PC, and your device should appear in the list.
Click View to start mirroring your Android screen.

Android

5. Control Your Device

Use your keyboard to type messages.
Navigate apps with your mouse.
Enjoy seamless control without constantly switching between devices.

Free vs Pro

Free version: Includes screen mirroring and basic controls with ads.
Pro version: Removes ads, adds Wi-Fi connectivity, full-screen mode, drag-and-drop, and HD quality.
You can check the latest pricing and subscription options here: Vysor Pricing – around $2.50/mo, $10/yr, or $40 lifetime as listed on their site.

Benefits of Using Vysor

✅ Boosts productivity for developers and office users.
✅ Easy for tech support to guide customers remotely.
✅ Great for presentations and demos.
✅ Makes mobile gaming easier on a larger screen.

References

👉 With Vysor + ADB drivers, you can fully control your Android from your PC with ease. Perfect for work, support, or entertainment.

Homelab: A Complete Overview

Siswoyo Siswoyo — Tue, 02 Sep 2025 16:33:01 +0000

📌 What is a Homelab?

A homelab is a personal environment where you experiment with technology, servers, and networking outside of production systems. It’s commonly used by IT enthusiasts, developers, and system administrators to learn, test, and self-host services at home.

Homelabs can range from a simple single-PC setup to a rack of enterprise-grade servers.

🎯 Why Build a Homelab?

Learning & Experimentation Practice new technologies like Docker, Kubernetes, virtualization, and networking.
Skill Development Gain hands-on experience for IT certifications and real-world problem-solving.
Self-Hosting Run your own cloud services such as Nextcloud, media servers, VPN, or password managers.
Automation Practice Experiment with tools like Ansible, Terraform, and CI/CD pipelines.
Cost Savings Repurpose old hardware instead of relying on expensive cloud providers.

🛠️ Common Homelab Components

1. Hardware

Old desktop PCs or laptops
Mini PCs (Intel NUC, Raspberry Pi)
Used enterprise servers (Dell PowerEdge, HP ProLiant)
Network equipment (routers, switches, firewalls)

2. Virtualization & Containers

Proxmox – open-source virtualization
VMware ESXi – enterprise-grade hypervisor
Docker – container platform for apps
Kubernetes / K3s – container orchestration

3. Networking

VLANs, VPNs, firewalls
Pi-hole for DNS-level ad blocking
pfSense or OPNsense for routing & security

4. Services to Run

Media servers: Plex, Jellyfin
File storage: Nextcloud, Syncthing
DevOps tools: GitLab, Jenkins
Monitoring: Grafana, Prometheus
Home automation: Home Assistant

🧑‍💻 Example Homelab Setup

Server: Old Dell PowerEdge with 32GB RAM
Virtualization: Proxmox for managing VMs
Containers: Docker running Nextcloud, Plex, Grafana
Network: pfSense firewall + Pi-hole DNS
Storage: RAID-configured NAS for backups

⚡ Tips for Building Your Homelab

Start small – repurpose an old laptop or Raspberry Pi.
Document everything – keep notes on configs and setups.
Use automation – learn Ansible/Terraform to manage infrastructure.
Backup frequently – test disaster recovery.
Keep it secure – use strong passwords, VPN, and firewalls.

📚 Resources to Get Started

✅ A homelab is not just a playground—it’s a personal cloud, learning lab, and automation hub.

Transaction Numbers in a System

Siswoyo Siswoyo — Mon, 01 Sep 2025 18:11:43 +0000

When designing a system that handles financial or operational transactions (e.g., orders, invoices, payments, shipments), one of the most important considerations is how transaction numbers are generated and managed.

Why Transaction Numbers Are Important

Uniqueness → Every transaction must be identifiable without confusion.
Traceability → Makes it easy to track and audit transactions.
Integration → When multiple services or systems are involved, transaction numbers must remain consistent.
User Reference → Customers and staff often need a simple reference number for communication.

Common Approaches to Transaction Numbers

1. Auto-Increment Serial (Sequential Numbers)

Example: TRX-000001, TRX-000002, TRX-000003
Pros:
- Simple and human-friendly.
- Easy to track the count of transactions.
Cons:
- Hard to merge across multiple systems (risk of duplicate numbers).
- Predictable numbers can expose business volume.

2. UUID (Universally Unique Identifier)

Example: d290f1ee-6c54-4b01-90e6-d701748f0851
Pros:
- Guaranteed uniqueness across systems and services.
- No collision issues when merging data.
Cons:
- Not user-friendly.
- Longer to store and index in databases.

3. Hybrid Format (Prefix + Date + Sequence / UUID)

Example: INV-20250819-0012 or PAY-2025-08-19-XYZ123
Pros:
- Human-readable with context (date, type).
- Sequence helps ordering within a day.
- Can still incorporate randomness or UUID for uniqueness.
Cons:
- Slightly more complex to implement.

Recommended Practice

For internal system identifiers: use UUIDs to ensure uniqueness, especially in distributed or microservice architectures.
For user-facing transaction numbers: generate a readable sequence with prefixes and dates (e.g., ORD-20250819-0456).
Store both values:
- Primary Key / Internal ID → UUID
- Public Transaction Number → Sequential or Hybrid format

Example: Dual Identifier Approach

Field	Example Value	Purpose
`transaction_id` (UUID)	`a9c3b5f4-2e4b-4ef9-a2af...`	Internal system reference
`transaction_no`	`ORD-20250819-0456`	User-facing, easy to reference

This way, the system remains scalable, merge-friendly, and user-friendly.

SQL Schema Example

Below is a PostgreSQL example showing how to implement this approach:

CREATE TABLE transactions (
    transaction_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- Internal unique ID
    transaction_no VARCHAR(50) UNIQUE NOT NULL,                -- Public transaction number
    transaction_type VARCHAR(20) NOT NULL,                     -- e.g. ORDER, PAYMENT, INVOICE
    transaction_date TIMESTAMP NOT NULL DEFAULT NOW(),
    customer_id UUID NOT NULL,
    amount NUMERIC(12,2) NOT NULL,
    status VARCHAR(20) NOT NULL DEFAULT 'PENDING'
);

-- Example: Insert with a generated transaction number
INSERT INTO transactions (transaction_no, transaction_type, customer_id, amount)
VALUES (
    CONCAT('ORD-', TO_CHAR(NOW(), 'YYYYMMDD'), '-', LPAD(nextval('transaction_seq')::TEXT, 4, '0')),
    'ORDER',
    '550e8400-e29b-41d4-a716-446655440000',
    150000.00
);

-- Sequence for daily increment
CREATE SEQUENCE transaction_seq START 1;

-- Example: Insert with a generated transaction number
INSERT INTO transactions (transaction_no, transaction_type, customer_id, amount)
VALUES (
    CONCAT('ORD-', TO_CHAR(NOW(), 'YYYYMMDD'), '-', LPAD(nextval('transaction_seq')::TEXT, 4, '0')),
    'ORDER',
    '550e8400-e29b-41d4-a716-446655440000',
    150000.00
);

Relationships with Other Tables

When designing related tables, always use transaction_id (UUID) as the foreign key.
Each related table should also have its own unique reference number (payment_no, shipment_no).

Payments Table

CREATE TABLE payments (
    payment_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- Internal unique ID
    payment_no VARCHAR(50) UNIQUE NOT NULL,                -- Public payment number
    transaction_id UUID NOT NULL REFERENCES transactions(transaction_id) ON DELETE CASCADE,
    payment_date TIMESTAMP NOT NULL DEFAULT NOW(),
    payment_method VARCHAR(50) NOT NULL,
    amount NUMERIC(12,2) NOT NULL
);

-- Sequence for payments
CREATE SEQUENCE payment_seq START 1;

-- Example insert
INSERT INTO payments (payment_no, transaction_id, payment_method, amount)
VALUES (
    CONCAT('PAY-', TO_CHAR(NOW(), 'YYYYMMDD'), '-', LPAD(nextval('payment_seq')::TEXT, 4, '0')),
    'a9c3b5f4-2e4b-4ef9-a2af-123456789abc',
    'CREDIT_CARD',
    150000.00
);

Shipments Table

CREATE TABLE shipments (
    shipment_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- Internal unique ID
    shipment_no VARCHAR(50) UNIQUE NOT NULL,                -- Public shipment number
    transaction_id UUID NOT NULL REFERENCES transactions(transaction_id) ON DELETE CASCADE,
    courier VARCHAR(50) NOT NULL,
    tracking_no VARCHAR(100),
    shipped_date TIMESTAMP
);

-- Sequence for shipments
CREATE SEQUENCE shipment_seq START 1;

-- Example insert
INSERT INTO shipments (shipment_no, transaction_id, courier, tracking_no, shipped_date)
VALUES (
    CONCAT('SHP-', TO_CHAR(NOW(), 'YYYYMMDD'), '-', LPAD(nextval('shipment_seq')::TEXT, 4, '0')),
    'a9c3b5f4-2e4b-4ef9-a2af-123456789abc',
    'DHL',
    'DHL123456789',
    NOW()
);

Why Use UUID for Relations but Public Numbers for Reference?

UUID (transaction_id, payment_id, shipment_id) → Used for database relations, stable and permanent.
Public numbers (transaction_no, payment_no, shipment_no) → Used for communication with users, human-friendly, and can include business context (prefix, date, sequence).
This ensures data integrity inside the system while providing clear references outside the system.

How to Create a Bootable USB Windows 10 Using Rufus

Siswoyo Siswoyo — Wed, 27 Aug 2025 16:44:36 +0000

Creating a bootable USB drive is one of the easiest and most reliable ways to install or reinstall Windows 10. With the help of Rufus, a lightweight and free utility, you can prepare a USB stick to install Windows quickly.

✅ What You Need

Before starting, make sure you have the following:

A USB flash drive (at least 8 GB in size).
A Windows 10 ISO file (you can download it from the Microsoft website).
The latest version of Rufus (download here).

🔧 Steps to Create Bootable USB with Rufus

1. Download and Install Rufus

Visit the Rufus official website.
Download the latest version (portable, no installation required).
Open the program by double-clicking Rufus.exe.

2. Insert Your USB Drive

Plug your USB flash drive into your computer.
Rufus will automatically detect it under Device.

⚠️ Note: All data on the USB will be erased. Backup your important files first.

3. Select Windows 10 ISO File

Under Boot selection, click SELECT.
Browse and choose the Windows 10 ISO file you downloaded.

4. Configure Partition Scheme

Partition scheme:
- Choose MBR if installing on BIOS/Legacy systems.
- Choose GPT if installing on UEFI systems.
File system: Leave as NTFS (default).
Cluster size: Leave as default.

5. Start Creating Bootable USB

Once settings are ready, click START.
Rufus may prompt to download additional files—accept if needed.
A warning will appear that all data on the USB will be destroyed. Click OK to proceed.

6. Wait for Completion

Rufus will format the USB and copy all Windows installation files.
The process may take several minutes depending on USB speed.
When the status bar turns green and says READY, your bootable USB is done.

🚀 How to Use the Bootable USB

Insert the USB drive into the target computer.
Restart the computer and enter the boot menu (usually by pressing F2, F12, ESC, or DEL, depending on manufacturer).
Select your USB drive as the boot device.
Follow the on-screen instructions to install Windows 10.

🎯 Conclusion

Using Rufus makes creating a bootable USB for Windows 10 simple and fast. With just a few steps—selecting your USB, choosing the ISO, and starting the process—you’ll be ready to install or repair Windows 10 on any computer.

🎂 Happy Belated Birthday, Linux! 🐧💻

Siswoyo Siswoyo — Tue, 26 Aug 2025 13:20:30 +0000

On 25 August 1991, a young Finnish computer science student named Linus Torvalds posted a short message on the MINIX newsgroup. In it, he introduced his new project: a free operating system kernel. At the time, he called it “just a hobby, won’t be big and professional like GNU.”

That “hobby” turned into Linux — and the world of technology has never been the same.

🌱 The Beginning

Torvalds’ announcement on 25 August 1991 sparked something special. By releasing his source code and inviting collaboration, he planted the seed for a project that would grow into a global movement. Developers everywhere joined in, contributing ideas, fixes, and improvements.

This open and collaborative model became the DNA of Linux, and it remains its strength to this day.

📜 Key Milestones in Linux History

25 Aug 1991 – Linus Torvalds announces Linux to the world.
1992 – Linux adopts the GNU General Public License (GPL), ensuring it remains free and open-source.
1996 – Tux the Penguin, designed by Larry Ewing, becomes the official Linux mascot.
2000s – Linux becomes the backbone of the internet, powering the majority of servers.
2008 – Android, built on the Linux kernel, begins transforming the mobile industry.
Today – Linux powers 96% of the top 1 million servers, all of the world’s top 500 supercomputers, and is at the heart of cloud platforms, containers, and IoT.

🌍 The Impact of Linux

Linux is more than an operating system — it’s a philosophy and a community.

Freedom – Anyone can study, modify, and share it.
Collaboration – Thousands of contributors worldwide continue to evolve it.
Innovation – From smartphones to space missions, Linux makes the impossible possible.

Without Linux, the internet, mobile computing, AI research, and even cloud platforms would look completely different.

🎉 Celebrating Linux Today

Though we’re a little late to say it:

🎉 Happy Belated Birthday, Linux! 🐧

More than three decades later, Linux remains a symbol of openness, stability, and progress. From students learning their first command line to engineers deploying global infrastructure — Linux belongs to everyone.

Here’s to the next chapter of innovation and community-driven growth. 💻✨

Choosing `UUID` for Unique IDs in a Multi-System Environment

Siswoyo Siswoyo — Sat, 23 Aug 2025 11:42:41 +0000

When designing a database schema, the choice of unique identifier is critical for scalability, data integration, and future-proofing. While databases traditionally use SERIAL (auto-increment integers), in modern distributed and service-oriented architectures, UUID (Universally Unique Identifier) is often the better choice.

Why Not `SERIAL`?

A SERIAL or BIGSERIAL column generates sequential IDs (1, 2, 3...). This works fine for a single, isolated database but creates challenges when scaling:

ID collisions during merges: Two different systems may both have a record with id = 100. Merging them becomes complex.
Predictable IDs: The sequence can reveal the number of records (e.g., knowing you have 50,000 customers).
Sharding and replication issues: Multiple services writing to their own databases may generate overlapping IDs.

Why Use `UUID` Everywhere?

A UUID is a 128-bit identifier that is globally unique. Using UUIDs for both master tables (e.g., customers, products) and transaction tables (e.g., orders, invoices) brings key benefits:

✅ Advantages

Seamless data merging

Whether merging customers or orders across services, IDs will never clash. This simplifies integration projects.
Supports distributed systems

Microservices, event-driven architectures, and multi-database systems can generate IDs independently without coordination.
Future-proofing

Even if today you only have one database, tomorrow you might need to replicate, shard, or consolidate with another system.
Security

UUIDs are non-sequential, making it harder for outsiders to guess the number of records or enumerate IDs.

⚠️ Trade-offs

Larger storage size (16 bytes vs. 4 bytes for integers).
Slightly slower indexing and joins.
Harder to read/debug manually (though often hidden behind APIs).

Example Schema

Master Table: Customers

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

CREATE TABLE customers (
    customer_id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    name VARCHAR(100) NOT NULL,
    email VARCHAR(100) UNIQUE NOT NULL
);

Transaction Table: Orders

CREATE TABLE orders (
    order_id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    customer_id UUID NOT NULL REFERENCES customers(customer_id),
    order_date TIMESTAMP DEFAULT now(),
    amount NUMERIC(10,2) NOT NULL
);

Final Decision

If your system might merge data across multiple databases, services, or environments,
then the consistent choice is to use UUID for all primary keys — both master data and transactional data.

This avoids conflicts, simplifies future integrations, and aligns with best practices for distributed systems.

DEV Community: Siswoyo Siswoyo

stress-ng vs sysbench

stress-ng vs sysbench

1. Overview

2. stress-ng

Core features

Control and configuration

Measurement and reporting

Common uses

Example commands

3. sysbench

Core features

Example commands

4. Key Differences

5. Which One Should You Use?

Using them together

6. Summary

YAGNI: You Aren't Gonna Need It

YAGNI: You Aren't Gonna Need It

What Is YAGNI?

Why Speculative Features Are a Problem

A Simple Example

❌ Violating YAGNI

✅ Following YAGNI

When Should You Add Something?

Common YAGNI Violations

What YAGNI Is Not

YAGNI vs. Related Principles

Caveat: When Anticipating the Future Is Reasonable

Key Takeaways

Architecture Comparison: NGINX Only vs NGINX + API Gateway

Overview

Architecture Diagrams

Option 1 — NGINX Only

Option 2 — NGINX + API Gateway

Comparison by Category

1. Complexity

2. Performance

3. Routing

4. Security

5. Scalability

6. Observability & Monitoring

7. Rate Limiting

8. Development Speed

9. Cost & Resource Usage

10. Enterprise Features

Summary Scorecard

Recommendation

Apache JMeter – Overview and Practical Guide

What is Apache JMeter?

Why Use JMeter?

Common Use Cases

Core JMeter Concepts

1. Test Plan

2. Thread Group (Virtual Users)

3. Sampler

4. Config Elements

5. Timers

6. Assertions

7. Listeners

Key Performance Metrics in JMeter

Example: E‑Commerce Load Test Scenario

Running JMeter Tests

GUI Mode (Development Only)

Non‑GUI Mode (Production / CI)

Best Practices

Limitations of JMeter

Conclusion

Install ISPConfig with Nginx Webserver on Ubuntu 22.04

Introduction

Prerequisites

Step 1: Log in to the server

Step 2: Configure the hostname and hosts file

Step 3: Update the system

Step 4: Run the auto‑installer for ISPConfig with Nginx

What the arguments mean

After installation completes

Step 5: Setting up the firewall

Step 6: Finalizing

Step 7: Adding Your Website

Step 1: Log in to the server

Step 2: Configure the hostname and hosts file

Step 3: Update the system

Step 4: Run the auto‑installer for ISPConfig with Nginx

Step 5: Setting up the firewall

Step 6: Finalizing

Step 7: Adding Your Website

Step 8: Advanced options

Step 9: Troubleshooting

Why Not `SERIAL`?

Why Use `UUID` Everywhere?