Pano Server nhận ảnh từ nhiều máy cùng lúc: hàng đợi và lưu nền

Giải thích cách Server nhận ảnh xong trả lời client ngay, lưu file và cơ sở dữ liệu chạy hậu trường — phù hợp fleet tới 300 máy, kèm server.env và dấu hiệu quá tải.

Pano Server nhận ảnh từ nhiều máy cùng lúc như thế nào

Khi vài chục đến vài trăm máy nhân viên cùng gửi ảnh màn hình về Pano Server, nếu Server phải lưu xong từng ảnh rồi mới trả lời thì máy client sẽ chờ lâu, dễ lỗi kết nối và gallery trên Admin cập nhật chậm.

Pano Server xử lý theo cách khác: nhận ảnh xong báo “đã nhận” ngay, còn việc lưu file ảnh và ghi vào cơ sở dữ liệu chạy ở hậu trường qua một hàng đợi — máy gửi không phải đứng chờ.

Bài viết giải thích luồng này cho người cài đặt và vận hành Server, không lặp lại phần chọn gói license hay giám sát nhân viên.

Ba bước từ máy client tới gallery trên Admin

Bước 1: Máy client gửi ảnh định kỳ

Pano Client trên từng máy Windows, vài giây một lần, gửi lên Server địa chỉ dạng http://máy-chủ:8010/api/agent/data (cấu hình trong agent.env).

Mỗi lần gửi kèm:

• Tên hoặc mã máy
• Ảnh chụp màn hình (đã nén JPEG)
• Ứng dụng đang mở, tab trình duyệt, máy online hay offline
• Cảnh báo USB hoặc mạng (nếu bật trong cấu hình)

Với khoảng 100 máy, chu kỳ 5–10 giây, Server có thể nhận 10–20 gói tin mỗi giây vào giờ cao điểm — đặc biệt khi nhiều máy cùng gửi gần một thời điểm.

Bước 2: Server kiểm tra và xếp vào hàng đợi

Server kiểm tra token hợp lệ, license còn hạn, kích thước ảnh không vượt giới hạn (mặc định khoảng 6 MB mỗi lần gửi).

Ở chế độ mặc định (phù hợp fleet lớn), Server không lưu ngay mà đưa gói tin vào hàng đợi chờ xử lý, rồi trả lời máy client ngay — client tiếp tục chu kỳ chụp tiếp theo.

Bước 3: Luồng nền lưu ảnh và cập nhật Admin

Một hoặc vài luồng chạy nền trên Server lấy từng mục trong hàng đợi và:

1. Lưu file JPEG vào thư mục ảnh trên ổ đĩa Server (theo từng máy và thời gian) 2. Ghi thông tin máy, thời gian online, danh mục ảnh vào cơ sở dữ liệu trên Server 3. Cập nhật thêm lịch sử trình duyệt, log cảnh báo nếu có trong gói tin đó

Khi mở gallery trên Admin, Server đọc từ cơ sở dữ liệu — không phải mở từng file ảnh thủ công mỗi lần refresh.

Hai chế độ nhận dữ liệu trên Server

Chế độ hàng đợi — mặc định, dùng khi nhiều máy

Trong file server.env, tham số INGEST_MODE đặt là async (bất đồng bộ).

Nghĩa đơn giản:

• Máy client gửi xong là được trả lời, không chờ lưu file
• Server có vài luồng nền (thường 4–8, tùy CPU) cùng lưu ảnh song song
• Hàng đợi chứa tối đa khoảng 15.000 gói tin chờ; nếu đầy cần kiểm tra ổ đĩa hoặc nâng cấp phần cứng

Phù hợp từ vài chục máy trở lên, đặc biệt gói Business tới 300 máy.

Chế độ lưu ngay — chỉ nên dùng khi pilot ít máy

INGEST_MODE=sync: Server lưu ảnh xong trong cùng lúc nhận, rồi mới trả lời client.

• Tiện khi thử 3–5 máy, dễ tìm lỗi “gallery không có ảnh”
• Không nên dùng khi nhiều máy cùng gửi — Server chậm, client hay báo lỗi timeout

Các dòng thường gặp trong server.env

File server.env nằm trên máy cài Pano Server. Người triển khai có thể chỉnh:

• INGEST_MODE — async (hàng đợi, khuyến nghị) hoặc sync (lưu ngay)
• INGEST_WORKERS — số luồng nền lưu ảnh (mặc định Server tự chọn theo CPU)
• INGESTQUEUEMAX — độ dài tối đa hàng đợi (mặc định 15000)

Gói Enterprise thường đã cấu hình async sẵn. Trial 10 máy thường không cần sửa gì.

Triển khai lớn có thể thêm Redis làm hàng đợi chung — chỉ cần khi công ty có đội kỹ thuật và kiến trúc nhiều máy chủ; đa số SMB một Server Windows là đủ.

Vì sao gallery mở nhanh khi có hàng ngàn ảnh

Cơ sở dữ liệu trên Server lưu chỉ mục ảnh: máy nào, lúc nào, file nằm ở đâu trên ổ. Admin lật trang gallery thứ 2, 3… Server tra chỉ mục thay vì liệt kê cả thư mục ảnh mỗi lần.

Sau khi restore backup hoặc nâng cấp phiên bản, Server có thể đồng bộ lại chỉ mục với file ảnh còn trên ổ. Chi tiết: Backup và retention dữ liệu trên Pano Server.

Dấu hiệu Server đang quá tải

Trong màn hình kiểm tra sức khỏe Server (chỉ mở trong mạng nội bộ), chú ý:

• Số gói tin đang chờ trong hàng đợi (queue_depth) tăng cao, gần giới hạn
• Gallery trên Admin cập nhật chậm dù máy client vẫn online
• Ổ đĩa Server gần đầy hoặc antivirus quét từng file ảnh mới lưu

Cách xử lý thường gặp: giải phóng dung lượng ổ, chuyển sang SSD, tăng INGEST_WORKERS trong server.env, hoặc nâng RAM/CPU máy Server.

Từ chụp màn hình tới ảnh trên Admin

Trên Windows, agent chụp màn hình bằng thư viện mss — hạn chế nháy chuột so với cách chụp cũ. Máy nhiều màn hình: ghép thành một ảnh trước khi nén và gửi.

Quy trình đầy đủ:

1. Agent chụp và nén JPEG 2. Gửi lên Server 3. Server xếp hàng đợi, luồng nền lưu file 4. Admin hiển thị trong gallery

Chi tiết chụp ảnh: Cơ chế chụp ảnh màn hình định kỳ trên Pano Agent.

So với phần mềm cloud

Phần mềm giám sát cloud thường đẩy ảnh lên kho lưu trữ của nhà cung cấp. Pano self-hosted gom nhận ảnh + lưu file + cơ sở dữ liệu trên một máy Server trong công ty — không trả phí upload ra internet, dữ liệu không rời mạng nội bộ; bạn tự chọn cấu hình RAM và ổ cho quy mô fleet.

Gợi ý cấu hình máy Server

• 10–30 máy — chế độ hàng đợi mặc định; 4 GB RAM, SSD từ 256 GB
• 50–100 máy — 8 GB RAM, SSD 512 GB–1 TB
• 100–300 máy — 16 GB RAM, ổ NVMe/SSD 1 TB trở lên; theo dõi hàng đợi sau pilot một tuần

Ước lượng dung lượng ổ theo số máy và số ngày lưu ảnh: Backup và retention.

Câu hỏi thường gặp

Gallery trống nhưng máy client vẫn báo gửi được

Kiểm tra chế độ INGEST_MODE, luồng nền Server còn chạy không, ổ đĩa còn trống, quyền ghi thư mục ảnh. Thử đặt sync tạm khi pilot 1 máy để loại trừ lỗi hàng đợi.

Có cần Redis khi chỉ 50 máy không

Không. Một Server Windows với hàng đợi nội bộ thường đủ.

Máy client hay báo lỗi khi gửi ảnh

Thường do Server đang ở chế độ lưu ngay (sync) trong khi nhiều máy gửi cùng lúc, firewall chặn, hoặc ảnh gửi quá lớn. Chuyển sang async và kiểm tra mạng LAN.

Trial có dùng cơ chế hàng đợi không

Có — cùng cách vận hành với bản trả phí; chỉ giới hạn 10 máy và 7 ngày dùng thử.

Bước tiếp theo

• Tổng quan PANO: Pano là gì — self-hosted Windows
• Scale nhiều máy: Self-hosted 300 máy trên Pano Server
• Cấu hình client: agent.env — địa chỉ Server và token
• Tải Trial: panosoftware.com/trial