По идее порт 23600 должен быть в приоритете.
В модуле объекта должен быть метод HTTP_GetPort, примерно так называется, можно по номеру порта поискать.
Ну или просто трафик http посмотреть снифером.

Думаю достаточно на АТС в iptables закрывать или открыть порт 23600. Или просто nginx прибить процесс.

Добрый день.

Панель телефонии, версия для управляемых форм: 1.4.26.34
FreePBX: 15.0.17.64

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



Вот наша АТС и модули, фильтр, права:


https://wiki.miko.ru/astpanel:ats:freepbx_distro вот по этой инструкции делали и все версии как на тесте брали
https://wiki.telefon1c.ru/smartivr:freepbx это установка второго модуля

Делали замеры в 1С, постоянные HTTP-соединения, которые все время съедают:
ЗамерТормоза1.pff (2.25 МБ)

Вот видео, с 55 секунды видно, что слева звонки на АТС в реальном времени, до прихода двух звонков 1с реагирует на каждый клик по строкам, потом пришло сразу два звонка (видно в левом нижнем углу очередь) и 1С начала подвисать и не реагировать на клики,  при том, у меня не настроен номер в панели и поставлена галка использования, просто подключена АТС к 1С (введен адрес и тп):
ВидеоТормоза1С.mp4 (9.02 МБ)

Куда еще смотреть, не подскажете, где узкое место?

Спасибо, сделали как вы сказали. Теперь, 1С не висит, значительный прогресс, но и не летает, как прежде. В 1С в замерах производительности из топов пропал вызов запроса http, который сильно нагружал: были закомментированы строки кода в функции HTTP_GetVarPing, не относящиеся к порту 23600.

Теперь со значительным опережением в замерах значится обращение к регистру "МИКО_опИндексНомераТелефонов", в котором 230607 строк).




Сам замер: Замер2.pff (1.03 МБ)
Конечно, телефоны построены по справочнику лицевых счетов абонентов и там много не действующих.
Надо, наверное, пошагово смотреть во-первых, откуда столько вызовов за относительно непродолжительное время - почти два часа.

Второй узкий момент в замере был замечен в сохранении общих настроек пользователя, по времени, почти как все 1200 запросов к индексам телефонов:


Интересный момент с настройками, не копал еще, почему они сохраняются, вроде бы я сам интерактивно ничего не делал, просто запустил сеанс и поставил замер.

Какие-то методики оптимизации посоветуете в таком случае?