Lorawan-stack: Optimalkan pencocokan perangkat

Dibuat pada 5 Jun 2020 · 5Komentar · Sumber: TheThingsNetwork/lorawan-stack

Ringkasan

Optimalkan pencocokan perangkat di Server Jaringan

Mengapa kita memerlukan ini?

Untuk Redis I/O, penggunaan memori dan kinerja komputasi secara keseluruhan saat kami meningkatkan penggunaan kembali DevAddr dan meningkatkan ukuran DevAddr.

Apa yang sudah ada? Apa yang kamu lihat sekarang?

Saat ini, NS menjangkau perangkat oleh DevAddr, dan mendekodekan proto. Protonya besar, berisi status mac dan pesan uplink dan downlink terbaru, ditambah lagi bisa ada banyak proto (ratusan) duplikat DevAddr.

Apa yang hilang? Apa yang ingin kau lihat?

Kami membutuhkan tampilan terwujud di Redis untuk mencocokkan uplink ke perangkat dengan UID, sebelum memuat perangkat yang cocok.

Bagaimana Anda mengusulkan untuk menerapkan ini?

Simpan informasi yang relevan untuk dicocokkan dalam kunci khusus, jadi pada dasarnya DevAddr, FCnt, NwkSIntKeys, dan UID.

Kumpulan yang diurutkan dan/atau peta hash akan berguna karena ini memungkinkan penyortiran Redis dan kueri dari FCnt, mendapatkan kunci integritas dan UID.

Perbarui tampilan terwujud ini pada setiap uplink dan join-accept.

Kami dapat melakukan migrasi bergulir dengan mundur ke skema pencocokan yang ada.

Bagaimana Anda mengusulkan untuk menguji ini?

Tes unit, berpotensi dengan menegaskan kunci Redis dan nilainya dalam pengujian.

Bisakah Anda melakukannya sendiri dan mengajukan Permintaan Tarik?

Dapat meninjau

network server performance in progress scalability

Sumber

johanstokking

Semua 5 komentar

Saya pikir pendekatan yang lebih baik adalah mengatasi ini dengan cara lain, yang juga meningkatkan kinerja dalam kasus umum - pisahkan data yang menghabiskan ruang dari proto dan simpan secara terpisah - yaitu recent_uplinks , recent_downlinks dll., juga lebih masuk akal untuk menyimpan ini dalam daftar daripada menyusun proto - itu berarti kita sebenarnya tidak perlu menanyakan pesan yang ada, tetapi hanya akan menambahkan yang baru, yang jauh lebih efisien, tetapi mari kita mulai dengan hanya proto dan pergi dari sana.
Mengingat kami memiliki fieldmask, pemisahan proto akan cukup mudah dan sepenuhnya ditangani oleh implementasi registri Redis.

Jadi sarannya adalah memiliki:

ns:devices:uid:foo:bar:recent_uplinks
ns:devices:uid:foo:bar:recent_downlinks
ns:devices:uid:foo:bar:mac_state:recent_uplinks
ns:devices:uid:foo:bar:mac_state:recent_downlinks
ns:devices:uid:foo:bar:pending_mac_state:recent_uplinks
ns:devices:uid:foo:bar:pending_mac_state:recent_downlinks
...
ns:devices:uid:foo:bar - sisa proto

Migrasi akan terjadi secara otomatis, begitu pula dengan bidang yang sudah usang ditangani di registri.

rvolosatovs pada 22 Jun 2020

Apa statusnya di sini?

johanstokking pada 20 Agu 2020

Saya berharap ini akan siap untuk digabungkan pada akhir minggu depan.
Implementasi dilakukan selama berminggu-minggu, mengerjakan refactoring dan kemudian mengadaptasi tes sejak itu

rvolosatovs pada 20 Agu 2020

👍1

Harap pertimbangkan untuk membuat kesalahan yang dikembalikan lebih jelas jika perangkat tidak dapat dicocokkan. Lihat misalnya https://github.com/TheThingsNetwork/lorawan-stack/issues/2394.

Kami tidak dapat memberikan banyak informasi, tetapi device_not_found menyiratkan bahwa perangkat tidak dapat ditemukan, sementara mungkin saja DevAddr tidak ditemukan sama sekali, bahwa MIC tidak cocok dengan entri yang ditemukan dan/ atau bahwa FCnt mengatur ulang saat itu tidak diizinkan dengan entri yang ditemukan.

johanstokking pada 24 Agu 2020

👍1

Saran yang bagus, tetapi saya pikir yang terbaik adalah melakukannya sebagai langkah selanjutnya, karena ini akan menjadi PR besar untuk ditinjau dengan banyak fungsi yang relatif kompleks

rvolosatovs pada 24 Agu 2020

👍1

Apakah halaman ini membantu?

0 / 5 - 0 peringkat