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

Администрирование - Оптимизация БД (HighLoad)

78
Юрий Лазаренко поделится опытом ускорения 1С нестандартными методами, в том числе с помощью http-сервисов. Он расскажет, как с помощью сверхтонкого клиента для 1С и интеграции с сайтом удалось добиться ускорения 1С на порядок. Также в статье приведена статистика по отчету о нагрузочном тестировании сверхтонкого клиента для 1С:ITIL.

Здравствуйте, коллеги. Вот уже второй год я рассказываю вам о том, как можно интегрировать 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 2017 COMMUNITY.

Приглашаем вас на новую конференцию INFOSTART EVENT 2018 Education.

78

См. также

Комментарии
Сортировка: Древо
1. A1ice1990 110 16.08.18 12:41 Сейчас в теме
Ребят, поверх апача надо кэширующий-редиректящий nginx прикрутить, наверное.
В вебе именно он отвечает за работу со статикой. Возвращает картинки и вот это все.
Что серьезно ускоряет работу и разгружает сервер. Апач2 в этой связке именно для динамики.

Совет актуален именно для http сервисов, Я думал именно про них и будет статья.

Алсо, в догонку вопрос к более опытным коллегам:
есть http сервис с анонимным доступом, всегда первый запрос выполняется жутко долго (как я понимаю поднимается сеанс 1с), можно ли както ускорить это дело или задать время жизни сеанса в разы подольше?

Сам не гуглил еще и итс не смотрел, надеюсь тут подскажут :3
2. TitanLuchs 87 16.08.18 12:48 Сейчас в теме
(1) Картинки и всю подобную статику вообще лучше из 1С не тащить, мы их или кладем на сайт (а там обычно кэширование уже настроено), или, если все-таки возвращаем 1Ской, то кэшируем nginx-ом.

"всегда первый запрос выполняется жутко долго (как я понимаю поднимается сеанс 1с" - да, так и есть. В настройках публикации можно задать переиспользование сеансов и указать время жизни одного сеанса (например, сутки), тогда сеансы будут жить практически "вечно" и сразу подхватят свежевошедших посетителей.
ram3; acanta; A1ice1990; +3 Ответить
3. A1ice1990 110 16.08.18 12:54 Сейчас в теме
(2)
Картинки и всю подобную статику вообще лучше из 1С не тащить, мы их или кладем на сайт (а там обычно кэширование уже настроено), или, если все-таки возвращаем 1Ской, то кэшируем nginx-ом.

Ага, это и имел ввиду.


Большое спасибо за ответ, обязательно посмотрю еще раз.

Алсо, могу поделиться своим кейсом (может потом статью накатаю):

В нашей компании сильно донимают бухгалтера такими вопросами как: "а сколько денег я получу, а что мне причитается за отпуск?".
Все это пользователь мог бы посмотреть и сам, да вот в ЗУП пускать нельзя. Итого: предложил реализовать через http сервис, авторизация через почту.

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

Но такая авторизация (как по мне) довольно геморойная и идея сместилась в сторону OAuth2 гугла (у нас корпоративная почта на гугле), в итоге пользователь:
Открывает URL, гугл предлагает выбрать ему его почту > далее после авторизации одним кликом гугл редиректит на http сервис 1с (в дальнейшем, возможно, это будет отдельный веб-сервер) > 1с'ка возвращает страничку пользователю и дальнейшая авторизация происходит по Google API ключу, который даже хранить в 1с не надо и по дефолту имеет время жизни около 2 часов, что вполне устраивает.
TreeDogNight; creatermc; TitanLuchs; +3 Ответить
4. A1ice1990 110 16.08.18 13:27 Сейчас в теме
Раз уж начал флудить в комментах, поделюсь еще одной задумкой.

Лично меня жутко раздражает URL вида:
http://www.host.ru/Base/hs/api/get

Через проксирующий nginx можно настроить редирект на домены третьего уровня и сделать следующую штуку:

http://api.host.ru/get

Согласитесь, выглядит гораздо симпатичнее :3
5. TitanLuchs 87 16.08.18 13:45 Сейчас в теме
(4) Мы предпочитаем веб-сервисы напрямую в интернет не выставлять. У нас все запросы проходят через промежуточный сайт и 1С принимает запросы только с сайта, а с прочих IP блокирует (точнее, это делает не 1С, а файерволы и прочие аппаратно-программные штуки). Таким образом повышаем уровень безопасности. Получается и УРЛ красивый, и защита от кахеров.
6. A1ice1990 110 16.08.18 14:09 Сейчас в теме
(5) Ну так красивый url внутри сети можно сделать через Static DNS на роутере.

Допустим у вас "ООО Рога и копыта", прописываете "rk.ru" на роутере ссылающимся на какойнить вебсервак на лине 192.168.1.1, а с него запрос к 1s.rk.ru nginx'ом перекидываете уже на 192.168.1.2 iis с 1с'ом.

Причем это физически может быть одна и таже машина, если эти операционки на ней поднять через ESXi.

По моему вполне красивая схема и за домен платить не надо)



Про невыставлять в интернет корпоративное - полностью согласен, сам параноик, доступ только через VPN)
Только личный сервер смотрит мордой в нет и в тор.
creatermc; TitanLuchs; +2 Ответить
7. TitanLuchs 87 16.08.18 14:16 Сейчас в теме
(6) Да, для использования внутри норм.
8. starik-2005 1402 16.08.18 18:36 Сейчас в теме
По поводу хранения "промежуточных" данных в MySQL, то это вряд ли может привести к существенному росту производительности, а вот использовать для этого memcache или Redis - да, очень практично. С учетом того. что последний на моем Ryzen 1600 выполнял 2 100 000 GET-запросов в секунду, что уже даст вам этак в сто раз количество пользователей увеличить )))
iliabvf; TitanLuchs; +2 Ответить
11. TitanLuchs 87 16.08.18 21:48 Сейчас в теме
(8) Согласен. Пока с такими технологиями не экспериментировали из-за отсутствия спроса.
12. starik-2005 1402 17.08.18 10:02 Сейчас в теме
(11) чем хорош Redis - так это тем, что у него есть каналы и подписка. А плоховат он пока стабтльной работой, но это вполне решается. Также у него, как и у прочих кешеров, есть время жизни ключа, т.е. можно указать, сколько тот или иной ключ проживет (например, 10 минут), и в ORM-модели обращаться сначала к кешеру, а если там ничего нет - к базе данных.

Также в этом контексте можно рассмотреть апачевскую очередь Kafka - ее можно встретить даже в решениях HyperLedger - блокчейн-платформы уровня энтерпрайз, активно поддерживаемой сообществом, в которое входят конторы от SAP до IBM.

А MySQL - это просто замена одной реляционной базы на другую, к которой чуть быстрее будет организован доступ.
13. TitanLuchs 87 17.08.18 10:08 Сейчас в теме
(12) Промежуточная база в данном случае используется для уменьшения количества запросов к 1С, поэтому даже MySQL это уже вполне рабочий способ если не ускориться, то повысить количество одновременно работающих пользователей. Но работа с оперативной памятью - безусловно более правильное решение.
9. BackinSoda 16.08.18 20:11 Сейчас в теме
База СашиГрей детектед :D
10. TitanLuchs 87 16.08.18 21:42 Сейчас в теме
(9) Собственно так она у нас и зовется. А "гатлинги" - это генераторы запросов, в каждом по 1000 пользователей.
Прикрепленные файлы:
TreeDogNight; ice-net; Gang031; nazirovramzil; +4 Ответить
14. BigB 172 21.08.18 12:54 Сейчас в теме
У Вас есть 3000 лицензий на 1С?
15. monkbest 97 22.08.18 08:10 Сейчас в теме
(14) а зачем? соединений с 1С у них 5 штук на 1000 пользователей
16. Ndochp 101 22.08.18 09:28 Сейчас в теме
(15)А почитайте внимательнее вопросы-ответы по лицензиям.
Например, при 100 пользователях 1С к MSSQL идет вообще одно соединение - от сервера 1С. А лицензий нужно все равно 100. С 1С та же тема.
Другое дело, что такое одновременно, а что последовательно работающие пользователи в условиях, когда они сидят не в клиенте 1С, а в морде сайта и периодически дергают веб сервисы - это большой вопрос. Лицензий должно быть столько, сколько одновременных пользователей.
18. monkbest 97 22.08.18 10:56 Сейчас в теме
(16) не знаю, очень тонкий вопрос. Думаю в случае суда у 1С нет шансов:
1. Как вы заметили речь об одновременных пользователях
2. Речь о пользователях 1С, а тут они пользователи сайта и данные из 1С берут не всегда. то что в кэше сайт отдает сходу без соединения.
19. Ndochp 101 22.08.18 14:26 Сейчас в теме
(18) Как думаете, а у MS есть? Зачем куча клиентских лицензий к скулю и прочих бандлов 1С+SQL? одна пользовательская для сервера 1С + 1 серверная.
25. monkbest 97 22.08.18 19:11 Сейчас в теме
(19) надо прочесть пользовательское соглашение MSSQL. В 1Сном соглашении на эту тему нет однозначного ответа, есть комментарии 1С на этот счет.
20. TitanLuchs 87 22.08.18 14:32 Сейчас в теме
(14) В данном конкретном случае - эмуляция работы 3000 пользователей - 3000 лицензий не требуется, так как в качестве клиента выступает один генератор запросов, а не реальные пользователи.
17. Дуб 69 22.08.18 09:29 Сейчас в теме
По сабжу: я проглядел, а где сам продукт?
По кешированию на клиенте: по каким событиям обновляется кеш? Какие механизмы используются? Что с кроссбраузерностью?
Что с подключением торгового оборудования?
21. TitanLuchs 87 22.08.18 14:47 Сейчас в теме
(17) Примеры решений на основе данного продукта можно посмотреть здесь: https://digitcat.ru/demo/
Рассматриваемый в статье ITIL там тоже есть. В действительности решений больше, но мы можем показать далеко не все, так как большинство из них делается на заказ и не каждый заказчик согласен выставлять свои веб-интерфейсы в качестве примера на всеобщее обозрение.

Кэш обновляется в зависимости от логики данного конкретного решения. В показанных на демостранице решениях кэш не используется. Вообще редко когда приходится его использовать, я рассказал о нем в статье чтобы потенциальные заказчики были в курсе, что такое в принципе возможно. Механизмы можно использовать любые: localstorage, websql на клиенте, промежуточную БД или как писали выше memcache на сервере, и т.д.

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

Торговое оборудование не подключали - таких заказов пока не было. Но все, что может работать через веб-клиент, точно сможем подключить. Если интересует возможность подключения какого-то конкретного оборудования, напишите тип и модель, я смогу ответить точно, насколько это реально. Но если что-то не получится подружить с браузером средствами js, то всегда есть java, а с ее помощью можно сделать все.
22. DonAlPatino 28 22.08.18 17:11 Сейчас в теме
Я правильно понял, что система тестировалась на Win2008R2+ Apache 2.4 64 bit? А на штатный IIS не пробовали? И/или Linux вместо Windows? Интересует как это на общую производительность могло бы повлиять...
23. TitanLuchs 87 22.08.18 18:03 Сейчас в теме
(22) Да, Win2008R2+ Apache 2.4 64 bit, таковы были требования от заказчика. Поскольку согласно требований надо было убедиться, что система не умрет на 700 пользователях, то при достижении цифры 3000 дальнейшие тесты прекратили. Насчет IIS и Линукса самим интересно, какие будут цифры, но подготовка и проведение такого теста занимает пару дней, а у нас сейчас нет столько рабочего времени в запасе.
24. TitanLuchs 87 22.08.18 18:07 Сейчас в теме
(22) Могу сказать, что проведение подобного теста на Xeon с 192 Гб оперативы, SSD и Win 2012 на борту показала результат в 5 раз лучше. То есть, при тех же условиях это было бы уже 15000 пользователей.
26. СергейК 51 23.08.18 08:25 Сейчас в теме
(24) Что-то не нашел какой SQL использовали. Сравнивали MS и Postgres?
27. TitanLuchs 87 23.08.18 09:30 Сейчас в теме
(26) SQL 2008. С Postgress не сравнивали.
Оставьте свое сообщение