Зависает веб сервис 1с

Обновлено: 05.07.2024

Возьмем для примера веб-сервер на базе MS IIS с публикациями баз 1С. Бывают случаи, когда сеансы пользователей зависают. Например, при использовании веб/тонкого клиента 1С.

Одно дело — клиент-серверный вариант, с применением СУБД. С ним проще. Открываете административную консоль и через список закрываете эти зависшие сеансы.

В случае файловой базы все не так тривиально. В Конфигураторе вы можете видеть эти якобы активные сеансы, но отдельной команды в интерфейсе на закрытие — попросту нет.

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

Но, на практике выполнить сложнее, т. к. баз бывает несколько и ведется активная работа других пользователей. Могут быть ошибки и потери связи. Плюс недовольства сотрудников, что их работу прервали.

Какое может быть решение? Один из выходов — более тонкая настройка IIS.

Сделать так, чтобы каждая опубликованная база (приложение) выполнялась в отдельном пуле приложений. По умолчанию все публикации «привязываются» к DefaultAppPool.

Выберите время и настройте IIS, чтобы каждой информационной базе был сопоставлен отдельный пул.

Или сгруппируйте базы так, как вам удобно, чтобы сократить количество пулов. Выходит, что базы будут не в одной «куче», а по отдельности.

  1. Откройте консоль «Диспетчер служб IIS».
  2. В левой части выберите «Пулы приложений», а справа по команде «Добавить пул приложений…» зарегистрируйте новый пул с настройками, аналогичными пулу по умолчанию. Добавьте понятное имя, например, по названию публикации ИБ.
  3. Перейдите в список опубликованных баз.
  4. Выберите ИБ, через «Основные настройки…» укажите новый пул из ранее созданного в п. 2.
  5. Повторите шаги 1-4 для других информационных баз при необходимости.

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

Использование веб-сервера и публикаций информационных баз — один из способов оптимизации 1С. Особенно при работе с ИБ в файловом варианте. Так безопаснее. Сотрудники подключаются к ИБ 1С через браузер или тонкий клиент , не имея прямого доступа к файлам.

В статье расскажем, как решали возникающие вопросы по настройкам Internet Information Services. Через призму своего опыта и коллег.

Сертификат выдается сроком на 90 дней. Для автоматического продления создается периодическое задание в Планировщике. При запуске задачи сайт должен быть доступен (пройти проверку домена) по 80-му порту.

II. Типовая настройка и публикация информационных баз на IIS

На что обратить внимание:

1. Состав компонентов IIS — в Интернете полно инструкций и указаний. Повторяться не будем.

2. Установка 1С необходимой разрядности . Варианта 2: x86 (32-разрядное приложение) или x64. Обязательно выбираем «Модули расширения веб-сервера».

3. Права для встроенной группы /пользователю веб-сервера (IUSR) на папки:

  • с установленной платформой — на «чтение и выполнение» (для старта процессов);
  • самих расположений ИБ — на «изменение» (в случае файлового варианта).

4. Публикация базы через Конфигуратор 1С . Возможно потребуется открыть программу с повышенными правами — «Запуск от имени администратора».

5. Для 32-разрядного клиента 1С в диспетчере IIS включаем разрешение запуска ( DefaultAppPool — Дополнительные параметры — Разрешены 32-разрядные приложения = True ). Для 1C x64 — значение не меняем.

6. На странице сопоставления обработчиков для «1С Web-service Extension» потребуется указать путь к исполняемому модулю :

  • x86 — «C:\Program Files (x86)\1cv8\8.3.x.xx\bin\wsisapi.dll»;
  • x64 — «C:\Program Files\1cv8\8.3.x.xx\bin\wsisapi.dll».

Либо изменяем путь к библиотеке в файлах web.config через Блокнот (располагается, как правило, в c:\inetpub\wwwroot\<имя базы>).

Если в п. 2 все сделано правильно — по указанному пути должен присутствовать файл wsisapi.dll.

7. В частных случаях требуется перезапуск служб IIS . Выполните «Перезапустить» в оснастке управления или перезагрузите сервер.

✅ Соблюдаем соответствие разрядности: если запускаем и публикуем 64-разрядный клиент 1С:Предприятие, то dll также должна быть 64-битной версии.

Если публикуем 32-разрядную версию 1С, то ставим разрешение запуска 32-разрядных приложений на IIS и проверяем путь к wsisapi из каталога x86.

III. Если клиент 1С зависает при подключении к базе по web

Прежде посмотрите этот материал — там общие рекомендации.

Другой случай. Файловая ИБ опубликована на IIS. После авторизации зависает на эмблеме 1С. При открытии Конфигуратора — все нормально.

В журналах Windows ошибка «Процесс, обслуживающий пул приложений "1С", не ответил на команду ping».

  • проверьте права на папку с базой 1С для IUSR/IIS_IUSRS, уровень доступа — на «изменение»;
  • в оснастке IIS «Пулы приложений — <пул_1С> — Дополнительные параметры — Модель процесса» задайте для « Максимальная задержка отклика при проверке связи » значение, превышающее 90 секунд;
  • посмотрите на поведение IIS при «Проверка связи включена» = False.
📝 Из справки: установка [pingingEnabled] (Проверка связи) в значение false не позволит IIS проверять, выполняется ли рабочий процесс, и таким образом сохранит его активным до остановки процесса отладки.

✅ Установка «Максимальное время отклика пинга» в большое значение позволит IIS продолжать наблюдение за рабочим процессом.

Информационная база 1C опубликована на IIS. При работе через тонкий клиент, при нажатии на «Отчеты» вываливается ошибка.

Описание: Необработанное исключение при выполнении текущего веб-запроса. Изучите трассировку стека для получения дополнительных сведений о данной ошибке и о вызвавшем ее фрагменте кода.

✅ Откройте настройки пула приложений и проверьте «Режим управляемого конвейера» = «Classic».

В версии 8.3.9 мы выполнили значительное количество задач по оптимизации разных механизмов платформы. Здесь хочется рассказать об одной из них. Это повышение производительности веб-сервисов.

Переиспользование сеансов

Недостаточная производительность веб-сервисов объяснялась тем, что каждый вызов веб-сервиса имел значительные накладные расходы на создание и завершение сеанса. Причём при создании каждый раз выполнялся обработчик УстановкаПараметровСеанса(), который в типовой конфигурации может быть довольно «тяжёлым».

Кроме этого существовал и функциональный недостаток. Веб-сервисы не обладали состоянием. Это не позволяло реализовывать логику, использующую сохранение состояния между вызовами веб-сервиса.

Этих результатов удалось достичь за счёт того, что мы реализовали две различные стратегии, обеспечивающие переиспользование сеансов:

При автоматическом переиспользовании сеансов клиент не имеет возможности влиять на количество сеансов и время их жизни. Ему просто автоматически выделяется сеанс из существующего пула сеансов. Такая стратегия подходит для высоконагруженных публичных сервисов, к которым обращаются клиенты, выполняющие шаблонные операции, и обладающие унифицированными привилегиями.

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

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

Средства управления

  • reuseSessions – аналог свойства ПовторноеИспользованиеСеансов, может принимать значения autouse, use и dontuse;
  • sessionMaxAge - аналог свойства ВремяЖизниСеанса;
  • poolTimeout - используется при автоматическом управлении сеансами, содержит время ожидания доступности сеанса;
  • poolSize - используется при автоматическом управлении сеансами, содержит максимальное количество сеансов, которое может быть создано в пуле.

Например, файл default.vrd может выглядеть так:

Автоматическое переиспользование сеансов

Сеансы в пуле хранятся в разрезе типа сервиса, наименования сервиса, пользователя/пароля, значений разделителей и безопасного режима. Причём в пуле может быть несколько сеансов с одинаковыми значениями перечисленных реквизитов.

При вызове платформа проверяет, есть ли простаивающий сеанс с подходящим сочетанием этих реквизитов. Если такой сеанс есть, то он выделяется для обработки вызова. Если такого сеанса нет, то создается новый сеанс и выделяется для обработки.

Сеанс автоматически завершается по истечении периода бездействия (ВремяЖизниСеанса).

Если достигнуто максимальное количество сеансов (poolSize), то вызов ждет указное время (poolTimeout). Если за это время подходящий сеанс не освободился, то возвращается ошибка со статусом 406 Not Acceptable.

Настройки автоматического пула сеансов действуют в рамках публикации. Это значит, что если у вас есть несколько публикаций для одной и той же информационной базы, то при вызове действуют те параметры, которые указаны в публикации, к которой обращается текущий вызов. Таким образом, если в одной публикации для сервиса указан лимит в 3 сеанса, а в другой публикации 5, то общее количество сеансов, которое может быть создано для вашей информационной базы равняется сумме этих значений 8.

При выборе размера пула следует учитывать все разрезы, в которых хранятся сеансы в пуле. Мы рекомендуем устанавливать размер пула немного больше, чем количество возможных вариантов. Это позволит вам избежать ситуации, когда пул заполнен сеансами, и вызов с новой комбинацией разделителей/пользователей обработан быть не может.

Эта стратегия не подходит для сценариев, в которых нужно использовать сохранённое состояние сеанса на сервере. Потому что нет никакой гарантии, что при следующем вызове клиент будет подключен к тому же самому сеансу. Как мы говорили в начале, в пуле может быть несколько сеансов с одинаковыми значениями ключевых реквизитов.

Управление сеансами

После получения такого заголовка на сервере стартует сеанс информационной базы, происходит аутентификация, установка разделителей и вызывается обработчик УстановкаПараметровСеанса().

Для подключения ранее созданного сеанса, вам необходимо указать куки IBSession с идентификатором сеанса.

Эта стратегия позволяет вам реализовать сценарии, в которых используется состояние сеанса, сохранённое на сервере. Потому что вы имеете уникальный идентификатор сеанса. Единственное, о чём нужно помнить, что завершение сеанса может происходить не только по вашей «команде», но и автоматически. В том случае, когда превышен период бездействия сеанса (ВремяЖизниСеанса). Поэтому вы, как клиент сервиса, должны быть готовы к тому, что сеансовые данные могут быть сброшены, если сеанс завершен.

Веб-сервисы в расширениях

В дальнейшем мы будем рассматривать возможность поддержки этих свойств в расширениях.

Возможные решения

1. Проверка даты/времени на ПК

Проверьте корректность через «Панель управления — Часы и регион — Дата и время». Отправьте команду на автоматическую синхронизацию, если вы соединены с сетью Интернет.

2. Проверка доступности

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

Если адрес не открывается — другие распространенные причины:
• доступ заблокирован через файл hosts;
• нет доступа из-за прокси-сервера;
• ресурс блокирован firewall/антивирусом.

3. Отключение проверок

Список ИБ — Выбор базы — Изменить… — Дополнительно… — Далее >
Выберите клиентский сертификат: Не предоставлять
Выберите способ проверки сертификата сервера: Не проверять


Не проверять сертификат сервера

4. Игнорирование ошибки проверки отзыва

В конфигурацию платформы — в файл conf с расширением cfg — добавьте следующую опцию:

Расположение файла:
• C:\Program Files\1cv8\8.х.хх.хххх\bin\conf
• C:\Program Files (x86)\1cv8\8.х.хх.хххх\bin\conf

Данный механизм игнорирует именно ошибки проверки отзыва, а не отменяет проверку отзыва сертификата. Поэтому, если сертификат сервера отозван и это подтверждено, то соединение с таким сервером установлено не будет.

5. Импорт самоподписанного сертификата

Добавьте сертификат сервера на ПК, с которого вы подключаетесь, в список «Локальный компьютер — Доверенные корневые центры сертификации — Сертификаты».

В этом случае поставьте режим «Выберите способ проверки сертификата сервера = Хранилище сертификатов Windows». Или укажите файл сертификатов CA — как удобнее.

6. Диагностика ошибок

Используйте методические рекомендации по диагностике ошибок ОС Windows из официальной статьи 1С.

Если окружение настроено корректно и есть доверие к сертификату удаленного ресурса, то ошибки не будет. Пусть все получится. 🤗

Читайте также: