Высоконагруженные веб-сервисы 1С - скорость работы #735585

Есть база на PostgreSQL, веб-сервер Apache, опубликован к примеру простейший веб-сервис (чтобы не отвлекаться на обсуждение кода методов, структуры базы и т.д), отдает данные типа 10 строк "Код-наименование". Этот запрос в самом методе веб-сервиса и упаковка в пакет XDTO происходит так - в общем тестируя через SoapUI получаем цифру 77-88 миллисекунд на ответ. Но вот проблема - если делать нагрузочный тест, к примеру, кол-во запросов за секунду - то я могу получить всего 180 таких запросов , что очень мало. Во время этого теста проц на сервере 1С загружен на 100%, все остальное вроде не загружено. Вопрос - где читать, выяснять, что нужно в первую очередь настроить или прикупить м.б (железо?), чтобы увеличить количество запросов, которое может обработать сервер? Или нужно стремиться ускорить выполнение одного запроса?

запросы шлешь последовательно? и реально так будет в жизни? Попробуй параллельно, с разных машин, и смотри как распараллеливается запрос в 1С - должно быть много сеансов. если не хватает - добавляй сеансы - RTFM

Шлю через SoapUI пакет запросов, с разрывом в 1-5 миллисекунд каждый. Сеансов дофига в 1С.

если есть бюджет, то ответ очевиден -

дофига это сколько? добавь в ответ информацию о текущем сеансе. Посмотри статистику, сколько реально сеансов работает.

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

>>>77-88 миллисекунд на ответ. это примерно 1 сек на ответ, по моему ответ очевиден - надо сокразать время на ответы.... хотя-бы, до 0.1 сек.... >>>кол-во запросов за секунду - то я могу получить всего 180 таких запросов то есть ты имеешь примерно 150 конектов в секуунду... проблемма в том, что 1с сеанс поднимает долго, я-бы пошел путем поднятия например 100 сеансов и поодержка их в открытом состоянии через всякие кеши, а замеры производил с второй, третей секунды, ибо первая секунда - это инициализация сеансов...

кстати я делал похожую систему, только связь апач-1с я делал через ком, держал в переменных 10 открытых ком соединений... и текущие запросы в апаче определял в уже открытые ком обьекты, правда там с правами заморочка, я делал доп параметры в 1с для каждого запроса отдельные права через прарамтры функции делал... писал на asp

Нет, в 1 секунде 1000 миллисекунд, 77 мс это 0.07 секунд. Поднять 100 сеансов и поддерживать не вариант - проверяется именно количество различных пользователей, которые коннектятся к базе. Если делаю например 2 секунды то получаю всего 280-300 запросов.

Железки-то какие?

10 соединений - этого хватало? Почему не 100 соединений? Железо Xeon 2.4 2 проца , 12 гб памяти, ОС 64 бит.

у тебя есть ID сеанса апача, его передаешь в виде параметра в функцию, по этому ID в 1с определяешь пользователя и его права... хотя конечно практика может все мои слова опровергнуть...

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

у меня было не на столько нагружено... у меня одновременоо 20-30 потоков было всего, мне хватало за глаза и одного сома... но делал на преспективу которая не случилась...

Например результат 173 ответа - в 1С в регистре логов вижу те же 173 сеанса - в чем смысл?

Запрос пустой совсем. "Выбрать Таб.Наименование, Таб.Код из Справочник.ИмяСпр". И все. Платформа 8.2.14.528.

Где почитать про "Держать несколько веб-расширений, выделить под них отдельный сервер в кластере"?

Подожди - что-то я запутался - у меня же SOAP веб-сервисы, причем тут веб-расширения?

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

Особой разницы нет, судя по тесту. Если 100 сеансов пуляю одновременно или например 40 сеансов (которые могут не по одному разу успеть пульнуть запрос) - примерно 160-200 запросов за секунду отрабатывает и там, и там.

Какой процесс грузит до 100%? Схему можно масштабировать поставив два апача, а перед ними балансировщик.

Postgre грузит.

Ошибся - Rphost конечно же.

ну тут ответ очевиден - уперлись же в железо

Для многих случаев можно для вэб сервисов просто упростить УстановкаПараметровСеанса

Пример схемы с балансировщиком в вашем случае каждый апач должен обращаться к отдельному серверу приложений, если затык в rphost

Помогло немножко совсем. 0.1 сек. выиграл вроде.

а еще можно заюзать вместо вебсервисов http-сервисы. по крайней мере будет контроль над объемом сериализации.

+ вплоть до полного её отсутствия

отклик даже на такой метод - уже 0.086 сек; установку параметров сеанса отключил.

а на http сервис сколько задержка?

веб сервер кэширует соединение с 1с, так что последовательные запросы новый коннект не поднимают

У нас 8.2.14... , поэтому HTTP к сожалению нет

Проверил на 8.3 (поставил файловую базу) - пустой запрос примерно 20 миллисекунд идет, на SOAP тот же пустой запрос 0.7 - 0.8 миллисекунд! Не знаю, как на серверной 8.3 будет себя вести - подозреваю, что также.

Ошибка - В SOAP 70-80 миллисекунд, в HTTP - до 20 миллисекунд

А если нагрузить http? Может там и нагрузка на процессор меньше при большом количестве обращений?

5 apache и haproxy с балансировкой robinbobin.

Да, хочу нагрузить его, но вот проблема - у нас 8.2 стоит серверная, а на 8.3 лицухи на сервер нету. Вчера вечером-ночьюпробовал поставить агент 8.3 на другой порт - не работал - пишет что нет серверной лицензии. Попробовал тогда отключи агент 8.2, включить 8.3 на стандартном 1541 порту, лицензию нашел но базу не создавал (видимо что-то еще недоставил, а рушить все, удаляя текущий агент сервера - не могу - люди же работают). Удалось только в файловом варианте развернуть 8.3 и нагружить http - но там печаль - никакой параллельности вообще, вроде, читал, что в файловой параллельности нет совсем. Добавил 6 или 8 рабочих процессов на сервер 1С - в результате процы стали немного больше загружены при массовой нагрузке "тяжелыми" запросами (легкие запросы полностью грузили сервер  и при одном раб.процессе)

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

Велика вероятность, что для 8.3 придется лицензировать заново. Механизмы лицензирования допиливались и что-то может не совпасть. Мне при переходе с 8.2 на 8.3 на том же железе пришлось генерить лицензии заново.

Если отключить агент 8.2 и включить тупо 8.3 на том же порту, как я сделал - он нашел лицензии, но базу не смог создать (видимо не доделал я что-то - а удалять рабочие настройки и агента сервера и консоль 8.2 не стал, т.к сервер-то рабочий).

1. 8.3. запусти на другом порту. 2. поставь сервер 1с на линухе и соедини их добавив к виндовому серверу 8.3 еще один сервер по ip. 3. в ролях для виндового сервера добавь только роль "Лицензирование", а остальные запрети. Для линуксового все разрешить.

Вообще, интересная ветка. Ежу было понятно, что 1С по определению не годится для публичных сервисов. Только для приватных порталов. Но результаты реальных тестов - это уже конкретная информация. И я не знаю, как это удалось разработчикам 1С, но давно уже в тестах замечена удивительная тенденция - очень часто узким местом на банальных операциях с СУБД становится не дисковая подсистема (что как бы логично), а процессорные мощности.

Можно, конечно, побыть оптимистом и увидеть причину этого в эффективном кэшировании.

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

Согласен, погорячился. Для общедоступного портала для размещения заказов в компании, где поток заявок заведомо ограничен и хорошо прогнозируем - сгодится вполне. А вот даже просто для хранения данных, доступ к которым может стать резко популярным - уже болт.

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

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

Да, приходится все пихать в пару регистров сведений с примитивными строковыми и числовыми полями. Чтобы быстро считывать это все.

Свой фэйсбук на 1с хочешь написать чтоли?

Да нет конечно - но даже 300-600 запросов в секунду - очень большая проблема получить. И это вроде как считается немного.

последовательных?

параллельность достигается не только за счет уменьшения времени 1 процедуры

Параллельных конечно

но тут уже все от железа зависит

На чем затык в железе?

Процы загружены на 100% (на мелких запросах) и процентов на 60 на средних запросах (пробовал увеличить пул соединений Apache, в Postgre установил тоже макс.кол-во соединений 10000 - особо не помогло. Помогло немного добавление нескольких рабочих процессов к серверу 1С)

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

Интересно, при линейном увеличении количества параллельных запросов, время ответа растёт линейно, не замеряли?

Да нет конечно - но даже 300-600 запросов в секунду - очень большая проблема получить. И это вроде как считается немного. ------------ вам надо юзать sap - с вашей производительностью.

+1 Post-запросы быстрее отрабатывают чем Web-сервисы

и прямые запросы

хотите скорости в данном вопросе, то вам на java. Или что бы все просто и из коробки, то на .net. Net конечно менее гибко и помедленнее, но если проект простой, то меньше времени на кофигурацию потратите

интегрировать сейчас модно через rest full

62+

Можно сгенерить классы для Code First