Pull to refresh
1
0
aiotko @aiotko

User

Send message
Добрый день!

Можете подсказать, пожалуйста, по функции zclDIYRuZRT_LeaveNetwork()?

1. Не знаете возможно ли покинуть текущую сеть, удалить ее настройки и начать поиск новой доступной сети без перезагрузки устройства?
2. После перезагрузки устройства не происходит поиск новой сети, т.е. нужно нажать кнопку еще раз. Возможно ли каким-то образом «запланнировать» поиск после перезагрузки?

Заранее спасибо!
Огромное спасибо за статью!
Подскажите, пожалуйста, какую версию прошивки используете на координаторе zigbee2mqtt?
Я использую стик с чипом CC2531, прошивка на базе Z-Stack 1.2, насколько я понял 3.0 еще очень сырая и не всегда работает с устройствами 1.2.
Нужно ли переходить на нее если писать прошивки под CC2530 на версии 3.0?
Интересно есть ли какие-то программы/сервисы для разводки макетных плат по аналогии с разводкой (трассировкой) печатных?
Проектировать устройства с >10 элементов методом проб и ошибок имхо достаточно непросто, а цена ошибки — испорченные компоненты :)
Полностью поддерживаю тезис о том, что «наличие средства такого анализа позволило бы значительно упростить работу многих программистов и некоторых ученых, работающих над алгоритмами оптимизации в СУБД».
Для средств разработки приложений, подобные средства уже есть и, в умелых руках, очень помогают разработчикам. Например — Pascal Analyzer для проектов написанных на Delphi.

В работе не раз сталкивались с необходимостью оптимизации быстродействия работы приложения, узким местом которого было взаимодействие с БД. Достаточно часто это было приложение написанное другими разработчиками.

Как правило, использовали аналитические методы и действовали по алгоритму:
— с помощью трейсеров, консоли Оракл и т.п. инструментальных средств, определяем самые «медленные» запросы, которые с точки зрения пользователей мешают работе системе;
— максимально оптимизируем запросы и структуру БД;
— проводим нагрузочное тестирование;
— если результат все еще не устраивает возвращаемся на шаг 1 :-)

Типовые причины проблем с быстродействием с которыми сталкивались:
— неоптимальная структура БД.
Т.е. БД может быть спроектирована в 3НФ, «по классике», однако не учитывать популяцию запросов приложения.
Варианты решения — изменение структуры (с или без нарушением 3НФ), создание объектов material view или таблиц обновляемых триггерами специально под определенные задачи.

— множество точечных запросов вместо одного/двух.
При этом основное время уходит не на сам запрос, а на взаимодействие приложения и БД по каждому запросу.
Самый простой пример — много запросов вида select… where id =…
Вариант решения — замена на один запрос вида select… where id in ( ..., ..., ...).
В случае, если каждый следующий запрос требует данные предыдущего (например «вытягиваем» дерево узлов из БД) — можно использовать иерархические запросы или заранее предсохраненные, обновляемые триггерами данные.

— неоптимальный план запроса.
Либо изначально, либо в какой-то момент СУБД меняет план и запрос начинает работать в несколько раз медленнее.
Варианты решения — создание/удаление индексов, ручное изменение плана запроса средствами СУБД (например, консоли Оракл), изменение текста запроса так, чтобы СУБД «поняла как лучше» выполнять этот запрос (последний вариант — на грани шаманства :-) ).
На практике также встречаются ошибки даже в таких СУБД как Оракл, которые могут не только менять план запроса, но и приводить к некорректным данным, возвращаемым таким запросом. Здесь может помочь только чтение документации, переписка с саппортом самого СУБД, эксперименты.

неоптимально написанный запрос (часто для профессионала явно неоптимально), который на небольшом количестве данных работал нормально, а в реальной системе внезапно (!) начал тормозить.
Вариант решения — книги «Основы SQL-для чайников/проффесионалов» для разработчика, который написал этот запрос, и «Почему плохо давать задачи по написанию запросов новичкам, а потом ленится их почитать» ведущему разработчику/тим-лиду/ПМ по проекту. Может помочь еще книга «Зачем нужен Code Review».

«слишком много» данных в таблицах и предыдущие варианты решений не актуальны.
Варианты решения — технический: партирование, структурый: отделение актуальных данных от архивных.

Думаю, для разработчиков было бы полезно, чтобы средство автоматического анализа:
— отрабатывало все перечисленные и много других подобных ситуаций;
— предоставляло возможность разработчику выделять «приоритетные» запросы, поскольку только одним автоанализом неэффективные, с точки зрения пользователя, запросы не выявить. Например, для какого-то запроса, который часто выполняется, нормальным временем может быть 1000 секунд (если это регламентная задача или часть задачи по печати отчета занимающего 1000 страниц). В то же время, для более «редкого» запроса 2 секунды может быть уже недопустимым временем (например, кассовые операции, работа с банкоматом);
— как дополнение содержало инструкцию с описанием как отрабатывать рекомендации и детальным разбором «анти-патернов», их примерами.

Как первый шаг к написанию такого средства, возможно, полезно было бы хорошую книгу или Интернет ресурс по SQL где описываются патерны/анти-патерны наиболее часто встречающихся ситуаций в приложениях, работающих с БД.

Если будут желающие – было бы интересно поучаствовать в написании такой книги, возможно, в зависимости от загрузки по работе – разработке такого средства.

Information

Rating
Does not participate
Registered
Activity