Category: Hosting & Performance

Description: Insights into high-speed, reliable hosting built on OpenLiteSpeed, Ampere AArch64, and Oracle Cloud. Learn how to optimise WordPress and web applications for speed, scalability, and SEO success.

Preventing Unnecessary OpenLiteSpeed Reloads from .htaccess Touches

Preventing Unnecessary Open Lite Speed Reloads
  • Introduction

    In OpenLiteSpeed 1.8.x, the server does not automatically reload when .htaccess or configuration files change. For WordPress and PHP hosting environments, this means that changes to rewrite rules or caching directives in .htaccess files will not take effect until the server is manually reloaded or restarted.

    System administrators running multi-site setups, therefore, often add automation to detect when .htaccess files have changed and trigger a graceful reload. The challenge is that the usual methods can reload unnecessarily when a file’s timestamp changes but its content doesn’t; for example, during deployments, syncs, or backup restores. My improved script solves this problem.

    The Traditional Example from OpenLiteSpeed Forums

    A commonly suggested script looks a bit like this:

    #!/bin/bash
    #
    # If any .htaccess files change, reload the lsws server and show which ones changed
    #

    # Find .htaccess files newer than the lsws cgid binary
    changed_files=$(find /var/www/*/htdocs/ -maxdepth 2 -type f -name '.htaccess' -newer /usr/local/lsws/cgid)

    if [[ -n "$changed_files" ]]; then
        echo "The following .htaccess file(s) changed:"
        echo "$changed_files"
        /usr/bin/systemctl reload lsws
        echo "Reloaded lsws due to changes in .htaccess file(s)"
    fi

    This approach compares modification times (-newer /usr/local/lsws/cgid), so if a deployment tool or the site touches files without altering them, the script will reload OpenLiteSpeed needlessly.

    The Tekate Improvement for OpenLiteSpeed reload on .htaccess change

    To eliminate false reloads, Tekate’s version uses SHA-256 content hashing rather than timestamps. The server reloads only when an .htaccess file’s contents actually change.

    Key advantages:

    • Detects real content changes only
    • Avoids redundant reloads from file syncs or touches etc
    • Prevents overlapping cron runs with flock
    • Runs lightly under nice and ionice
    • Uses the standard /var/www/*/htdocs/ structure
    • Compatible with OpenLiteSpeed 1.8.x on Oracle Linux 9

    Here’s the improved script:

    #!/bin/bash
    # Reload OpenLiteSpeed only when .htaccess content actually changes.
    # Tested on OpenLiteSpeed 1.8.x (Oracle Linux 8).
    # Uses standard web root location /var/www/ for all sites.
    # Simple reporting: show only ADDED/MODIFIED entries (hash + path).

    set -euo pipefail

    # Prevent overlapping cron runs
    exec 9>/run/lock/htaccess-watch.lock || exit 0
    if ! flock -w 2 9; then
      logger -t htaccess-watch "Skipped: previous run still holding lock"
      exit 0
    fi

    HASH_FILE="/root/.htaccess_hashes"
    TMP_HASH="$(mktemp /tmp/.htaccess_hashes.XXXXXX)"
    trap 'rm -f "$TMP_HASH"' EXIT

    # Build new list of hashes; deterministic ordering
    LC_ALL=C nice -n 10 ionice -c3 \
      find /var/www/*/htdocs/ -maxdepth 2 -type f -name '.htaccess' -exec sha256sum {} \; 2>/dev/null \
      | LC_ALL=C sort > "$TMP_HASH"

    # First run: seed baseline and exit quietly
    if [[ ! -f "$HASH_FILE" ]]; then
      mv -f "$TMP_HASH" "$HASH_FILE"
      exit 0
    fi

    # If lists differ, reload and print out for email only new/modified lines
    if ! diff -q "$HASH_FILE" "$TMP_HASH" >/dev/null; then
      echo "The following .htaccess file(s) changed (added/modified):"
      if comm -13 "$HASH_FILE" "$TMP_HASH" | grep -q .; then
        comm -13 "$HASH_FILE" "$TMP_HASH"
      else
        echo "(no added/modified entries — change was deletions only)"
      fi

      /usr/bin/systemctl reload lsws
      echo "Reloaded lsws due to actual content changes in .htaccess file(s)"
      logger -t htaccess-watch "Reloaded lsws due to .htaccess content changes"

      mv -f "$TMP_HASH" "$HASH_FILE"
    fi

    Setting Up the Cron Job

    Add this to the root crontab to check for .htaccess changes every three minutes and email the admin only when reloads occur:

    */3 * * * * /root/scripts/serverReloadLsws | /usr/local/bin/maybe_mail "server: openlitespeed reloaded" webmaster@example.com

    In this cron entry, the maybe_mail script only emails to the specified email address if it is passed content through stdin.

    This ensures:
    – OpenLiteSpeed reloads automatically on real .htaccess content changes
    – SysAdmins get concise, actionable notifications
    – No redundant reloads or “spammy” alerts from unmodified files

    Why Tekate’s Version Is Preferable

    FeatureOld ExampleTekate Script
    Relies on file timestampsYesNo
    Detects real content changesNoYes
    Prevents overlapping runsNoYes
    Lightweight and deterministicBasicOptimised

    Conclusion

    OpenLiteSpeed 1.8.x doesn’t auto-reload when .htaccess changes. By introducing a hash-based check, my script keeps sites perfectly in sync with their configuration while minimising unnecessary reloads. It’s a small but elegant improvement that reinforces our philosophy of performance through precision, essential for modern high-performance WordPress environments.

    Now, I shouldn’t have to tell you this 🙂 This script is provided as “as-is.” Use it at your own risk. Test thoroughly in a staging environment before production deployment. It was tested on OpenLiteSpeed 1.8.x using systemd on Oracle Linux 9 (RHEL-based), modifications may be needed for other environments.

  • Website speed is no longer a luxury. For many businesses, it’s the difference between a customer staying or bouncing, between ranking on the first page of Google or being buried out of sight.

    Yet time and again, we meet companies running their sites on generic shared hosting, or Apache setups that were never designed for today’s web. The results are predictable: sluggish load times, erratic performance at peak traffic, and frustrated users.

    At Tekate, we wanted something different. We needed hosting that could support not only brochure websites, but also complex workflow applications, high-traffic e-commerce stores, and WordPress sites with heavy plugin usage. We also wanted to do it sustainably, without wasting unnecessary electricity on the problem.

    The answer was to build a hosting stack from the ground up — tuned for speed, resilience, and efficiency.


    Why Traditional Hosting Falls Short

    For most businesses, hosting is invisible until it goes wrong. But underneath the surface, there are real limitations:

    • Shared hosting bottlenecks – multiple customers fighting for the same resources.
    • Apache overhead – powerful but bloated, consuming CPU cycles on tasks that OpenLiteSpeed handles more efficiently.
    • x86 inefficiency – older architecture that burns through power for the same workload an Ampere Arm server can handle at half the energy cost.
    • One-size-fits-all databases – single-instance MySQL setups that become a single point of failure.

    These setups can work for small sites. But when performance and reliability really matter, they start to crumble.


    Building Something Better

    Instead of accepting those limits, we designed a stack optimised for the workloads we actually see. Here’s what that looks like:

    1. OpenLiteSpeed Web Server

    We chose OpenLiteSpeed (OLS) over Apache or Nginx because it gives us:

    • Event-driven architecture – able to handle thousands of concurrent connections with lower memory usage.
    • Built-in caching – page caching at the server level, faster than most WordPress plugins.
    • HTTP/3 & QUIC support – out of the box, improving performance on mobile and poor connections.

    For WordPress in particular, OLS consistently benchmarks faster than Apache.

    2. Ampere AArch64 Machines

    Most hosts still rely on x86 CPUs. We didn’t. We deploy on Ampere Altra (Arm-based) processors running in Oracle’s London data centre. Why?

    • More performance per pound – higher core counts at lower cost.
    • Energy efficiency – less electricity per request, a win for both costs and sustainability.
    • Scalability – each VM can be tuned with flexible vCPU and memory allocations.

    It means we can offer high performance without charging enterprise-level hosting fees.

    3. Oracle Linux + MySQL Replication

    Our servers run on Oracle Linux for stability and long-term support. For databases, we use high-availability MySQL and MariaDB, always with replication across nodes. That ensures:

    • Failover resilience – one server can take over if another fails.
    • Better read performance – queries spread across replicas.
    • Safety for business-critical data.

    4. Cloudflare DNS & CDN

    On top of the server stack, we run all sites through Cloudflare. That adds:

    • Edge caching for global speed.
    • DDoS protection and security filtering.
    • Smart DNS with low-latency routing.

    Together, these layers ensure that content loads quickly, regardless of whether your customer is in London, Sydney, or New York.


    Real-World Performance

    Benchmarks are one thing — but what matters is how sites behave in practice. On our platform, we’ve seen:

    • WordPress sites load in under one second, even with heavy page builders like Divi or Elementor.
    • 40% faster response times compared to equivalent Apache setups.
    • Reduced server load by 30–40% under traffic spikes thanks to OLS caching.
    • Greater uptime with monitoring and replication — even during maintenance windows.

    One client migrated from a well-known UK shared hosting provider where their WooCommerce store struggled to handle traffic. After moving to Tekate’s stack, the same site handled Christmas sales with ease, loading faster while running more transactions.


    Why Speed Isn’t Just About Technology

    It’s tempting to think of hosting purely in technical terms — cores, memory, benchmarks. But speed is really about business outcomes:

    • SEO impact – Google rewards fast sites in its ranking.
    • Conversion rates – studies show every extra second of delay can reduce conversions by 7%.
    • User trust – slow sites feel unreliable, and that perception matters.
    • Energy efficiency – running on efficient Ampere servers reduces both costs and carbon footprint.

    Fast hosting isn’t vanity. It’s a competitive advantage.


    Lessons Learned Along the Way

    Building this stack wasn’t about picking the newest tools. It was about asking: what actually matters for our clients?

    • WordPress needs server-level caching, not another plugin.
    • Workflow apps need resilient databases, not single points of failure.
    • Modern hosting needs efficiency, not brute force.

    We didn’t just want to host sites. We wanted to host them well — in a way that makes them faster, safer, and more future-proof.


    Looking Ahead

    The web will only get heavier — more scripts, more integrations, more demand for real-time features. That makes a fast, resilient hosting base more critical than ever.

    Our stack isn’t finished; it’s constantly evolving. We’re already testing:

    • Automated scaling for traffic spikes.
    • Edge AI integrations for image optimisation and personalisation.
    • Deeper observability tools to spot bottlenecks before users notice them.

    However, the principle remains the same: hosting should make applications faster, not hinder them.


    Final Reflection

    When we built our hosting stack, it wasn’t about chasing the latest trend. It was about solving the real-world frustrations we saw in our clients’ sites: slow load times, admin bottlenecks, and fragile databases.

    By combining OpenLiteSpeed, Ampere servers, Oracle Linux, MySQL replication, and Cloudflare, we created a platform that consistently delivers faster, more reliable WordPress and workflow applications.

    And in doing so, we proved a simple point: when hosting is done right, it becomes invisible. The only thing users notice is that everything just works — and it works fast.