यह तकनीकी दस्तावेज़ अंग्रेज़ी में उपलब्ध है।
Planning reference: volumes and infrastructure figures in this document are hypothetical sizing scenarios, not measured product capacity or deployed installations. Validate workload, costs, security and recognition performance before procurement. The current feature overview is available at /features.
These are reference figures for the primary site of a deployment with 4 billion fingerprint templates, 4 billion face records and 4 million cameras. The recovery site is normally the same size for the database and files, and at least half the size for matching and ingest.
All figures are engineering estimates from measured component performance (see the table at the end). They are confirmed or adjusted by the acceptance benchmark on the delivered hardware.
Reference server list (primary site)
| Tier | Servers | CPU | RAM | Storage | Network |
|---|---|---|---|---|---|
| Load balancers (HAProxy + keepalived) | 2 (+2 per 1M cameras) | 16 cores | 64 GB | 2 × 480 GB SSD (RAID 1) | 2 × 25 GbE |
| Camera VPN concentrators | 4+ | 16 cores, AES-NI | 64 GB | 2 × 480 GB SSD | 2 × 25 GbE |
| API / web servers | 8 to 16 | 32 cores | 128 GB | 2 × 960 GB SSD | 2 × 25 GbE |
| Ingest servers | ~60 at peak (start with ~20) | 32 cores | 128 GB | 2 × 960 GB SSD | 2 × 25 GbE |
| Fingerprint shortlist index | 10 (2 matcher shards each) | 64 cores | 512 GB | 2 × 3.84 TB NVMe | 2 × 25 GbE |
| Native matchers (2 copies × 20 shards) | 40 | 64 cores (AVX2 / AVX-512) | 512 GB | 2 × 960 GB SSD | 2 × 25 GbE |
| Face vector index | 8 (4 shards × 2) | 64 cores | 256 GB | 2 × 3.84 TB NVMe | 2 × 25 GbE |
| Database servers (MongoDB shard members, or Oracle RAC nodes) | 72 (24 shards × 3) | 32 cores | 256 GB | 8 × 7.68 TB NVMe (RAID 10) | 2 × 25 GbE |
| MongoDB config servers (MongoDB only) | 3 | 16 cores | 64 GB | 2 × 960 GB SSD | 2 × 25 GbE |
| Central storage: NAS (NFS) or object storage | 8+ | 32 cores | 128 GB | 24 × 20 TB HDD + NVMe cache | 2 × 25 GbE |
| Management (bastion, monitoring, logs, backup, keys) | 6 | 16 cores | 64 GB | as needed | separate network |
Start smaller and grow: every tier is added to by adding servers, without stopping the service.
The server calculator on the Scale page now supports a planning range from 1 million to 10 billion people. At ten fingers per person this derives up to 100 billion fingerprint templates, with a separate face-record assumption of one per person. Its outputs are indicative projections, not benchmarked capacity. The 4-billion-record tables below remain a separate reference workload. The software writes the settings of every one of these servers from one description of the installation, and checks at start that each server matches the stored layout.
How the numbers are worked out
Fingerprint matching
- Memory: 4,000,000,000 templates × ~1.7 KB ≈ 6.8 TB for one copy. Each 512 GB matcher holds ~340 GB of templates (the rest is the operating system and room to grow), so one copy needs 20 servers. A second copy, so a failed server does not stop searches, makes 40.
- Speed: one search runs on one copy: 20 servers × 64 cores × ~150,000 comparisons per second per core ≈ 192 million comparisons a second. The other copy serves other searches at the same time.
| Search | Templates compared | Time (100,000–200,000 comparisons/s per core) |
|---|---|---|
| Full search: finger position unknown | 4,000,000,000 | ~21 s (16–32 s) |
| Finger position known (scanners) | ~400,000,000 | ~2.4 s (1.9–3.4 s) |
| Shortlist index, then exact scoring | ~1 s target; a full search follows whenever the shortlist finds nothing |
Times include ~0.3 s to read the print and merge the results of every server.
- Searches a day: each copy handles one search at a time, so both copies together do about 72,000 finger-known or 8,000 full searches a day. More searches, or faster ones, need more matchers: twice the matchers halves the time.
Other sizes
| Fingerprints | Matchers (2 copies) | Full search | Finger known |
|---|---|---|---|
| 40 million | 2 | ~4.5 s | ~0.7 s |
| 500 million | 6 | ~18 s | ~2 s |
| 1 billion | 10 | ~21 s | ~2.4 s |
| 4 billion | 40 | ~21 s | ~2.4 s |
| 6 billion | 60 | ~21 s | ~2.4 s |
With the fewest servers, the search time levels off at about 20 seconds: memory, not speed, decides the number of matchers, and each one scans about 340 GB of templates. Choose more matchers for faster searches.
Faces
- Each face takes about 180 bytes in memory (its 128 numbers as one byte each, plus its ids): 1 billion faces ≈ 180 GB, so one 256 GB server holds a billion. 4 billion faces: 4 shards × 2 copies = 8 servers.
- The search is exact. Measured at 10.3 million faces per second per thread: about 1.5 s per search for a billion faces on 64 cores. Three times the face shards (24 servers) bring it to about 0.5 s.
Camera reads
- 4,000,000 cameras × 2,000 reads a day = 8,000,000,000 reads a day ≈ 92,600 a second on average, about 280,000 a second at peak.
- At roughly 5,000 reads a second per ingest server (plate already read by the camera, watch-list in memory), the peak needs ~56 servers; 60 are listed.
- Sighting records at
600 bytes: ~4.8 TB a day before compression. Keep 30 days hot (50 TB compressed across the shards) and archive older reads.
Camera links
- ~2,000 reads × ~10 KB crop ≈ 20 MB a day ≈ 0.6 GB a month per site; full images only for hits.
Measured component performance
| Measurement | Value |
|---|---|
| Reference matcher (pilots only) | ~650 to 1,700 comparisons per second per core (measured) |
| Native C++ matcher | ~100,000 to 200,000 comparisons per second per core: more than 10 million templates in under 1 second on a 64-core server (benchmarked during the project) |
| Template size in memory | ~1.7 KB (measured; ~420 bytes stored as ISO/IEC 19794-2) |
| Fingerprint extraction from an image | ~0.3 s on one core (measured) |
| Face detection and descriptor | ~1 s per photo on CPU (measured); browsers and cameras can compute descriptors themselves |
| Face search | 10.3 million faces per second per thread, exact (measured) |
| Fingerprint shortlist | 5.9 ms per search on 800 synthetic prints on one thread; the right person first in the median, in the top 1% 98% of the time (measured; real scans are harder) |
The national figures above assume the native matcher. The reference matcher is about 100 times slower per core and is only suitable for pilots and small galleries.