Есть база 1С на Postgres. В конфигурации имеется http-сервис обрабатывающий запросы с мобильных телефонов. Данный http-сервис является как бы ретранслятором, т.е. при получении http-запроса, выполняются http-запросы к другим ресурсам и просто пересылается ответ. Получается, что самих вычислений как бы и нет никаких, просто пересылка запросов и возврат ответов, т.е. скорость ответа на прямую зависит от того с какой скоростью ответил конечный http-ресурс. Так вот один такой запрос внутри http-сервиса длится от 0,5, до 1,5 секунды. Количество запросов к нашему http-сервису около 90 в минуту, т.е. как я понял, собирается не хилая очередь запросов, т.к. 1С, как я понял, выполняет эти запросы как бы не совсем параллельно, а есть какая-то очередь/пул и на практике пользователь телефона ожидает ответ около минуты. Почитал эту статью Повышение производительности веб-сервисов. Пришел к выводу для увеличения ответа конечному пользователю, в моем случае в метаданных, у сервиса, нужно выставить свойство ПовторноеИспользованиеСеансов в значение ИспользоватьАвтоматически, а также в vrd файле увеличил значение poolSize с 10 до 50 и poolTimeout с 5 до 20. И после перезапуска все как бы зашевелилось, на телефонах стали получать ответ за 5-8 секунд, но постепенно это время растет и растет, и через пол часа работы опять ждут около минуты. После перезапуска Apache, и завершения всех сеансов через консоль кластера, опять начинает все быстро работать с постепенным падением производительности. Может кто нибудь порекомендовать как правильно повышать производительность http-сервисов? Или где более развернуто можно почитать про оптимизацию http-сервис 1С? Или подсказать из-за чего может происходить постепенное падение производительности? Причем замеры скорости ответа на запросы внутри самого сервиса остаются не изменными - от 0,5 до 1,5 секунды, но почему конечный пользователь так долго получает ответ? Или мне размер пула нужно увеличить до размера количества входящих запросов в секунду? Или что где можно подкрутить? Как правильно на практике выставлять значения poolSize и poolTimeout?
---
Но как только перезапускаешь службу Апача, все начинает летать минут 5-10, мотом опять постепенно уходит в небытие. В итоге помог переход на IIS - все заработало из коробки, не потребовалось вообще ничего настраивать, никаких тебе там размеров пула и таймаутов. В итоге все работает с самого утра и до вечера без единого сбоя и деградации производительности. Короче либо Апач сам по себе ГАМНО, что мало вероятно, либо 1С лучше работает с IIS если передаются большие объемы данных.
---
наводящие вопросы:
лицензии освобождаются?
память не утекает?
---
Лицензии освобождаются, память не утекает. Сейчас увеличил пул до 200 соединений, уже несколько часов вроде норм, выдает в пределах 3 сек. Посмотрим, что будет завтра. И все таки исходя из чего на практике выставлять значения poolSize и poolTimeout?
---
к сожалению пока опыт = 0
все опыты и внедрение перенесены на осень
так что пока придется пользоваться методом научного тыка
---
Короче увеличение размера пула соединений тоже оказалось полной херней. Чуток поработало и опять тормозит, доходит до того, что запросы вообще не доходят до http-сервиса, при это клиент как буд-то что то там грузит или ждет ответа, т.е. запросы ваще висели в подвешенном состоянии и ни ошибок ни http-ответов получить не удавалось
---
Но как только перезапускаешь службу Апача, все начинает летать минут 5-10, мотом опять постепенно уходит в небытие. В итоге помог переход на IIS - все заработало из коробки, не потребовалось вообще ничего настраивать, никаких тебе там размеров пула и таймаутов. В итоге все работает с самого утра и до вечера без единого сбоя и деградации производительности. Короче либо Апач сам по себе ГАМНО, что мало вероятно, либо 1С лучше работает с IIS если передаются большие объемы данных.