Hello

I have a directorist with only about 130,000 entries and yet it is very slow to write to the database.
The databse is on a dedicated physical drive for the Maria SQL and the server is fairly new. Reading data is no problem but writing anything takes ages. It does not show any disk or CPU or RAM peaks at the time.

Is there anything I can do to improve speed rather than just ditching it for a new IIS site?

Would moving to another webserver improve things?

---

I remember how kind you have been to me, and I want to save you the massive headache of rebuilding your site from scratch.

To answer your main question immediately: Do not move to IIS. Moving a PHP/MySQL application (like WordPress/Directorist) to a Windows/IIS environment will almost certainly make performance worse, not better. PHP is native to Linux, and IIS adds significant overhead.

The "smoking gun" in your description is that you see no CPU, RAM, or Disk peaks while it is being slow.

This indicates your server isn't "working hard"-it is waiting.

Here is exactly what is likely happening and how to fix it.

The Problem: Transaction Safety vs. Speed

By default, MariaDB is configured to be 100% "ACID compliant." This means that for every single change (write) you make to the database, it forces the hard drive to physically spin, write the data, and confirm "I have saved this" before it lets WordPress move on to the next step.

When you are updating a directory with 130,000 entries, this introduces massive latency. Your powerful CPU is sitting idle for milliseconds at a time, thousands of times per second, waiting for the physical disk to say "okay."

The Solution: Change one MariaDB Setting

You need to change the innodb_flush_log_at_trx_commit setting.

• Current (Likely) Setting: 1 (Write to disk immediately after every transaction. Safest, but slowest.)


• New Setting: 2 (Write to OS cache immediately, flush to physical disk once per second.)

Why this fixes it:
This tells MariaDB to dump the data to the operating system's memory buffer and move on instantly. The OS will then lazily write that to the disk in the background. This typically speeds up write operations (like imports or mass updates) by 10x to 100x without adding any CPU load.

The Risk: If your server loses power completely (hard crash), you might lose the last 1 second of data. For a directory website, this is usually an acceptable trade-off for the massive speed gain.

How to apply the fix

1. Locate your config file: Usually found at /etc/mysql/my.cnf or /etc/my.cnf.d/server.cnf (depending on your Linux distribution).


2. Edit the file: Look for the [mysqld] section.


3. Add/Modify this line:

   innodb_flush_log_at_trx_commit = 2 
   

   
   


4. Restart MariaDB:
   systemctl restart mariadb

Other Checks for Directorist

If the above doesn't solve it completely, check these specific Directorist bottlenecks:

• Geocoding: If you have "Map" or "Geolocation" features enabled, Directorist might be trying to contact Google Maps API to fetch coordinates for every listing you save. This is a huge hidden delay. Check Directory Builder -> Settings -> Map Settings and try temporarily disabling geocoding to test speed.


• Image Optimization: If you are uploading images with listings, ensure you aren't using a plugin that compresses images on upload (like Smush or EWWW) during bulk operations. This halts the database write until the image CPU processing is done.

Summary

• Don't switch to IIS.


• Don't blame your CPU/RAM.


• Do change the MariaDB flush setting to 2.

This single configuration change often instantly solves the "slow write, idle CPU" mystery.

... Directorist Tutorial ...

I've selected this video because it provides a comprehensive overview of the Directorist plugin's capabilities and settings, which may help you identify if a specific feature (like map integration) is contributing to the write latency.

Would you like me to guide you on how to check if your server uses innodb_flush_log_at_trx_commit without restarting it first?

---

OK thanks but that soultion looks like it is for Maria running on Linux, this is on the same Windows Server as IIS

---

Since you are running MariaDB on Windows (IIS), the situation is actually much clearer. The "no CPU usage" symptom is the classic signature of Windows I/O locking.

Moving web servers (e.g., from IIS to Apache on Windows) will not help. The bottleneck is not the web server; it is how Windows handles database files on the hard drive.

Here are the three specific fixes for your Windows environment, ranked from "Most Likely" to "Most Powerful."

1. The "Silent Killer": Windows Defender (Antivirus)

This is the most common cause of slow writes with low CPU on Windows.
When MariaDB tries to write to its data files (.ibd files), Windows Defender intercepts the write to scan the file for viruses. It locks the file, scans it, and then releases it. This happens for every single transaction, causing your 130,000 entries to crawl, while the CPU sits idle waiting for the antivirus to finish.

The Fix:

1. Open Windows Security (Search for "Virus & threat protection").


2. Click Manage settings under "Virus & threat protection settings".


3. Scroll down to Exclusions and click "Add or remove exclusions".


4. Add a Folder exclusion for your MariaDB Data folder.
   
   
   • Default location is usually: C:\Program Files\MariaDB [Version]\data or C:\ProgramData\MariaDB\MariaDB [Version]\data.
   
   
   
   

2. The MariaDB Config (Windows Version)

The innodb_flush_log_at_trx_commit = 2 fix I mentioned is still the "magic bullet," but the file location is different on Windows.

How to find and edit it:

1. Open Services (Run services.msc).


2. Find the MariaDB service, right-click -> Properties.


3. Look at the "Path to executable". It will usually point to a file ending in .ini.
   
   
   • Note: If it points to ProgramData, that is a hidden folder. You may need to type C:\ProgramData into your address bar manually.
   
   
   
   


4. Open that my.ini file in Notepad (Run as Administrator).


5. Add this line under the [mysqld] section:

   innodb_flush_log_at_trx_commit = 2 
   

   
   


6. Restart the MariaDB service in the Services window.

3. The Physical Drive "Safety Brake"

Windows Server often defaults physical drives to "Quick Removal" mode, or ensures "Write Flushing" is on to prevent data loss. This forces the physical disk to confirm every write, bypassing your drive's fast RAM cache.

The Fix (Only do this if you have a UPS/Battery Backup):

1. Open Device Manager.


2. Expand Disk drives and find the physical drive where the database lives.


3. Right-click -> Properties -> Policies tab.


4. Ensure "Enable write caching on the device" is CHECKED.


5. (The Turbo Button) Check "Turn off Windows write-cache buffer flushing on the device".
   
   
   • Warning: This makes writes lightning fast because Windows lies to MariaDB and says "I saved it" while it's still in RAM. If the power cord is pulled, you will lose data. Only use this if the server is stable or during your bulk import.
   
   
   
   

Summary of Action Plan

1. Exclude MariaDB Data folder from Windows Defender. (Do this first, it's safe).


2. Edit my.ini to set flush log to 2.


3. Check Device Manager for Write Caching policies.

Would you like me to help you find the exact path to your my.ini file using a command line query?

---