Результаты поиска

И сюда ардуинщики добрались: Ставим Nginx: Запускаем тест запроса просто страницы по умолчанию "/" Заходим в консоль (добавляем apt-get install net-tools) и видим бесконечный список: root@819eb0560fc5:/# netstat -t Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address...

Ещё для справки: Различие однопоточного самописного web-сервера конфигурации на тупейшем контроллере и древней OpenWRT: Для одного клиента: Для 10 thread (хотя расчет велся до 5-ти клиентов за раз): Т.е. имеем различие от 20 до 2-х раз, при разнице производительности CPU в 1008*4 МГц...

Я не призываю использовать Modbus TCP. Это в качестве примера, как самого простейшего и поддерживаемого протокола имеющего стандарты на передачу бинарных данных. SSL у него тоже имеется. Для обще-пользовательского сервера у него для современности есть ограничение в адресном пространстве...

Вообще не понятно, зачем там нужен MQTT? Если охота какой-то простой и известный протокол, то без проблем годится и устаревший, но везде поддерживаемый Modbus TCP. :) Любой тест TCP в локальной сети покажет, что время запрос-ответ в Modbus TCP составляет до 1 ms и в основном уходит на время...

Классический подход давно не работает - это как в случае с FastCGI вы получите ещё более slow систему. Не клюйте на рекламу – “Fast” это ныне = “Slow”. Аналогично было с vfork() – оно было введено для ускорения, в целях оптимизации. Отношение скорости выполнения соответствовало переключению...

И как промежуточный итог: Вы считаете, что после таких советов, как вы привели и более глубоких знаний что творится ныне в реальном совте от нашествия Ардуинщиков не захочется ругаться матом? От такого разгильдяйства в ПО и появляются всякие извращенцы типа Nikolz, т.е. современное ПО - это...

Алексей. Про CGI или FastCGI даже не хочу измерять. Вы это можете сами - измерьте запрос вывода в web пусть таблицы route и опишете как оно, или как для этого применить ваши указания. :)

Далее сделаем сравнение любительской писанины для проца в сотни раз тормознее, с нашествием ардуинщиков в Linux. Доморощенное, не ардуино подход, говорит о десятикратных улучшениях по показателям: А так-же посмотрим на ошибки в OpenWRT httpd. При тесте и после имеем простыню с тысячами...

До CGI мы ещё доберемся, но ему предшествует простое HTTP соединение. Вот с него и начнем. Простейший тест HTTP запросов к web на OpenWRT, модуль NanoPi-R1. Установлена версия: LuCI openwrt-18.06 branch (git-18.228.31946-f64b152) / OpenWrt 18.06.1 Установлена поддержка HTTPS, web по HTTP...

И о потреблении, при 20 замерах всех значений в секунду с GY-91 (MPU9250 + BMP280) на модуле JDY-10 (TLSR8266) c UBIA Общее: Модуля GY-91:

В очередной раз nikolz залез в тему, в которой у него нет знаний, и навязывает своё непроверенное решение. Даже не решение, а фантазию. И далее, тут-же в этом признается, попутав персонажей и всю детерминацию, с переносом обвинений в своих поступках на других :) Разжеванно, для nikolz, т.к. он...

И как всегда от дебила nikolz примера так и не дождались. Одни отговорки :P

Я ещё раз перечитал ваше сообщение: и это породило навязчивую мысль - а что делает этот ваш описываемый CGI? Грузит картинки по выбору клиентов? Вроде более ничего другого описываемая вами система не умеет. Ну честно - не вижу смысла в ней - поиграть в рисование HTML страниц? Онлине-магазин и...

И нету у меня там никаких FastCGI - всё интегрированно в один процесс, если это можно так назвать :)

Вы это расскажите современным писателям, к примеру uci в OpenWRT, а не мне. У меня и так 200 MHz mips обслуживает 10 тысяч запросов в сек в системе автоматизации... А ныне хочу увеличить ещё на один десятичный порядок и пару раз на более новых CPU... Я думаю, что вы забываете - не все web...

kharlashkin - вы пишите на питоне, но проверьте сколько он раз в секунду откроет и закроет элементарный socket, да на одном ядре :) Вот пример времени исполнения вызова другого приложения в Linux. Это производится через fork() и аналогичные процедуры. Считаем 1/0.0001725 = всего 5797 раз в сек...

Ещё не забывайте элементарный пример из прошлого – i386 на сотню MHz не мог прокачать UART на 115200 Baud, т.е. не мог обслужить прерывание 11520 раз в секунду, пока в UART не вставили FIFO на 8 байт :) И память у него была c произвольным доступом в 40..70 ns и ему опустошение кеша не сильно...

WiFi в идеальных условиях на ESP32 прокачивает до 1200 пакетов в секунду, что равно 1.8 мегабайта сырых данных. Это каждый пакет в полный MTU (1500 байт). При этом битовая скорость выходит практически равная кодировке PHY и в RF кадре пакетик IP выглядит как часть кадра. Предельная длительность...

Всё совпадает как в аптеке с докой от Bosh, мелкая разница от номинального питания:

Ой - на три порядка опшибся - в sleep читать 190 nA!