@ProEsp8266 - страница 1537

SetPf

льем страничку с внешней флехи)

А прям на флеш пишите?

SetPf

Ну хотя когда она 1ф и 800кб почему бы нет. Я со свою на SD держал. Т.к. там проект веба изначально вроде 5МБ был лол =) Пришлось SD 4х пиновый разводить лол, а то по SPI не читалось вообще.

Василий

А прям на флеш пишите?

да, прям в определенные сектора

SetPf

Да. Локальность одно из условий. Ну плюс я еще логи на СД пишу и апдейчусь с нее, так что сойдет =) Один фиг нужна была, но 4 линии сидящие на жтаге жалко.Пришлось перемычки мудрить.

Василий

чтобы без задержек на фс итд вылетало

Василий

А прям на флеш пишите?

у нас внешняя 16 мб spi nor

SetPf

Зато он теперь козыряет на собесах как делал морду под бэк на Си и ОПТИМИЗИРОВАЛ вырезанием букв и спецсимволов. И вроде прокатывает.

SetPf

Ну я не против вью, т.к. ресурсы что файлами грузятся - один фиг были бы нужны. Печально что кор там 200кб голый будет где-то. Но есп проворачивает, так что сойдет. Учитывая что дизайнеры тоже молодцы, любители задействовать 5 кастомных шрифтов блин.

SetPf

А я молодец, что не могу совладать с ограничением на очередь запросов на сервер. Все молодцы.

SetPf

Увеличить длинну очереди.

SetPf

Тип хз, ОЗУ свободная есть. В теории можно было бы с 16 до 64 увеличить и хрен забить.

SetPf

4 клиента одновременных у нас это совсем уж невозможная ситуация.

SetPf

Ну вон выше человек говорит, можно спецхидер заслать с ограничением.

SetPf

Я правда про такой не нашел.

Alexey

В RFC есть еще заметка, которая расписывает should must и can. Так что, should - всего лишь рекомендауия, на которую все кладут

Alexey

Чем собрать в один файл - зависит от фремворка, на котором собираете. Покурите webpack (подозреваю, что у вас там явно js) + какой-нибудь uglifier и для js, и для css. + минифакатор, который вырежет пробелы, переносы и т. П. + сразу хранить в gz, чтобы минифицировать объем передачи

Alexey

Я не так истрактовал сообщение)

SetPf

Чем собрать в один файл - зависит от фремворка, на котором собираете. Покурите webpack (подозреваю, что у вас там явно js) + какой-нибудь uglifier и для js, и для css. + минифакатор, который вырежет пробелы, переносы и т. П. + сразу хранить в gz, чтобы минифицировать объем передачи

В gz уже

SetPf

Проблема не веса, а именно сборки билда в 1 файл. Искали - пока не нашли =\

Alexey

Так на чем написано-то?)

Alexey

Проблема не веса, а именно сборки билда в 1 файл. Искали - пока не нашли =\

Не вижу проблем даже руками это сделать. Или простейшим скриптом на bash

SetPf

Не вижу проблем даже руками это сделать. Или простейшим скриптом на bash

тип оно же билдится, каждый билд руками переписывать? Плюс я не уверен что там все так легко.

SetPf

Ок гляну.

Alexey

тип оно же билдится, каждый билд руками переписывать? Плюс я не уверен что там все так легко.

Сделать скрипт, воткнуть в pipeline)

SetPf

Картинки уже в svg инлайним

Alexey

Сделать cat * > all_in_one.htm)

Alexey

Лучше не в хэдер, а в конец тела, а то страница не будет рендериться, пока весь зедер не распарсит, это долго и выглялит некрасиво. Особенно заметно на больших файлах

Alexey

Ну, тут уже логику работы смотреть надо. Не все теории одинаковы на практике)

SetPf

да крутилка есть, без нее совсем туго было =)

SetPf

ок спс посмотрю

SetPf

чет у меня было ощущения что там дохрена надо руками перетаскивать было

SetPf

а ща подумал - реально же 1 файл

SetPf

Вот с favicon ток еще вопрос.

SetPf

Мне говорят что нельзя ее тоже заинлайнить

SetPf

шоб был же

?

Порой очень даже надо. Я вон себе понемногу вездеход пишу умеющий все сразу. Ни тебе приложений, ни интернета не надо, и все шпарит только знай ip. А если не надо, то и нагрузки нет, всего-то место на флехе отъедает немного. Если места не хватает, на sd карте живет все тяжеловесное. Как можно судить из фото нагородил я уже не мало там, один фиг на чипе еще вагон места. Просто не надо говнокодить(копипастом) всякими js и будет счастье.

?

Проблема не веса, а именно сборки билда в 1 файл. Искали - пока не нашли =\

Из контекста вырываю конечно сообщения, не понимая сути проблемы. Так понимаю чип перегружен запросами? Врубайте кэширование принулительное там, где можно. Выключайте асинхронный режим у скриптов. Проблема только при первой прогрузке, дальше уже все скэшировано. Картинки меняем на svg и пишем в тело главной страницы, а другие подгружаем фреймами или через js. Короче все эти проблемы"древних" были во времена диалапов и прекрасно решались. Просто надо максимально воспользоваться "старой школой" и куча проблем просто не смогут появиться.

?

Есть еще новые фишки с "локальным контентом" браузера, но я не вникал. Это должно быть еще круче. Один раз скачал и не паришся.

?

Честно, не замечал проблем с затупами по сети, просто надо понимать на что способен чип. А для серьезных серверных дел у меня есть onionOmega там тупо линух сидит.

Evgeniy

Я оч заебался с этим бороться.

Ого! Вариант с IDF 4.3.2 и lru_cache_enabled мне сразу помог, но хочу на 4.4 тоже самое

Evgeniy

В моем случае: после подключения к точке доступа на ESP32 приходит GET запрос, чтобы узнать версию прошивки. И спустя несколько переподключений исчерпывается лимит открытых соединений.

Gaius Claudius Glaber

В моем случае: после подключения к точке доступа на ESP32 приходит GET запрос, чтобы узнать версию прошивки. И спустя несколько переподключений исчерпывается лимит открытых соединений.

Отбой по тайм-ауту. Или закрывайте самии соединение.

ok-home

Ого! Вариант с IDF 4.3.2 и lru_cache_enabled мне сразу помог, но хочу на 4.4 тоже самое

Доброе утро. Попробуй esp_err_thttpd_sess_update_lru_counter(httpd_handle_thandle, int sockfd) Update LRU counter for a given socket. LRU Counters are internally associated with each session to monitor how recently a session exchanged traffic. When LRU purge is enabled, if a client is requesting for connection but maximum number of sockets/sessions is reached, then the session having the earliest LRU counter is closed automatically. Updating the LRU counter manually prevents the socket from being purged due to the Least Recently Used (LRU) logic, even though it might not have received traffic for some time. This is useful when all open sockets/session are frequently exchanging traffic but the user specifically wants one of the sessions to be kept open, irrespective of when it last exchanged a packet.

ok-home

технически - должен закрывать самые старые сокеты, чтобы не было превышения количества сокетов

Evgeniy

Ага! Это даже работает на версиях IDF 4.3 и ранее, но каким-то образом даже без хидера Connection: Keep-Alive - не работает на 4.4 и 4.4.1. Я пробовал вот этот патч, но тоже не помогает, здесь как раз эту функцию вставляют:

Evgeniy

Прямо в функцию открытия нового соединения

Evgeniy

Как такой баг остался незамеченным целым сообществом? 😁

ok-home

Calling this API is only necessary if the LRU Purge Enable option is enabled ?

Evgeniy

да, включена....

Evgeniy

Доброе утро. Попробуй esp_err_thttpd_sess_update_lru_counter(httpd_handle_thandle, int sockfd) Update LRU counter for a given socket. LRU Counters are internally associated with each session to monitor how recently a session exchanged traffic. When LRU purge is enabled, if a client is requesting for connection but maximum number of sockets/sessions is reached, then the session having the earliest LRU counter is closed automatically. Updating the LRU counter manually prevents the socket from being purged due to the Least Recently Used (LRU) logic, even though it might not have received traffic for some time. This is useful when all open sockets/session are frequently exchanging traffic but the user specifically wants one of the sessions to be kept open, irrespective of when it last exchanged a packet.

Добавил вызов внутрь функции open_fn. Точно также полный игнор LRU.

ok-home

хм - сорри - это наоборот позволяет не закрывать нужный тебе сокет автоматом - Обновление счетчика LRU вручную предотвращает очистку сокета из-за логики наименее использовавшегося (LRU), даже если он может не получать трафик в течение некоторого времени.

Evgeniy

Пока понял, что этот код не выполняется, где-то видел другую версию этого блока с if:

ok-home

Пока понял, что этот код не выполняется, где-то видел другую версию этого блока с if:

не выполняется - или не закрывает сокеты - вставь отладку посмотри что делает то - там примитивная логика - проверяет LRU и закрывает httpd_sess_trigger_close самый старый

Evgeniy

они переписали функцию httpd_is_sess_available по сравнению с idf 4.3.2

Evgeniy

Ошибка где-то в другом месте: не прокатывает именно accept(), даже если все соединения были закрыты!