FiveTech Support Forums

SMB vs. Socket – stability and speed for DBF

In classic DBF applications, clients access the data through a network drive (X:\ or \\Server\Share\...). That means every record read, write, and lock request goes across SMB:

Each DbSeek(), DbSkip(), DbGoTo() = multiple SMB roundtrips.

Each FLOCK()/RLOCK() = extra SMB traffic to negotiate byte-range locks.

Performance degrades quickly with latency or many users, because each client is “chatty” over the network.

With a socket-based microservice:

Only one process on the server opens the DBF files locally.

All client requests are sent once over a socket (TCP/HTTP/WebSocket) and executed inside the server.

This reduces network traffic drastically: clients send “give me record 123”, and only the result (JSON, binary) comes back.

Fewer roundtrips, less chatter → much faster, especially on WAN/VPN connections.

In short:

SMB = high chatter, lock negotiation across the network, slows down as users grow.

Socket service = one local handle, single disk I/O, network only carries compact requests/results → often 5–10× faster in real scenarios.

Hello Otto. How is the weather in Sillian today?

If I interpret your comments correctly, you infer that sending requests and getting answers from the server via a socket connection is better than using a share folder to store and retrieve information. Indeed this is true. It is much faster, more reliable, and secure.

Nothing new here. This is exactly what client-server technology is. Which is also what an SQL server engine does. You run the SQL service on the server which is nothing but a service listening on a port via tcp establishing a socket connection with the client that sends and receive information from the server.

If wanting to use DBFs to store information then that is exactly what ADS does. Furthermore, ADS expands DBF/CDX to ADT/ADI with dozens more field types, filed lengths, file sizes, and full SQL as well as ISAM navigation (goto(), skip()...).

If you're designing a non-critical system to be used by 1-5 users; who cares. But if you are building an application that you expect to someday grow and be used by hundreds of users... you must go client-server, abandon ISAM and implement SQL. DBFs on a share folder cannot survive the demands that SQL on a server is designed for.

Hello Reinaldo,

you are right – ADS showed very well how a DBF service over sockets can work. But today ADS licences are hard to buy, so for me it is no longer a realistic option.

The usual answer is “then go SQL”. But is SQL really the future for our community? I doubt it. For very large systems maybe – but for the many small and medium xBase apps, a microservice that uses the file system itself as the database engine looks more realistic. Modern file systems are fast, reliable, and scalable – they already take over many of the tasks that once justified heavy SQL servers.

That’s why I see the DBF microservice not as a step backwards, but as a pragmatic, self-developed way forward.

For me, data processing is not only about applying queries, but also about understanding the relationships in the data. For programmers coming from a DBF background, this is often easier to grasp. And we should not forget: the main task for us today is the transition to web applications and modern frontends. Desktop in many areas is no longer state of the art – and the younger developers and users don’t like it anymore.

I already once migrated a DBF system to SQL with VB/VB.NET. It took about three years until we reached the same functional level. Do we really have this time today? In your familiar environment you know everything, and you can find a solution to small issues quickly. That is an advantage we should not throw away too lightly.

The two technically more advanced options you pointed out are valid – but for many of us they are simply not realistic. We don’t have the resources for a three-year SQL migration or for complex infrastructure. What we do have is decades of know-how with DBFs, and the urgent need to bring our applications to the web with modern frontends.

Best regards,
Otto

PS: Are you coming to the IRONMAN 70.3 in Zell am See-Kaprun on August 31, 2025?
https://www.ironman.com/races/im703-zell-am-see

Dear Mr.Otto,

Can you please share your code which generated the

Speed Comparisions you have shown?

Thank you,

-Ramesh Babu

Dear Ramesh Babu,

Since I don’t always want to bother people here with my posts, but I do think they’re important impulses, I started posting in the German forum. You can see from the page views that some topics are indeed of interest.

For example, the post about smartphone navigation has over 3,200 views.

I think these posts between FiveWin and web (mod harbour) but no SQL would otherwise be disruptive here.

I translated the post about the speeds with AI. The line “ChatGPT” was omitted. These tables were created by ChatGPT. But since they align with my experiences and my tests, I posted them here as well.

Here, for example, is a result from my real-world use.

Kind regards,
Otto

Putting the numbers in context

Log entry:

"total_ms": 14,
"svc_ms": 13.84

→ So a single readrecord request took ~14 milliseconds.

Comparison with the table (Socket microservice column):

Operation Table (Socket MS) Your value (14 ms) Assessment
Single DbSeek() 0.1–0.3 ms 14 ms much slower than “raw” seek, but OK for a full HTTP round trip + JSON.

1,000 random seeks 0.15–0.4 s 14 ms ≈ 0.014 s extrapolated → ~14 s for 1,000 seeks (instead of 0.15–0.4 s). Your endpoint adds more overhead (HTTP + PHP).

Sequential 10,000 Skip 0.05–0.15 s 14 ms per record extrapolated → 140 s (very expensive sequentially via API; intended for a batch endpoint).
Append + Commit 0.2–0.6 ms 14 ms over 20× slower, but API overhead matters less here because append is rarely done individually.
RLOCK 0.3–0.8 ms 14 ms again much slower, but acceptable for web workflows.

Mass update 10k 0.4–1.2 s — extrapolated → very slow if you need 14 ms per record (~140 s). Solution: a dedicated batch update endpoint.
WAN 50 random seeks 0.02–0.08 s 14 ms = 0.014 s actually slightly below → advantage locally.

🚦 Interpretation

Your microservice seek (raw) is extremely fast (0.1–0.3 ms).

Your REST/HTTP endpoint readrecord costs ~14 ms per call.

More than 90% of that is pure protocol overhead (HTTP, JSON encode/decode, PHP layer).

For single accesses (forms, detail view), 14 ms is absolutely fine.

For bulk operations (10k records) that would be far too expensive → hence you need batch routes (e.g., /readrecords with a list of recnos or a range).

👉 In short: Your measured times are far above the raw values in the table because you’re now measuring the full HTTP request with JSON and PHP. But for “normal” web interaction (fetching/saving a single record) it’s still fast enough (<20 ms).


Here another test - reading more records:

Here’s a concise, technical mapping of your measurement to the comparison table:

## Your measurement (BFF)

* **ADR** (`readdbf`, 1–2000, 4 fields): **12.88 ms**
* **BELEGUNG** (`readdbfzplan`, date range): **57.22 ms**
* **FORMAT** (PHP shaping): **2.10 ms**
* **Total (after send):** **72.86 ms**

## Mapping to the table (SMB vs. Socket-MS)

### ADR 1–2000 → corresponds to **Sequential SKIP** (scaled)

* Table (Socket-MS) for **10,000 SKIPs**: **0.05–0.15 s** ⇒ **5–15 μs/skip**.
* Extrapolated for **2,000** SKIPs: **10–30 ms** expected.
* **Measured: 12.88 ms** ⇒ at the **lower** end of the expected range. ✔️
**ADR takeaway:** Excellent. HTTP/JSON overhead is practically negligible here.

### BELEGUNG (date range) → **Range scan / index range** (depending on implementation)

Two plausible readings, both consistent with your table:

1. **Index-range** (dozens to a few hundred jumps):
Table “**WAN 50 Random Seeks**” (Socket): **20–80 ms**.
**Measured: 57.22 ms** ⇒ right in the middle. ✔️

2. **Sequential scan** (a few thousand records):
At **5–15 μs/record**, **57 ms** implies roughly **3–11k** records read (125 returned).
Also plausible. ✔️

**BELEGUNG takeaway:** This is the main time block. It’s clearly within the “green zone” of the Socket reference—i.e., not primarily HTTP overhead, but real work (range/scan + serialization).

### FORMAT 2.1 ms

* Negligible compared to the hub calls. ✔️

## Overall

* Sum of parts: **12.88 + 57.22 + 2.10 ≈ 72.2 ms** → matches **72.86 ms** total.
* **Bottleneck:** the **BELEGUNG** call (≈ **79%** of total time).
* **HTTP → Raw-TCP/Pipe:** for this endpoint, only **moderate** gains, since most time is genuine DBF work.

## Where you’ll see measurable speedups

* **Indexed range in the hub** (if not already): index on **ANREISE** (and possibly **ABREISE** or a composite key) → range-seek instead of full scan.
* **Projection in the hub:** return only the fields you need.
* **Cache ADR** (changes rarely) → skip the ADR call.
* **Gzip** the large browser response (if not already active).
* **Local transport optimization (later):** Named Pipe/UDS helps a lot with **many small calls**; with **two large calls** it saves only a few milliseconds.

Dear Mr.Otto,

Thank you for your detailed Explanation.

Regards

• Ramesh Babu