0) Readiness & Goals

since you’re on XAMPP + Laravel + PHP + MySQL + Linux, and you want SLIs (latency, error rate, throughput) & metrics just in your Dev environment, you don’t need enterprise-grade APMs like New Relic yet. Laravel/PHP has some native and lightweight options that can give you per-request response time, DB query timings, and code profiling.

Here’s a structured set of recommendations:

🔹 Native / Laravel-Friendly Tooling

1. Laravel Telescope (Official)

• What it does:
  • Profiles each request (execution time, memory, status code).
  • Shows all queries with timing, N+1 warnings, slow query detection.
  • Displays jobs, cache hits/misses, exceptions, mail, logs, etc.
• Why good for Dev: Easy to install, beautiful dashboard, zero external infra.
• Install: composer require laravel/telescope --dev php artisan telescope:install php artisan migrate php artisan serve
• Accessible at /telescope in dev.

2. Laravel Debugbar

• What it does:
  • Adds a debug toolbar at the bottom of each page.
  • Shows request duration, memory usage, DB queries with time.
  • Highlights slow queries and duplicate queries.
• Why good for Dev: Extremely lightweight, immediate visibility.
• Install: composer require barryvdh/laravel-debugbar --dev

3. Clockwork

• What it does:
  • Adds Chrome/Firefox extension for profiling Laravel requests.
  • Records request duration, queries, cache, events, logs, timeline.
  • More “developer-friendly” than Debugbar because it integrates with browser dev tools.
• Install: composer require itsgoingd/clockwork --dev php artisan vendor:publish --tag=clockwork-config
• View in Clockwork browser extension or /__clockwork endpoint.

4. XHProf / Tideways / Blackfire (Low-Level Profilers)

• What they do:
  • Provide per-function and per-line profiling.
  • Show CPU time, memory usage, call counts.
  • Help track bottlenecks beyond queries (e.g., loops, serialization).
• Why good for Dev: Deeper insight when Laravel Telescope/Debugbar isn’t enough.
• Options:
  • XHProf (free, simple, supported by XHGUI web UI).
  • Tideways/XHProf fork (better maintained).
  • Blackfire.io (commercial but free Dev tier).

🔹 Metrics & SLI Extraction

Since you want SLIs (latency, error rate, throughput), you can:

1. Use Laravel Telescope / Debugbar Data
   • Export query logs & request timings → store in Prometheus/Grafana (optional).
2. Laravel Prometheus Exporter
   • Package: superbalist/laravel-prometheus-exporter.
   • Exposes a /metrics endpoint for Prometheus with:
     • Request duration histogram
     • Query count & time
     • Cache hits/misses
     • Jobs queued/processed
3. Self-hosted Grafana + Prometheus (optional for Dev)
   • Pull /metrics endpoint.
   • Create SLI dashboards:
     • Latency: http_request_duration_seconds p95, p99.
     • Error rate: http_requests_total{status="5xx"} / http_requests_total.
     • Traffic: requests/sec.

✅ Suggested Dev Setup (Practical & Lightweight)

1. Start with Laravel Telescope → best native tool for queries + request profiling.
2. Add Clockwork or Debugbar → for real-time in-browser visibility.
3. If you want structured SLI metrics → add Laravel Prometheus Exporter and run Prometheus + Grafana in Docker.
4. For deeper profiling → plug in XHProf/XHGUI when you hit complex bottlenecks.

👉 My recommendation:

• Use Telescope + Debugbar for day-to-day dev.
• Add Prometheus Exporter only if you want a Grafana SLI dashboard.
• Keep XHProf/XHGUI in your toolkit for deep-dive debugging.

Database

Great question. Here’s a practical, safe set of MySQL/MariaDB settings you can enable/tune to process queries efficiently and avoid CPU/memory blow-ups, tailored for a web app (Laravel/PHP) on InnoDB. I’ve grouped them by purpose and included suggested starting values plus a ready-to-drop my.cnf template. (Use InnoDB everywhere; avoid MyISAM for OLTP.)

Key principles (before you tune)

• Prefer InnoDB; set proper memory split: big “global” InnoDB cache, small “per-connection” buffers (to avoid RAM spikes).
• Keep max_connections realistic; too high → memory explosion under load.
• Turn on slow query log and fix queries/indexes first—it’s the biggest win.

A) Core InnoDB memory & durability

B) Concurrency & CPU

C) Per-connection memory (prevent RAM blow-ups)

These allocate per connection. Keep them modest and keep max_connections realistic.

D) Optimizer & SQL safety

E) I/O & background

F) Logging & instrumentation

G) Binary logs & timeouts (dev vs prod)

H) MariaDB specifics (if you’re on MariaDB)

Ready-to-use my.cnf template (Linux)

Adjust memory-sized values to your RAM. Example below assumes ~16GB host primarily for MySQL.

[mysqld]
# General
user = mysql
bind-address = 0.0.0.0
skip-name-resolve
sql_require_primary_key = ON

# InnoDB core
default_storage_engine = InnoDB
innodb_buffer_pool_size = 10G
innodb_buffer_pool_instances = 2
innodb_log_file_size = 1G
innodb_log_buffer_size = 256M
innodb_flush_log_at_trx_commit = 2      # 1 in prod for full durability
innodb_flush_method = O_DIRECT
innodb_file_per_table = 1
innodb_flush_neighbors = 0
innodb_autoinc_lock_mode = 2
innodb_io_capacity = 1000
innodb_read_io_threads = 4
innodb_write_io_threads = 4

# Concurrency & caches
table_open_cache = 4000
table_definition_cache = 2000
open_files_limit = 65535
max_connections = 250
thread_cache_size = 64

# Per-connection memory (keep conservative)
tmp_table_size = 128M
max_heap_table_size = 128M
join_buffer_size = 1M
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 1M

# Logging & instrumentation
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.2
log_queries_not_using_indexes = ON
performance_schema = ON

# Binary log (dev)
skip-log-bin
# For prod:
# log_bin = /var/lib/mysql/binlog
# sync_binlog = 1

# Timeouts
wait_timeout = 120
interactive_timeout = 600
Code language: PHP (php)

After changing redo log size (innodb_log_file_size), stop MySQL cleanly, rename old ib_logfiles if needed (MySQL 5.7), then start.

How to confirm impact (quick checks)

• Memory planning (rule of thumb)
  Total RAM ≈ innodb_buffer_pool_size + global overhead + (max_connections × per-connection buffers peak)
  → Keep buffers modest; don’t push max_connections beyond what RAM allows.
• Watch these during load:
  • SHOW GLOBAL STATUS LIKE 'Threads_connected';
  • SHOW GLOBAL STATUS LIKE 'Opened_tables'; (shouldn’t climb too fast)
  • SHOW ENGINE INNODB STATUS; (check buffer pool hit rate, waits)
  • EXPLAIN ANALYZE <query> (MySQL 8+/MariaDB), fix missing indexes.
• Tune iteratively: raise table_open_cache if Opened_tables grows; reduce per-connection buffers if memory spikes; if CPU high with many threads, MariaDB thread_pool=ON (or reduce max_connections).

Safe rollout order

1. Turn on slow log and fix top queries/indexes.
2. Set buffer pool (and redo log) to match RAM.
3. Cap max_connections and shrink per-connection buffers.
4. Enable skip-name-resolve, tune table caches.
5. Consider thread pool (MariaDB) and I/O capacity.
6. Re-test; iterate.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.