Thời lượng phiên IoT


7

Một hộp Linux gửi các phép đo đến AWS-RDBMS. Một tập lệnh python mở và đóng kết nối chỉ đủ lâu để tải dữ liệu lên cơ sở dữ liệu (các phiên được đóng ngay sau khi cập nhật). Cách khác là hộp mở ra một phiên không xác định cho cơ sở dữ liệu và cập nhật RDBMS: không chắc vấn đề gì sẽ xảy ra với kết nối internet này và không chắc chắn về mức độ 'kiên trì' của kết nối khi gặp kết nối internet không ổn định. Ở quy mô, có thể có hàng trăm hộp đo lường tải dữ liệu lên RDBMS.

Thực tiễn tốt nhất liên quan đến thời lượng kết nối phiên IoT python là gì? Có phải là cách tốt nhất để đóng phiên sau khi truyền dữ liệu? Có thể xác định thời gian nhàn rỗi bắt đầu sau khi dữ liệu được truyền: nếu thời gian nhàn rỗi đạt nhiều hơn một lượng thời gian được xác định trước thì hãy đóng kênh. Tiền thưởng cho bất kỳ lời giải thích về lý do tại sao đằng sau thực tiễn tốt nhất.

Có lẽ câu hỏi này phụ thuộc vào nền tảng? tức là RDBMS vs AWS Greengrass?


2
Nó có thể giúp bạn có được câu trả lời cụ thể hơn nếu bạn giải thích chính xác những gì bạn đang tìm kiếm khi bạn nói những thực tiễn tốt nhất - không phải lúc nào cũng rõ ràng 'thực tiễn tốt nhất' thực sự có nghĩa là gì. Bạn có lo ngại cụ thể về thiết lập của mình không (ví dụ: "điều này có hoạt động tốt không?") Mà bạn có thể chỉnh sửa để đưa vào?
Aurora0001

Với loại câu hỏi này, nó luôn giúp đưa ra một chút bối cảnh xung quanh lý do tại sao bạn đặt câu hỏi. Khi nó đứng, nó khá ngoài ngữ cảnh (và trên bất kỳ ngăn xếp nào khác có thể trông giống như một câu hỏi bài tập về nhà - mặc dù tôi không cho rằng nó thực sự là lần này)
Sean Houlihane

Tôi đánh giá cao các ý kiến ​​để thêm chi tiết / bối cảnh: bất kỳ "câu hỏi" nào dưới dạng câu hỏi cụ thể sẽ được đánh giá cao và sẽ đẩy nhanh việc định hình câu hỏi.
gatorback

Tôi đang bỏ phiếu để đóng câu hỏi này ngoài chủ đề vì đây chỉ là một câu hỏi mã hóa ổ cắm chung khác, với hai lựa chọn thay thế được giải thích rõ trên hàng trăm, nếu không phải hàng ngàn trang web, bao gồm nhiều câu trả lời trên SO
Mawg nói rằng phục hồi lại

Câu trả lời:


2

Các biến mà IoT mang đến cho bữa tiệc ở đây, ở mức tối thiểu, quy mô và năng lượng. Bạn cũng có thể coi bảo mật / khả năng phục hồi là chịu các ràng buộc khác nhau so với cách câu hỏi này có thể đã được trả lời 5 năm trước. Các 'root' câu hỏi về SO là đã 7 tuổi và không rất phổ biến.

Tần suất giao dịch và chi phí thiết lập kết nối được xác thực có lẽ là trình điều khiển chính, cả về băng thông dữ liệu và chi phí năng lượng.

Có một chi phí để mở kết nối? Bạn sẽ cần bao nhiêu nỗ lực để quản lý một kết nối 'chủ yếu là bền bỉ' so với 'đóng-sử dụng mở' tầm thường hơn? Cách tiếp cận nào sẽ dẫn đến tranh chấp tài nguyên nhanh nhất (giả sử sản phẩm của bạn được lên kế hoạch mở rộng quy mô)?

Bạn có khả năng di chuyển mã / giao thức của mình hơn nữa đến rìa của mạng (hoặc di chuyển chức năng đám mây gần hơn với cạnh) trong tương lai không? Những di chuyển tiềm năng này có thể thay đổi các ràng buộc của bạn hoặc bạn có thể muốn trì hoãn đầu tư phần mềm tiềm năng.


1

Mặc dù bạn đang sử dụng phiên cho IOT, nhưng đây * không phải là câu hỏi IOT, chỉ là câu hỏi về ổ cắm chung và, như vậy, có rất nhiều, rất nhiều câu trả lời trên Google và trên Stack Overflow .

Về cơ bản, không có câu trả lời "đúng", bạn chỉ cần xem xét tình huống của mình.

Nói chung, việc triển khai "đóng sau mỗi giao dịch" sẽ dễ dàng hơn, vì bạn không cần nhiều "ooops, phiên hiện đang mở của tôi chỉ đóng mã bất ngờ". Đó là cách tiếp cận mà tôi luôn thực hiện, và đã thấy thường được sử dụng nhất trong công nghiệp.

Tuy nhiên, nếu bạn cần gửi các gói thường xuyên (kích thước không quan trọng, chỉ là tần số), thì chi phí đóng và mở lại sau mỗi gói có thể dẫn đến các vấn đề về hiệu suất.

Bạn trả tiền, bạn chọn :-)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.