Vengala Vinay

Having 9+ Years of Experience in Software Development

Home » Performance Comparison: Running Laravel Swoole vs Go (Golang) Under Heavy Concurrency Benchmarks

Performance Comparison: Running Laravel Swoole vs Go (Golang) Under Heavy Concurrency Benchmarks

Benchmarking Methodology: Setting the Stage

To provide a meaningful comparison between Laravel Swoole and Go (Golang) for high-concurrency scenarios, a rigorous benchmarking methodology is essential. We’ll focus on simulating realistic web application loads, specifically targeting API endpoints that involve database interaction and moderate CPU-bound processing. The goal is to measure throughput (requests per second) and latency (response time) under increasing concurrent user loads.

Our benchmark will simulate a typical e-commerce API endpoint, such as fetching product details with associated reviews. This involves a database query for product information and another for related reviews. For the Go benchmark, we’ll use a standard `net/http` server with a PostgreSQL database. For Laravel Swoole, we’ll leverage the Swoole extension within a standard Laravel application, also connected to PostgreSQL.

Environment Setup: Consistency is Key

Achieving a fair comparison necessitates a consistent and isolated environment. We will deploy both applications on identical hardware. For this benchmark, we’ll use cloud instances with the following specifications:

  • CPU: 8 vCPUs
  • RAM: 16 GB
  • Storage: 100 GB SSD
  • Network: 1 Gbps
  • Operating System: Ubuntu 22.04 LTS

The database will be a managed PostgreSQL instance (AWS RDS or equivalent) with identical configurations for both benchmarks, ensuring that database performance is not a differentiating factor. Connection pooling will be enabled for both applications to mitigate connection overhead.

Go (Golang) Implementation: A Lean API Endpoint

We’ll create a simple Go HTTP server that handles a GET request to an endpoint like `/api/products/{id}`. This endpoint will fetch product data and its reviews from PostgreSQL. For simplicity, we’ll use the `pgx` driver for database interaction and `goroutines` for concurrency.

Go Server Code (main.go)

package main

import (
	"database/sql"
	"encoding/json"
	"fmt"
	"log"
	"net/http"
	"os"
	"strconv"
	"time"

	_ "github.com/jackc/pgx/v4/stdlib"
)

type Product struct {
	ID          int    `json:"id"`
	Name        string `json:"name"`
	Description string `json:"description"`
}

type Review struct {
	ID        int    `json:"id"`
	ProductID int    `json:"product_id"`
	Author    string `json:"author"`
	Comment   string `json:"comment"`
}

type ProductDetails struct {
	Product Product  `json:"product"`
	Reviews []Review `json:"reviews"`
}

var db *sql.DB

func main() {
	// Database connection string from environment variable
	dbConnectionString := os.Getenv("DATABASE_URL")
	if dbConnectionString == "" {
		log.Fatal("DATABASE_URL environment variable not set")
	}

	var err error
	db, err = sql.Open("pgx", dbConnectionString)
	if err != nil {
		log.Fatalf("Failed to connect to database: %v", err)
	}
	defer db.Close()

	// Configure connection pool
	db.SetMaxOpenConns(100) // Adjust based on expected concurrency
	db.SetMaxIdleConns(50)
	db.SetConnMaxLifetime(5 * time.Minute)

	err = db.Ping()
	if err != nil {
		log.Fatalf("Failed to ping database: %v", err)
	}

	http.HandleFunc("/api/products/", handleProductDetails)
	log.Println("Starting server on :8080")
	log.Fatal(http.ListenAndServe(":8080", nil))
}

func handleProductDetails(w http.ResponseWriter, r *http.Request) {
	// Extract product ID from URL
	productIDStr := r.URL.Path[len("/api/products/"):]
	productID, err := strconv.Atoi(productIDStr)
	if err != nil {
		http.Error(w, "Invalid product ID", http.StatusBadRequest)
		return
	}

	// Fetch product
	var product Product
	err = db.QueryRow("SELECT id, name, description FROM products WHERE id = $1", productID).Scan(&product.ID, &product.Name, &product.Description)
	if err != nil {
		if err == sql.ErrNoRows {
			http.Error(w, "Product not found", http.StatusNotFound)
			return
		}
		log.Printf("Error fetching product: %v", err)
		http.Error(w, "Internal server error", http.StatusInternalServerError)
		return
	}

	// Fetch reviews
	rows, err := db.Query("SELECT id, product_id, author, comment FROM reviews WHERE product_id = $1", productID)
	if err != nil {
		log.Printf("Error fetching reviews: %v", err)
		http.Error(w, "Internal server error", http.StatusInternalServerError)
		return
	}
	defer rows.Close()

	var reviews []Review
	for rows.Next() {
		var review Review
		if err := rows.Scan(&review.ID, &review.ProductID, &review.Author, &review.Comment); err != nil {
			log.Printf("Error scanning review row: %v", err)
			http.Error(w, "Internal server error", http.StatusInternalServerError)
			return
		}
		reviews = append(reviews, review)
	}
	if err = rows.Err(); err != nil {
		log.Printf("Error iterating review rows: %v", err)
		http.Error(w, "Internal server error", http.StatusInternalServerError)
		return
	}

	details := ProductDetails{
		Product: product,
		Reviews: reviews,
	}

	w.Header().Set("Content-Type", "application/json")
	json.Enc := json.NewEncoder(w)
	if err := jsonEnc.Encode(details); err != nil {
		log.Printf("Error encoding JSON response: %v", err)
		http.Error(w, "Internal server error", http.StatusInternalServerError)
	}
}

Go Build and Run Commands

# Build the application
go build -o product_api main.go

# Run the application (replace with your actual DB URL)
export DATABASE_URL="postgresql://user:password@host:port/dbname?sslmode=disable&pool_max_conns=100"
./product_api

Laravel Swoole Implementation: Leveraging the PHP Ecosystem

For Laravel, we’ll install the Swoole PHP extension and the `swoole-laravel` package. The application logic will remain largely the same as a standard Laravel API endpoint, but Swoole will manage the event loop and worker processes, eliminating the overhead of traditional PHP-FPM request handling.

Installation and Configuration

# Install Swoole PHP extension (example for Ubuntu/Debian)
sudo apt update
sudo apt install php8.1-swoole -y # Adjust PHP version as needed

# Install swoole-laravel package
composer require swoole/laravel

# Publish Swoole configuration
php artisan vendor:publish --provider="Swoole\Laravel\SwooleServiceProvider"

# Configure Swoole settings in config/swoole.php
# Ensure 'mode' is set to SWOOLE_PROCESS or SWOOLE_THREAD
# Adjust 'reactor_num' and 'worker_num' based on CPU cores

Laravel Controller (app/Http/Controllers/ProductController.php)

<?php

namespace App\Http\Controllers;

use App\Models\Product;
use App\Models\Review;
use Illuminate\Http\JsonResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\DB;

class ProductController extends Controller
{
    /**
     * Display the specified resource.
     */
    public function show(string $id): JsonResponse
    {
        // Use database transactions for consistency if needed, but for read-heavy,
        // direct queries are often faster.
        // For this benchmark, we'll use direct queries.

        $product = Product::find($id);

        if (!$product) {
            return response()->json(['message' => 'Product not found'], 404);
        }

        // Fetch reviews using Eloquent or Query Builder
        // Using Query Builder for potentially better performance in high concurrency
        $reviews = DB::table('reviews')
                     ->where('product_id', $id)
                     ->get(['id', 'product_id', 'author', 'comment']);

        return response()->json([
            'product' => $product,
            'reviews' => $reviews,
        ]);
    }
}

Laravel Routes (routes/api.php)

<?php

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Route;
use App\Http\Controllers\ProductController;

Route::get('/products/{id}', [ProductController::class, 'show']);

Starting the Laravel Swoole Server

# Ensure your .env file has the correct database credentials
# Example: DB_HOST=... DB_PORT=... DB_DATABASE=... DB_USERNAME=... DB_PASSWORD=...

# Start the Swoole server
php artisan swoole:http start

Load Generation: ApacheBench (ab)

We will use ApacheBench (`ab`) to generate concurrent load. `ab` is a command-line tool that sends a specified number of requests with a specified concurrency level to a web server. We’ll run `ab` from a separate machine to avoid impacting the server under test.

Benchmark Commands

We’ll test with increasing concurrency levels, starting from 100 and going up to 1000 concurrent users, with a total of 10,000 requests per test run. The URL will be the API endpoint for a specific product (e.g., `/api/products/1`).

# For Go server (assuming it's running on 192.168.1.100:8080)
ab -n 10000 -c 100 http://192.168.1.100:8080/api/products/1
ab -n 10000 -c 250 http://192.168.1.100:8080/api/products/1
ab -n 10000 -c 500 http://192.168.1.100:8080/api/products/1
ab -n 10000 -c 750 http://192.168.1.100:8080/api/products/1
ab -n 10000 -c 1000 http://192.168.1.100:8080/api/products/1

# For Laravel Swoole server (assuming it's running on 192.168.1.100:9000)
ab -n 10000 -c 100 http://192.168.1.100:9000/api/products/1
ab -n 10000 -c 250 http://192.168.1.100:9000/api/products/1
ab -n 10000 -c 500 http://192.168.1.100:9000/api/products/1
ab -n 10000 -c 750 http://192.168.1.100:9000/api/products/1
ab -n 10000 -c 1000 http://192.168.1.100:9000/api/products/1

Analyzing the Results: Throughput and Latency

After running the benchmarks, we’ll analyze the output from `ab`, focusing on:

  • Requests per second: Higher is better, indicating the server’s capacity to handle concurrent requests.
  • Time per request (mean): Lower is better, representing the average response time.
  • Transfer rate: Indicates network throughput.
  • Percentage of requests served within a certain time: Crucial for understanding user experience under load.

We’ll also monitor server-side resource utilization (CPU, memory) using tools like `htop` or `top` during the benchmark runs to identify potential bottlenecks.

Expected Outcomes and Considerations

Generally, Go is expected to outperform PHP (even with Swoole) in raw performance due to its compiled nature, efficient concurrency model (goroutines), and lower memory footprint. Go’s standard library is highly optimized for network services.

However, Laravel Swoole significantly closes the gap by providing a high-performance, event-driven runtime for PHP. It eliminates the request-per-process overhead of PHP-FPM, allowing PHP applications to achieve much higher concurrency and lower latency. For teams already heavily invested in the Laravel ecosystem, Swoole offers a compelling path to dramatically improve performance without a complete rewrite.

Key factors influencing the comparison:

  • Code complexity: Go’s simplicity can lead to more efficient code. PHP’s flexibility, while powerful, can sometimes lead to less optimized code if not carefully managed.
  • Database interaction: The efficiency of database drivers and connection pooling is critical for both.
  • Swoole configuration: Proper tuning of `reactor_num`, `worker_num`, and `task_worker_num` in `config/swoole.php` is vital for Laravel Swoole.
  • PHP extensions: The performance of any third-party PHP extensions used in the Laravel app can impact overall results.
  • Garbage Collection: Go’s garbage collector can introduce pauses, though it’s highly optimized. PHP’s memory management is different and can also have performance implications.

Conclusion: Making the Right Choice

The benchmark results will provide concrete data to inform the decision. If absolute maximum performance and minimal resource consumption are paramount, and a rewrite is feasible, Go is likely the superior choice. If leveraging an existing Laravel codebase, rapid development, and a vast ecosystem are priorities, Laravel Swoole offers a powerful and performant solution that can handle significant concurrency loads, often exceeding traditional PHP-FPM setups by orders of magnitude.

This comparison is not about declaring one definitively “better” than the other, but about understanding their respective strengths and weaknesses in a high-concurrency context. The optimal choice depends on project requirements, team expertise, and strategic goals.