MajorDoMo

Вопрос скорее к автору проекта, либо к тем кто проводил эксперименты с системой.
Система довольно таки гибкая. Можно одни и те же данные из интернета получить как минимум тремя способами (json, xml, из http через webvars). Такой собственно вопрос:

Через что все таки обращаться к сторонним ресурсам, если доступны все 3 пути при минимальной загрузке?

Глуповато звучит, но если вдуматься - например у webvars есть интервал обновления...я так полагаю - это к каждой переменной таймер прикручен, и допустим если у меня около 200 переменных - это в системе тикает 200 таймеров?

Так же - допустим у меня несколько переменных, одна получает данные через json, вторая через xml, третья через http. Это для третей тикает таймер, вторая вызывается по скрипту, первая скажем вписана в OnNewHour. И если бы они все вызывались по OnNewHour, мы бы избавились от таймера, который тикал для webwars?

Естественно для 3х переменных индикатор загрузки проца даже на 1% не сдвинется, но когда их под 200 каждым способом - думаю стоит задуматься.

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

Насчёт таймеров не совсем так. У каждой переменной в webvars есть интервал обновления и время последнего обновления. Если прошло времени больше чем последнее обновление + интервал, то она обновляется. Таким образом переменных может быть хоть несколько тысяч, главное, чтобы хватило канала их все загрузить.

По поводу "ночной" оптимизации -- я не думаю, что это очень перспективно. В системе узкие места по производительности, но в основном они связаны с базой данных, работу с которой стоит оптимизировать. Периодически я этим занимаюсь (правкой узких мест), так что движение в этом направлении есть. Самое сложное это диагностика -- локализация "затыков" и если кто-то может в этом помочь, то буду только рад.

> Самое сложное это диагностика -- локализация "затыков" и если кто-то может в этом помочь, то буду только рад.

Я могу помочь. Уже это озвучивал — с системе прямо беда с приёмом данных по сети. Входящие данные от датчиков (если приходят потоком чаще, чем раз в 8-10 секунд) поднимают загрузку к 80-90%.

В качестве решения приходится формировать пакеты на стороне Ардуины, что не очень удобно, а в случае пир-датчиков — вообще невозможно. А вот пакеты распаковываются без проблем с быстродействием. То есть проблема в алгоритме работы с сетью.

Alex писал(а):> Самое сложное это диагностика -- локализация "затыков" и если кто-то может в этом помочь, то буду только рад.

Я могу помочь. Уже это озвучивал — с системе прямо беда с приёмом данных по сети. Входящие данные от датчиков (если приходят потоком чаще, чем раз в 8-10 секунд) поднимают загрузку к 80-90%.

В качестве решения приходится формировать пакеты на стороне Ардуины, что не очень удобно, а в случае пир-датчиков — вообще невозможно. А вот пакеты распаковываются без проблем с быстродействием. То есть проблема в алгоритме работы с сетью.

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

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

Дефект 100% есть. Из практики: 10 пир-датчиков генерируют такой поток сигналов, который стопорит довольно мощную систему. Или 13 электродатчиков, если передавать их значения по отдельности, тоже поднимают загрузку процентов на 50%, а если одним пакетом, то короткий всплеск на 5-7%.