mirror of
https://github.com/qdrant/landing_page.git
synced 2026-10-09 21:08:31 +02:00
docs(article): use measured benchmark numbers and Qdrant 1.18.2
Record the real re-run: parallel 1->4 workers was ~1.2x (5.58s->4.61s) on a local single node, not 2x. Add the confirmed server version (1.18.2) to both callouts.
This commit is contained in:
@@ -170,7 +170,7 @@ A better approach is to upload points in batches. Batching allows Qdrant to proc
|
||||
|
||||

|
||||
|
||||
> **Benchmark:** On a local single-node Qdrant (Windows 11, `qdrant-client` 1.12.0, ~10,000 synthetic 768-dim vectors), batching at 64 points per request was about 5× faster than uploading one point at a time. This is a small dataset chosen to show the pattern; the gap widens as datasets grow into the millions, and exact numbers depend on hardware and Qdrant version.
|
||||
> **Benchmark:** On a local single-node Qdrant 1.18.2 (Windows 11, `qdrant-client` 1.12.0, 10,000 synthetic 768-dim vectors), batching at 64 points per request was about 5× faster than uploading one point at a time. This is a small dataset chosen to show the pattern; the gap widens as datasets grow into the millions, and exact numbers depend on hardware and Qdrant version.
|
||||
|
||||
Set a batch size when uploading points:
|
||||
|
||||
@@ -196,7 +196,7 @@ Parallel uploads allow several workers to upload different parts of the dataset
|
||||
|
||||

|
||||
|
||||
> **Benchmark:** On the same local single-node setup (Windows 11, `qdrant-client` 1.12.0, ~10,000 synthetic 768-dim vectors, batch size 256), uploading with 4 parallel workers was about 2× faster than a single stream. As with batching, treat these as directional: gains grow with larger datasets and more capable hardware.
|
||||
> **Benchmark:** On the same local single-node setup (Qdrant 1.18.2, Windows 11, `qdrant-client` 1.12.0, 10,000 synthetic 768-dim vectors, batch size 256), going from 1 to 4 parallel workers cut upload time from 5.58s to 4.61s (~1.2× faster). On a single local node the gain is modest — the workers share the same CPU — and grows more meaningful against a remote or multi-node deployment with more shards.
|
||||
|
||||
Note: Parallelism gains are not always linear; in some configurations, 2 workers may perform similarly to 1 before improvements appear at higher counts.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user