3000 пользователей на трехъядерном Athlon – сверхтонкий веб-клиент для 1С

Здравствуйте, коллеги. Вот уже второй год я рассказываю вам о том, как можно интегрировать 1С с сайтами в режиме онлайн. В своем прошлогоднем докладе я говорил о том, как можно делать красивые, удобные интерфейсы для работы с 1С через обычный браузер, но особого интереса это не вызвало. Люди посмотрели на это и сказали: «Да, классно, красиво, здорово, вы такую супер-работу проделали, но только ради чего? Мы не согласны ради интерфейса со всем этим мучиться».

Поэтому сегодня я вам расскажу, как можно значительно ускорить работу 1С, используя нестандартные подходы – а именно, http-сервисы.

Основные причины замедления работы 1С

Стандартные причины замедления работы 1С известны всем:

• Размер конфигураций возрастает
• Объем обрабатываемых данных увеличивается
• Количество пользователей растет
• Инфраструктура устаревает

Я на этом останавливаться не буду. Я расскажу о том, как мы смогли минимизировать влияние этих причин и достигли ускорения с помощью http-сервисов.

Проблемой интеграции 1С с сайтами я занимаюсь уже давно, с 2008 года. Раньше это было просто хобби – я выполнял проекты на заказ, и время от времени мне за это даже платили деньги. С тех пор прошло уже 9 лет, но некоторые из моих разработок до сих пор вполне нормально функционируют.

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

Мы попросили наших потенциальных заказчиков сформулировать, что их не устраивает, какие конкретно задачи они хотят автоматизировать, и выделили из них основные.

Например, у клиентов есть сотрудники, которые системой почти не пользуются – они утром входят в систему и раз в час выполняют какое-то одно действие. Всего за восемь часов рабочего дня они делают восемь действий, а сеанс висит весь рабочий день и отъедает на сервере память. И таких сеансов у них висит 500 штук. А хотелось бы, чтобы сеанс пользователя задействовал сервер только тогда, когда выполняются какие-то действия, а не висел весь день и не отъедал ресурсы сервера.

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

Третий вариант. У нас есть компания-заказчик с огромной армией выездных инженеров, которые для получения заявок используют планшеты. Инженер просматривает список заявок через обычный почтовик, кликает ссылку, получает доступ к приложению, отображающему суть заявки. Там он должен нажать на кнопочку: «Да, я принял к исполнению, сделаю тогда-то». Потом он должен приехать к клиенту, отработать заявку, сфотографировать результат и отправить уведомление о том, что работа выполнена. Таких инженеров у них 700 человек. И разработчик, который все это автоматизировал на стандартном мобильном приложении от 1С, сказал мне: «Я вчера собрал приложение под Android – все здорово, работает, я проверил. А сегодня мой Android обновил систему, и приложение больше не работает, его надо заново пересобирать. У нас 700 пользователей, у всех огромный зоопарк операционных систем, под каждую из которых нужно держать актуальную версию мобильного приложения.

Мы не хотим под каждого пересобирать приложение индивидуально. Сможет ли ваша система стабильно работать на различных устройствах?». Мы сказали: «Да, сможет». «А сколько пользователей она потянет? Наших 700 инженеров потянет?». И другой клиент тоже спрашивает: «А наших 1000 заказчиков она потянет? Будет ли ваша система работать быстрее, чем стандартный веб-клиент?».

Мы сказали: «Да, будет работать быстрее». И чтобы подтвердить свои слова, решили произвести тестирование и поэкспериментировать с веб-сервисами 1С.

Веб-сервисы как способ ускориться на порядок

Основание для того, чтобы утверждать, что будет работать быстрее, у нас было, потому что когда-то мы уже проверяли свою систему на скорость открытия формы документа.

Напомню, в своем прошлогоднем докладе я уже рассказывал про наше решение на http-сервисах, которое называется «Интерфейс дилера» – оптовики заходят на сайт, делают заявки в режиме онлайн, и эти заявки сразу же попадают в 1С.

Это решение интегрировано с типовой конфигурацией, где есть форма документа «Заказ клиента». В обычном тонком клиенте эта форма открывается за 0,45 секунды (мы открывали ее несколько раз и замеряли среднее время открытия, чтобы никто не мог сказать, что на скорость открытия влияет актуальность кэша).

В веб-клиенте эта же форма открывается за 0,65 секунды.

Почему дольше, чем в тонком? Потому что стандартный веб-клиент от 1С – это обычные HTML, CSS и JavaScript. И весь код, который находится внутри формы, платформа транслирует в JavaScript. Это достаточно трудоемко. Фирма «1С» и ее разработчики сделали огромную работу, они смогли поместить всю функциональность 1С в JavaScript. Мне тяжело представить, насколько это было трудно, но они это сделали.

А в нашем «сверхтонком» клиенте форма заказа покупателя открывается за 0,25 секунды. Мы назвали его «сверхтонким», чтобы не путать со стандартным веб-клиентом 1С – в нем есть только необходимый функционал и ничего «лишнего».

Итого, наш сверхтонкий клиент в 1,8 раз быстрее тонкого клиента и в 2,6 раз быстрее веб-клиента. Это уже достаточно серьезное ускорение.

За счет чего мы его достигаем?

Всем известно, что в форме есть три контекста выполнения кода:

• код, который выполняется только на клиенте;
• код, который выполняется на сервере без контекста;
• и код, который выполняется на сервере с контекстом (так называемые контекстные вызовы).

Фирма «1С» призывает: «Если вы можете сделать неконтекстный вызов, делайте неконтекстный вызов». Это не просто так.

Дело в том, что форма – это некие данные, которые были сформированы на сервере, упакованы в структуру и отправлены на клиент. Там они отобразились в виде каких-то полей реквизитов, табличных частей. Пользователь с этими данными работает, наполняет их значениями, и обрабатываемый им объем данных становится относительно большим. Когда программист делает контекстный вызов (например, хочет вызвать серверную функцию, которая вернет текущую дату), все данные, которые содержатся в форме, собираются, упаковываются в структуру и отправляются на сервер. Время тратится как на сборку структуры, так и на то, чтобы отправить это серверу. После этого на сервере создается некий образ формы – на все это тратится место, время и т.д. В итоге простейшая операция типа «получить текущую дату» превращается в целое событие.

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

• Все, что раньше выполнялось на сервере – модули форм, объектов, общие модули – все осталось без изменений.
• Все, что ранее было доступно на клиенте, мы переделали в HTML, таблицы стилей и JavaScript.
• А вот от контекстных вызовов мы отказались.

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

Что было сделано в итоге:

• Мы отказались от контекста форм на сервере;
• Сервер мы нагружаем только на время выполнения запроса;
• Уменьшили время выполнения каждого запроса;
• И постарались уменьшить количество запросов к 1С в принципе.

Получился интересный результат. Сейчас я расскажу, какое конкретно ускорение мы получили.

Какого ускорения можно достичь за счет использования веб-сервисов 1С?

На слайде показаны параметры нашего тестового стенда. Это – тот самый «динозавр», который упоминается в теме доклада.

У меня спрашивали, что такое трехъядерный Athlon, и как на процессоре может быть нечетное количество ядер. Рассказываю. Компания делает процессор, начинает его тестировать, оказывается, что одно ядро «сбоит», они его «лочат» на программном уровне, получают вот такой непонятный, «кастрированный» процессор и продают его за полцены.

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

Единственное их отличие от обычной десктопной машины в том, что мы туда поставили быстродействующий винчестер VelociRaptor на 10 000 оборотов – заметьте, это даже не SSD – и начали на нем проверять.

Для проверки мы использовали конфигурацию «1С:ITIL КОРП, версии 1.1». У нас для нее был уже разработан веб-интерфейс «Личный кабинет инициатора». Те, кто работал с ITIL, наверное, знают, что там есть обработка, которая называется «Личный кабинет инициатора». Человек может зайти в базу 1С удаленно, оставить заявку, посмотреть результаты выполнения, закрыть и т.д. У нас для этой обработки был реализован веб-интерфейс.

Для проверки производительности нашей системы мы написали тест, эмулирующий работу с этой обработкой по следующему сценарию:

• Пользователь открывает в веб-клиенте список своих заявок.
• Добавляет новую заявку.
• Выбирает важность, срочность, может указать место, где случился инцидент.
• И потом размещает эту заявку – в результате в 1С создается один новый документ «Обращение».

Всего за время выполнения этих действий выполняется 23 запроса к 1С (22 из них на чтение, 1 на запись).

Этот сценарий мы выбрали, потому что заказчик у нас спросил: «Сколько при таком сценарии работы сможет одновременно работать пользователей?». Он сказал, что пользователей у них много, они делают примерно по одной заявке каждые полчаса, т. е. это действие будет выполняться одним пользователем каждые 30 минут.

Выполнение одного цикла нашего сценария теста длится 1 минуту 7 секунд. Всего наш тест длился 11 часов. За это время должно было быть выполнено 1 422 780 запросов к 1С (полтора миллиона запросов), что является довольно серьезной нагрузкой.

На слайде показаны этапы выполнения теста:

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

Проверяли мы это на одном и том же сервере, но с разным софтом.

Изначально стоял 32-битный Apache и платформа старше 8.3.9.1919 в файловом варианте. Почему именно такая версия платформы? Те, кто читают «Зазеркалье» от 1С, знают, что именно в этой версии платформы было анонсировано ускорение работы с веб-сервисами. Нам было интересно посмотреть, как этот механизм будет работать на новой версии платформы при использовании оптимизированных запросов. Те первые результаты, которые мы получили, были очень печальными. При нагрузочном тестировании на этом варианте мы увидели, что у нас отлично работают целых 6 пользователей. Не 6000, не 60, а 6. Как только заходил 7-ой, система начинала «лагать».

Нас это расстроило, поэтому мы попробовали поставить SQL. Обрадовались, потому что ускорение было в целых 5 раз, т. е. теперь стало замечательно работать 30 пользователей. «Шикарно, – подумали мы, – можно все выкидывать в утиль. Столько лет работы ради 30 пользователей».

Потом попробовали поставить 64-битный Apache и платформу 8.3.10. И результаты нас порадовали. На слайде можно отследить некую линейную зависимость: от 6 до 3000 пользователей, причем эти 3000 пользователей работали одновременно, не мешая друг другу.

Настолько быстрый результат для платформы 8.3.10 мы получили за счет того, что при использовании сеансов уже используется многопоточность и много разных других «вкусностей».

Обратите внимание, что вам для этого не надо прилагать никаких усилий – вы просто апгрейдите свою систему, ставите 64-битный Apache и нормальную версию платформы, и у вас все начинает работать на порядки быстрее.

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

Тест мы делали в несколько этапов.

• Сначала запустили его на тысячу пользователей;
• А потом добавляли туда еще по тысяче, и смотрели, на скольких она «упадет».

Смотрите, как интересно – этот трехядерный «динозавр» при тысяче одновременно работающих пользователей показал загрузку процессора на уровне 47%. А винчестер и сеть тут вообще практически не заняты. Мы подумали: «Ничего себе! Если у нас так классно работает на тысяче пользователей, то мы туда еще подкинем».

Обратите внимание, мы запустили на сервер 1000 пользователей, а на сервере 1С у нас создано всего 5 сеансов, т.е. за счет переиспользования сеансов один сеанс обеспечивает работу 200 подключений, и все они друг друга не замечают – шикарно.

В итоге мы довели количество пользователей до 3000 и замерили показатели:

• Общее время выполнения тестов – 11 часов;
• В результате выполнения была создана 61 тыс.  новых документов,
• Среднее время выполнения одного запроса составило 0,327 секунд,
• При этом процессор был занят на 75%.

Обратите внимание, что при 1000 пользователей процессор был занят на 47%, а при 3000 – на 75%. Несерьезное увеличение.

Мы подумали, что у нас появился «вечный» сервер – как его ни нагружай, он все равно будет работать.

Но потом мы запустили четвертую тысячу пользователей.

На слайде показан график среднего времени выполнения запроса. Если посмотреть внимательно, то за две тысячи пользователей произошло незначительное увеличение времени запроса – примерно на 12% (с 300 мсек до 327 мсек). То есть, каждая тысяча пользователей добавляет 6% увеличения времени выполнения запроса.

Но потом мы запустили четвертую тысячу пользователей и были шокированы. Как только мы достигли определенного предела, все моментально «упало». Мы, конечно, сразу выгнали эту 4-ую тысячу, но это не помогло, потому что пошел какой-то всплеск нагрузки, потом еще один.

Я когда-то изучал тему пробок на дорогах – они тоже распространяются волнами: быстро нарастают, а потом никак не могут рассосаться. Мы эту 4-ую тысячу выгоняли примерно час и не могли нормализовать ситуацию.

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

Например, может оказаться, что сервер смог вытянуть 3000, а 3001 он уже не потянет. До этого тянул 3000, и все было хорошо, но, если вы нагрузите его лишним, то на 3001 он «упадет» со всеми вместе.

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

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

Нам удалось увеличить производительность путем интеграции с сайтом.

На слайде показан «Интерфейс дилера». Здесь находятся два независимых списка – слева дерево групп товаров, и при нажатии на каждую группу справа отображаются товары, которые в ней находятся.

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

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

Мы исключили лишние запросы к 1С. Даже если таких запросов будет 5-10%, их исключение будет способно спасти вашу систему и избавить ее от «падения». Даже лишние пара процентов может оказать существенное влияние на то, что система «упадет».

Кроме этого, есть еще много других хитростей, которые позволяют уменьшить время выполнения запросов или избавиться от них совсем. Мы даже разработали вот такую «страшную» схему.

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

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

Поэтому мы сделали «высший пилотаж» – разделили одну базу на две.

На слайде тот самый «Интерфейс дилера», который состоит из двух частей.

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

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

Схема примерно такая: есть две базы 1С – основная и зеркало.

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

Таким образом, нам удалось сэкономить даже больше, чем 10% времени и думаю, что 3000 – это совсем не предел. Просто этот результат нас удовлетворил. Нас просили сделать так, чтобы на нашем железе могли работать хотя бы 700 пользователей. У клиента железо намного круче, чем наш трехъядерный Athlon. Но, поскольку нам удалось достичь хорошего результата, мы не стали переносить это на более мощный сервер, и посчитали эту задачу выполненной. Клиент согласился. Сейчас делаем внедрение.

Дополнительные плюсы сверхтонкого веб-клиента

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

• Во-первых, безопасность.
• Во-вторых, кроссплатформенность, т. е. теперь не надо заботиться о том, что у вас в одном месте iOS, а в другом Android. У вас только браузер, и информация обновляется с сервера моментально.
• В-третьих, универсальные интерфейсы на мобильных устройствах и десктопах.
• Вы можете делать произвольный интерфейс, вам не нужно заботиться о том, что его вид отличается от интерфейса основного сайта – вся стилистика интерфейса, берущегося из 1С, будет соответствовать стилистике вашего сайта.

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 COMMUNITY. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.