[ Python và ứng dụng ] Chia sẻ kỹ thuật xây dựng chương trình tra cứu siêu tốc độ (5 người xem)

[befaint]

[ Python và ứng dụng ] Chia sẻ kỹ thuật xây dựng chương trình tra cứu siêu tốc độ​

** Lời tựa:
- Chạy KPI kéo traffic cho web diễn đàn lên nhé.
- Tạo động lực cho những ai đang ấp ủ, đang thực hiện xây dựng các công cụ tự động hóa.
Một chương trình đang chạy chậm chưa chắc do máy tính yếu, đôi khi chỉ cần thay đổi cách tổ chức và phương hướng xử lý, hiệu quả có thể khác biệt rất lớn.

** Kết quả thử nghiệm thực tế:
- Chương trình tôi xây dựng hoàn thành 1.000 mã trong khoảng 33 giây.
- Tốc độ xử lý đạt trung bình hơn 30 mã mỗi giây.
Đây là thời gian của toàn bộ quá trình chương trình chạy, bao gồm gửi yêu cầu, nhận diện CAPTCHA, lấy dữ liệu, phân tích kết quả và tổng hợp thông tin.

1. Nhận diện CAPTCHA bằng API và mô hình đã huấn luyện​

Một trong những bước ảnh hưởng nhiều đến tốc độ tra cứu là xử lý CAPTCHA.
Chương trình sử dụng API kết hợp với mô hình nhận diện đã được huấn luyện để:

• Nhận ảnh CAPTCHA từ hệ thống.
• Tiền xử lý hình ảnh.
• Đưa ảnh vào mô hình nhận diện.
• Trả về kết quả dự đoán.
• Tự động kiểm tra và thực hiện lại khi kết quả không chính xác.

Điểm quan trọng không chỉ nằm ở độ chính xác của mô hình mà còn ở thời gian phản hồi. Một mô hình nhận diện tốt nhưng xử lý quá lâu vẫn có thể trở thành “nút thắt cổ chai” của toàn bộ chương trình.
Vì vậy, quá trình xây dựng cần cân bằng giữa ba yếu tố:
Độ chính xác – tốc độ – khả năng xử lý đồng thời.

2. Không xử lý tuần tự từng mã​

Nếu chương trình thực hiện theo cách truyền thống:

Gửi mã thứ nhất → chờ kết quả → xử lý xong → chuyển sang mã thứ hai

thì phần lớn thời gian CPU sẽ bị lãng phí trong lúc chờ phản hồi từ máy chủ.
Phương hướng tôi áp dụng là tổ chức quá trình tra cứu thành nhiều luồng công việc có kiểm soát. Trong khi một yêu cầu đang chờ phản hồi, chương trình có thể tiếp tục chuẩn bị hoặc gửi các yêu cầu khác.
Tuy nhiên, xử lý đồng thời không có nghĩa là gửi yêu cầu càng nhiều càng tốt. Nếu số lượng yêu cầu vượt quá khả năng của máy hoặc máy chủ đích, tốc độ có thể giảm, phát sinh lỗi hoặc bị giới hạn truy cập.
Do đó, cần xác định mức đồng thời phù hợp thông qua thử nghiệm thực tế.

3. Xây dựng quy trình xử lý dạng pipeline​

Thay vì gom tất cả công việc vào một bước, chương trình được chia thành các giai đoạn riêng biệt:
Đọc danh sách mã → tạo phiên làm việc → lấy CAPTCHA → nhận diện CAPTCHA → gửi yêu cầu tra cứu → phân tích dữ liệu → lưu kết quả.
Các công đoạn hoạt động liên tục như một dây chuyền. Khi một nhóm dữ liệu đang được gửi đi, nhóm tiếp theo đã được chuẩn bị; khi một nhóm đang chờ phản hồi, nhóm trước đó có thể được phân tích và lưu kết quả.
Cách tổ chức này giúp giảm đáng kể thời gian chờ giữa các bước.

4. Tái sử dụng kết nối và phiên làm việc​

• Dùng connection pool.
• Hạn chế tạo lại các đối tượng không cần thiết.
• Chủ động làm mới phiên khi hết hạn.

Đây là một trong những yếu tố giúp giảm thời gian cho mỗi yêu cầu, đặc biệt khi xử lý hàng nghìn mã.

5. Tối ưu khâu phân tích và lưu dữ liệu​

Không phải lúc nào phần gửi yêu cầu cũng là công đoạn chậm nhất. Với dữ liệu lớn, việc phân tích nội dung trả về và ghi kết quả xuống file cũng có thể làm giảm tốc độ toàn hệ thống.
Một số hướng xử lý tôi áp dụng gồm:

• Chỉ phân tích những trường dữ liệu thực sự cần thiết.
• Tránh xử lý lặp lại cùng một nội dung.
• Hạn chế thao tác đọc, ghi file liên tục.
• Gom kết quả thành từng nhóm rồi mới ghi.
• Loại bỏ mã trùng trước khi tra cứu.
• Chuẩn hóa dữ liệu ngay trong quá trình xử lý.
• Tách tác vụ lấy dữ liệu và tác vụ lưu dữ liệu.

Nhờ đó, chương trình không bị chậm lại khi số lượng kết quả tăng lên.

6. Xử lý lỗi mà không làm dừng toàn bộ chương trình​

Khi xử lý số lượng lớn, chắc chắn sẽ có một số yêu cầu gặp lỗi như:

• CAPTCHA nhận diện sai.
• Phiên làm việc hết hạn.
• Máy chủ phản hồi chậm.
• Kết nối bị gián đoạn.
• Dữ liệu trả về không đúng cấu trúc.
• Mã tra cứu không tồn tại.

Thay vì để một lỗi làm dừng toàn bộ quá trình, chương trình cần có cơ chế:

• Tự động thử lại với số lần giới hạn.
• Phân loại lỗi để có phương án xử lý phù hợp.
• Làm mới CAPTCHA hoặc phiên làm việc khi cần.
• Ghi riêng danh sách mã lỗi.
• Tiếp tục xử lý các mã còn lại.
• Cho phép chạy lại những mã chưa thành công.

Điều quan trọng là phải phân biệt giữa lỗi tạm thời và lỗi dữ liệu. Không nên thử lại vô hạn vì vừa làm chậm chương trình, vừa tạo thêm tải không cần thiết.

7. Đo lường trước khi tối ưu​

Tốc độ 1.000 mã trong 33 giây không đến từ một kỹ thuật duy nhất. Đây là kết quả của việc đo thời gian từng công đoạn và tối ưu lần lượt.
Tôi theo dõi các thông số như:

• Thời gian lấy CAPTCHA.
• Thời gian nhận diện CAPTCHA.
• Thời gian máy chủ phản hồi.
• Thời gian phân tích dữ liệu.
• Thời gian ghi kết quả.
• Tỷ lệ CAPTCHA sai.
• Tỷ lệ yêu cầu phải thử lại.
• Số lượng yêu cầu xử lý thành công mỗi giây.

Khi có số liệu cụ thể, chúng ta mới biết chính xác chương trình đang chậm ở đâu. Tối ưu theo cảm giác đôi khi làm code phức tạp hơn nhưng tốc độ gần như không thay đổi.

8. Tốc độ phải đi cùng sự ổn định và trách nhiệm​

Một chương trình nhanh nhưng thường xuyên trả về dữ liệu sai thì không có nhiều giá trị. Vì vậy, ngoài tốc độ, tôi ưu tiên:

• Kết quả phải chính xác.
• Không mất dữ liệu khi chương trình bị gián đoạn.
• Có thể tiếp tục từ vị trí đang xử lý.
• Có nhật ký để kiểm tra khi xảy ra lỗi.
• Giới hạn số lượng yêu cầu phù hợp.

Lời kết​

Tôi chia sẻ bài viết này với mục đích chia sẻ về tư duy kỹ thuật, kiến trúc xử lý và phương hướng tối ưu hiệu năng, không cung cấp mã nguồn.

Chúc các bạn thành công nhé!