Відповідь:
Для перевірки спробували створювати змінні і запускати на виконання відправку змінної фіксованого розміру. Тест показав, що http.post на 443 порт перестає працювати якщо пам’яті менше ніж 30,5 кБ. При тому, що початково видно 40-41 кБ, то на решту програмного коду лишається тільки 10 кБ. А це дуже мало, щоб реалізовувати інші “потужні” задачі.
Наприклад, функціонал Web-сервера засобами net.createServer()
та net.listen
на 80 порт, потребує близько 10-12 кБ.
Є різні шляхи оптимізації пам’яті з вивантаженням всього зайвого і завантаженням лише тоді, коли треба – у вигляді окремих lc-файл-модулів через require()
.
Також можливо розділити роботу пристрою на режими, щонайменше:
- режим “звичайного завантаження”,
- режим “налаштувань”.
Під час дії режиму “звичайного завантаження”, на пристрої взагалі може бути вимкнений протокол взаємодії з мережею (звісно, все від задумі розробника і вирішуваної задачі). Локальний веб-сервер може запускатися лише під час завантаження пристрою у режимі “налаштувань”.
Код тестової програми:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
txt_arr = {} count = 1 function test_request() txt_arr[count] = '---text string 512 bytes---'..node.random(32765) http.post("https://domain/post", 'Content-Type: application/json\r\n', '{"hello":"world"}', function(code, data) if (code < 0) then print(count, "HTTP request failed", code, node.heap()) else print(count, code, node.heap()) end end ) count = count + 1 end req_tmr = tmr.create() req_tmr:register(20000, tmr.ALARM_AUTO, function() test_request() end) req_tmr:start() |
Видача в консоль тестової програми:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
dofile("https_min_heap_test.lua") 2 200 35928 -- перший прохід чомусь не потрапив у консоль, тому "2" 3 200 35368 -- "200" це код успішного виконання HTTP-запиту, далі вільна пам'ять 35368 байт 4 200 34832 5 200 34272 6 200 33656 7 200 33120 8 200 32568 9 200 32024 10 200 31336 11 200 30800 E:M 536 -- це кількість вільної пам'яті під час роботи бібліотеки Mbed TLS HTTP client: Connection timeout 12 HTTP request failed -1 30104 -- "-1" це помилка нестачі пам'яті, "30104" це поточна кількість пам'яті після виходу з бібліотеки Mbed TLS, і як видно, цього не вистачає. E:M 536 HTTP client: Connection timeout 13 HTTP request failed -1 29560 E:M 544 HTTP client: Connection timeout 14 HTTP request failed -1 29016 E:M 536 HTTP client: Connection timeout 15 HTTP request failed -1 28472 E:M 536 HTTP client: Connection timeout 16 HTTP request failed -1 27928 E:M 536 HTTP client: Connection timeout 17 HTTP request failed -1 27384 E:M 272 E:M 1584 E:M 1584 HTTP client: Connection timeout 18 HTTP request failed -1 28096 E:M 264 E:M 1584 E:M 1584 HTTP client: Disconnected with error: -16 -- "-16" це помилка синхронізації часу під час TLS/SSL рукостискання HTTP client: Connection timeout 19 HTTP request failed -1 27496 > req_tmr:unregister() -- тут ми зупинили таймер = node.heap() -- перевірили скільки стало вільної пам'яті >27944 > txt_arr = nil -- тут ми обнулили змінну у яку писали тестове “сміття” > = node.heap() 38320 -- очистка змінної додала 10376 кБ вільної пам'яті. Приблизно так і має бути. |
Висновок
Потрібно передбачати, що основний код і код HTTPs-відправника, веб-сервера, чи іншого, потужного і охочого до оперативної пам’яті процесу, мають працювати динамічно – в кожен момент часу лише той функціонал, котрий потрібен користувачу.
Перевірено на версії 2.2.1-master_20181207 з 20-ма C-модулями.