Учимся готовить кроликов с редиской: опыт применения Rabbit MQ и Redis в интеграционных проектах

Публикация № 1234830

Администрирование - Производительность и оптимизация (HighLoad)

При построении мощных производительных отказоустойчивых решений для интеграции во всем мире активно используются технологии обработки очередей сообщений с помощью брокера RabbitMQ и кэш-сервера Redis. О практическом опыте использования этих технологий при построении ИТ-ландшафта, включающего системы на 1С, на конференции Infostart Event 2019 Inception рассказал Сергей Наумов.

Сегодня поговорим про такие замечательные технологии, как «Кролик» и «Редиска», то есть RabbitMQ и Redis Server. Меня вообще очень радует, что наша отрасль начала применять такие промышленные технологии. Спасибо Андрею Овсянкину, который приложил свою руку к тому, что они появились в мире 1С. Также большая благодарность Даниилу Коневу (//cat.1module.ru/profile/597444/) – вместе с ним мы реализовывали те проекты, на примере которых я буду рассказывать про эти технологии.

 

Зачем 1С-нику знать про RabbitMQ и Redis Server?

 

 

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

Во-первых, чтобы не изобретать велосипед. Ко мне периодически приходят с такой проблемой – у нас есть интернет-магазин, есть 1С, интернет-магазин из 1С что-то получает, но периодически падает. Залезаешь в модуль этого web-сервиса, а там запрос на три экрана. Это, конечно, бред – работать это будет плохо, медленно и ожидаемо, что это будет падать.

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

 

 

Сегодня мы поговорим про две технологии:

  • первая – это брокер сообщений RabbitMQ, который организует очереди;
  • и вторая – это Redis, кэш-сервер. Я подробнее расскажу, что это такое, с чем его едят, и как я его применял.

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

 

Первый кейс – сбор лицензионных отчислений правообладателю от упоминания в интернете

 

 

Итак, первый проект. Заказчик этого проекта решил «забанить интернет» – в частности, инстаграм.

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

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

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

 

 

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

 

 

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

И дальше на средней картинке видно, что система еще периодически отсматривает эту публикацию, проверяет – удалил он ее или нет.

 

Первый вариант архитектуры сканирования инстаграма

 

 

Первый вариант архитектуры мы сделали «в лоб» – это система поисковых роботов, которые «дергают» 1С. При тестировании работало более-менее хорошо.

 

 

Как это выглядело? Поисковый робот получает параметры поиска у 1С (1С всем этим управляет), дальше переходит к следующей публикации, открывает публикацию, считывает данные и передает данные в 1С – совершенно «в лоб».

 

Проблемы архитектуры

 

 

Когда мы пришли первый вариант системы сдавать, нам заказчик выкатил вот такой список ненайденных публикаций. Он спросил: «А где они в твоем списке?». Проверяем первый экран инстаграма – действительно, что-то не то, через одну публикация не найдена.

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

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

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

Две недели просидели, перепробовали разные варианты, поняли, что надо все переделывать.

 

 

К счастью, заказчик у нас адекватный, мы ему сказали: «Нужна новая архитектура, на это нужны новые бюджеты». И он пошел нам навстречу – мы начали делать новую архитектуру.

Еще была очень большая проблема, что 1С не очень хорошо работала при высокой нагрузке на веб-сервисы – из-за того что, этих поисковых роботов очень много, и они все «стучат» в 1С, она периодически либо «зависала» с запросами, либо запросы не проходили по разным причинам. Чтобы выяснить причины, нам пришлось все обложить логами.

 

Исследование работы HTTP-сервисов 1С

 

 

Коллеги из «Цифрового КОТа» под руководством Юрия Лазаренко сделали нам исследование. Параметры исследования такие – взяли три сервера (их характеристики на экране):

  • один – совсем слабенький (тот самый «трехядерный» Athlon);
  • средний сервер;
  • и реально очень мощный сервер, Intel Xeon Gold, который стоил десятки тысяч рублей в месяц только на аренду.

 

 

И сделали исследование по такой методике – у нас есть две базы:

  • одна база – нагружаемая;
  • вторая база – выгружает.

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

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

 

 

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

 

Второй вариант архитектуры сканирования инстаграма

 

 

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

Во-первых, мы выделили роботов по ролям и между ними поставили RabbitMQ:

  • Выделили отдельного робота для сканирования – он сканирует инстаграм, находит публикации. Это позволило избежать ошибки, что в инстаграме при обновлении страницы каждый раз будет новая публикация. В предыдущей архитектуре это сбивало робота с толку, а в случае одного потока сканирования он довольно быстро идет и четко ничего не пропускает. То, что он находит, он кладет в Redis, так как это – некоторая оперативная информация.
  • А дальше робот-сканер через RabbitMQ делает указание роботам-разборщикам на считывание информации.

Получается, что сканирование идет в один поток, и от него работает штук 20-30 роботов-разборщиков, которые уже стучатся к 1С. Соответственно, не страшно, если 1С выкинула какой-то «финт ушами» (робот-разборщик упал с необработанной ошибкой) – ничего страшного, он потом из RabbitMQ еще раз прочитает и опять отправит.

 

 

Как это выглядит последовательно?

  • робот-сканер отмечает в Redis, что он прошел эту публикацию и дает поручение на ее разбор;
  • а дальше – робот-разборщик считывает эту публикацию, и, обратите внимание, он отправляет информацию в 1С, а только потом подтверждает в Redis, что он эту публикацию прочитал, и поручение на ее разбор можно убрать.

Очень удобно.

 

 

Так вот, Redis – это NoSQL СУБД, которая работает просто по принципу «Ключ:Значение». У нее много возможностей, но все сводится к тому, что это «Set» и «Get». Set – указать какое-то значение и Get – получить это значение.

А RabbitMQ – это брокер очередей. Его основная задача – гарантированно доставить сообщение. Если ты в него сообщение передал, то на 99.9% можешь быть уверен, что это сообщение дойдет.

 

Выводы из первого проекта

 

 

Какие выводы из этого проекта я сделал?

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

 

Второй кейс – организация шины данных для финансовой системы

 

 

Переходим к следующему кейсу.

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

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

Я думаю, у многих есть какое-либо банковское приложение. Там примерно такое же приложение, только для стран СНГ. И там планируется выход на разные рынки, на каждом из которых своя специфика (например, с тем же регламентированным учетом). То есть ландшафт быть универсальным, чтобы в него можно было легко подключать новые решения.

 

Особенности ИТ-ландшафта финансовых организаций

 

 

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

  • В частности, там достаточно сложно реализовать все требования в рамках одной монолитной системы, потому что, например, необходимо интегрироваться с КБ (кредитным бюро), и выгружать туда очень много информации, а когда идет эта выгрузка - это серьезная нагрузка. Соответственно, если вы применяете монолитный ИТ-ландшафт, то с большой вероятностью можете упереться в производительность. Поэтому лучше ставить системы, специализированные под свои задачи, и это позволит избежать таких проблем.
  • Также у финансовых компаний большие требования к отклику от системы. Если вы зашли на сайт, хотите взять кредит, нажали кнопку «Рассчитать график», и он считает больше нескольких секунд – вы закроете этот сайт. У системы должен быть очень быстрый отклик.
  • Но при этом многие запросы к ИТ-ландшафту, с которыми обращаются клиенты, повторяются. Потому что, если считать график платежей при следующем допущении, что суммы, которые выдаются, дискретные (кратные тысяче рублей, от 1 до 10 миллионов) – то там получается не так много значений.

 

Проблемы взаимодействия при интеграции напрямую

 

 

Первое решение, конечно, было «в лоб» – заинтегрировать все системы друг с другом.

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

Здесь, к счастью, мы проектировали ИТ-ландшафт «с нуля», поэтому постарались обеспечить все требования.

 

 

Вообще есть целый класс ESB-систем, шин данных:

  • основная задача ESB-систем – быть единой точкой интеграции для всех сервисов;
  • ESB-системы поддерживают маршрутизацию – в том числе, алгоритмическую;
  • а также они поддерживают сервисные функции по обработке, преобразованию и контролю данных.

 

Архитектура решения по интеграции различных систем в сложном ИТ-ландшафте

 

 

Какая архитектура у нас получилась?

Мы решили интегрировать все системы через BPM-систему.

  • Для того чтобы обеспечить гарантированность доставки сообщений, перед ESB стоит RabbitMQ, который гарантированно доставляет сообщения.
  • BPM-система в свою очередь эти сообщения маршрутизирует и как-то обрабатывает.
  • И для повторяющихся запросов стоит Redis. BPM-система знает, какие сообщения по каким параметрам могут быть закэшированы, и при поступлении запроса обращается в Redis, проверяет – есть данные? Если есть, возвращает оттуда. Если данных нет, то начинает опрашивать системы, которым было направлено это сообщение, собирает с них данные, помещает в Redis и возвращает клиенту.

 

 

Как все это работает:

  • запрашивающая система кладет сообщение в RabbitMQ;
  • BPM-система это сообщение считывает и после этого отправляет в целевую систему – также через RabbitMQ;
  • и потом прилетает ответное сообщение в обратном порядке.

 

 

Всего у нас получились следующие типы очередей:

  • одна очередь в RabbitMQ к BPM-системе – все системы пишут в одну очередь к BPM-системе;
  • и отдельные очереди от BPM к каждой из систем (некоторые именованные направления – для кого пишем).

 

Особенности реализации

 

 

Вот так выглядит главный интерфейс нашей BPM-системы.

Все сообщения логируются – мы даже на этапе тестирования сохраняем текст сообщения.

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

 

 

1С и RabbitMQ мы интегрировали очень просто. Есть публикация //cat.1module.ru/public/1051620/, большое спасибо автору. Там описана абсолютно бесплатная компонента, с помощью которой можно легко интегрироваться.

Мы сделали опрос RabbitMQ в цикле – не самое лучшее решение, но мы были сильно ограничены в сроках, и, кстати, из-за ограничения в сроках мы сделали свою BPM, потому что подрядчики, внедряющие промышленные ESB, не подписывались под теми сроками, за которые надо было сделать. Поэтому мы для минимизации рисков взяли знакомый инструмент и быстро на нем сделали то, что нам нужно для запуска этого «стартапа». И в качестве закрытия технического долга поставили себе задачу внедрить в дальнейшем промышленную ESB – теперь, когда у нас уже есть время, мы можем сделать это уже без горячки.

 

 

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

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

RabbitMQ, которого опрашивает BPM-система, очень нагружен. Как я уже говорил, мы сделали опрос в цикле, опрос идет в 12 потоков. Но, опять же, это выделенная виртуалка, она занимает 3.7% процессорного времени хостовой машины. Мы посчитали, что для быстрого запуска это допустимая нагрузка – нам нужно было сделать как можно быстрее.

А Redis, в свою очередь, очень порадовал. И сервер не нагружен, и обрабатывает все очень быстро. Вообще разработчики Redis заявляют о 100 тысячах транзакций в секунду, что Redis сможет их выдержать.

 

Полезный кейс: мини-система моделирования

 

 

На этом проекте мы применили очень интересный кейс.

У нас есть наша ESB (BPM-система), у нее есть какие-то входящие контракты, которые в ней же описываются. Каждый контракт обрабатывается определенным способом, маршрутизируется на определенные системы. И когда мы их стали делать, этих контрактов перевалило за сотню. Но разобраться в них реально сложно.

Что мы сделали? Мы взяли бизнес-сценарии, которые писались под этот проект, загрузили в BPM-систему, и дальше все контракты разбили по бизнес-сценариям.

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

 

RabbitMQ Management HTTP API – как можно и как нельзя использовать

 

 

Что касается интерфейса RabbitMQ Management HTTP – это очень классная штука, если его правильно применять. В общем случае, он позволяет проадминистрировать RabbitMQ – посмотреть, какие у нас есть очереди, какие в них есть сообщения, какие Exchange и т.д.

Интерфейс также позволяет, обращаясь к нему, создавать очереди – удалять, создавать пользователей и т.д. Мы это используем – у нас в BPM-системе настраиваются те системы, с кем она общается, и все очереди создаются сразу же автоматически из BPM-системы.

То есть сам RabbitMQ нам не нужно администрировать, он администрируется автоматически.

 

 

Для чего его точно нельзя применять?

Абсолютно точно его нельзя применять для интеграции. Про это и в документации сказано, но я, конечно же, не поверил и попробовал. Проблема в том, что читает он очень медленно, обеспечивает всего 170 сообщений в секунду, и сообщения, которые вы считываете через интерфейс RabbitMQ HTTP Management, нельзя подтвердить. Там нет такого сервиса. Поэтому очень неудобно.

Интеграция через стандартную компоненту намного удобнее – там согласно нагрузочным тестам пролетает по 2000 сообщений в секунду, плюс есть возможность подтверждения чтения сообщений.

 

Удачи и сложности проекта

 

 

Что на этом проекте у нас получилось хорошо?

  • При интеграции через шину архитектура получается расширяемой – можно абсолютно легко поставить рядом еще одну систему – просто сделать новые контракты, или вообще посадить систему на существующие контракты.
  • Все запросы аудируемые.
  • Redis существенно снижает нагрузку на инфраструктуру, нам не надо те же графики платежей каждый раз считать, они у нас кэшируются. У Redis очень удобно сделано. Там есть возможность поставить TTL, время жизни значения. Соответственно, если мы считаем сегодня, там всегда TTL ставится до 24:00 – таким образом, Redis сам следит за тем, чтобы графики всегда были актуальны.

Что очень сложно у нас проходило?

  • Идея единой точки интеграции очень сложно доходила до участников проекта. Очень много приходилось разъяснять: на этом проекте было много подрядчиков, со всеми приходилось вести многочасовые беседы, потому что каждый хотел вытащить свои REST-интерфейсы и по-простому заинтегрироваться “точка-точка”. Но, c таким количеством систем, ни к чему хорошему это не привело бы.
  • И были проблемы на старте с тем, что мы не совсем правильно подобрали ресурсы под виртуальные машины с RabbitMQ, соответственно, при больших нагрузках время доставки сообщений увеличивалось, мы не сразу могли это понять. Очень хорошо было бы, если бы какую-то систему мониторинга сразу под это подложили, чтобы она нам просигнализировала, что пора увеличивать.

 

Выводы из второго проекта

 

 

Какие выводы?

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

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

 

Вопросы:

 

  • Хотел спросить по поводу BPM-системы. На мой взгляд, маршрутизация в RabbitMQ – крайне гибкая и замечательная. Почему вы не использовали маршрутизацию в RabbitMQ?
  • Потому что у нас бизнес-логика была на BPM – там у нас был и контроль сессий мобильного приложения, и непосредственно бизнес-логика. Например, в зависимости от того, есть сессия или нет – могут быть разные ответы.
  • А на время отклика насколько повлияла BPM-система? Она же, получается, наиболее медленное звено оказалось в этой цепочке.
  • Не медленное, а наиболее высоконагруженное. Там сейчас средний отклик около 200 миллисекунд.
  • А каждое сообщение, я так понимаю, пишется в базу данных 1С и только после этого маршрутизируется куда-то еще?
  • Да. Время записи действительно влияет, я показывал JSON сообщения, который мы храним. Но это только на время тестов. Если его убрать, там быстрее будет.
  • Мобильное приложение у клиента отправляет запрос на обновление каких-то данных. И этот запрос уходит в очередь сообщений, очередь сообщений его направляет в BPM, BPM лезет за данными сначала в кэш, а если в кэше их нет, дергает систему, получает их, записывает в кэш, и потом, соответственно, эти данные должно получить мобильное приложение. А как мобильное приложение эти данные получает?
  • Отличный вопрос. Когда мы начали с разработчиками мобильного приложения проектировать архитектуру, это единственные, кого я не смог убедить использовать асинхронные вызовы, поэтому у них это выглядит таким образом – они обращаются к бэкенду мобильного приложения, бэкенд мобильного приложения, соответственно, держит запрос 300 миллисекунд. В основном, мы 80% запросов в эти 300 миллисекунд получаем ответы. Он держит сессию 300 миллисекунд. В это время он кладет сообщение в RabbitMQ, дальше оно проходит контур безопасности – сначала во внешний Rabbit, между ними – сервис-транслятор, который позволяет отключить внешний контур от внутреннего. Сервис-транслятор перекладывает его во внутренний RabbitMQ, из внутреннего RabbitMQ его считывает BPM-система, собирает данные, возвращает. При возвращении данных (там есть MessageID, естественно) бэкенд смотрит, если еще сессия жива (если успели в 300 миллисекунд), то возвращает. Для мобильного приложения получается простой синхронный GET-запрос. Но за ним стоит асинхронность. Если не успел, она его кладет в Redis, но уже в другой Redis. Для мобильного приложения два уровня кэша. Первый уровень кэша – это Redis, который за BPM, а второй уровень кэша – это тот, который стоит на бэкенде. Кладет его в Redis, а мобилка получает 201 статус, если не успеет на 300 миллисекунд (это означает «запроси еще раз») и время, через которое нужно еще раз запросить.
  • У нас есть интеграция между 1С с другой системой через HTTP-сервисы. И когда запросов много – условно, несколько десятков, то все начинает жестко висеть. Вопрос в том – то, о чем вы сейчас рассказали, судя по всему, можно применить как раз чтобы накапливать вызовы этих HTTP-сервисов. То есть они у нас непостоянные, может быть секунда, в которую три вызова, есть секунда, в которую 30 вызовов. Можно ли применить то, что вы описали, но насколько это сложно? Есть уже работающая интеграция с каким-то простым HTTP-сервисом. Насколько сложно применить вашу технологию.
  • Не сложно, я давал ссылку на описание интеграции с RabbitMQ. Там коллега выложил готовый пример, его просто копируешь, и все работает. Вам нужно просто скопировать этот код в две конфигурации и поставить себе RabbitMQ. И все. И немного, может быть, допилить.
  • Что вы можете сказать по поводу отказоустойчивости RabbitMQ? Как вы обеспечили очереди с Durable? Или кластер был?
  • Мы еще не прорабатывали отказоустойчивость, это будет следующий этап.
  • Поэтому у вас и такие высокие скорости, стоит вам только включить Durable в очередь, у вас упадет все в десятки раз.
  • Смотрите, у нас цена потери сообщения – не очень высокая. Если у вас мобилка обновилась за полсекунды и за 0.7 секунды – вы не увидите разницы. Да, если включить отказоустойчивость, скорость просядет, но останется достаточно приемлемой, как правило. У нас в планах объединить RabbitMQ в кластер, и сделать горизонтальное масштабирование BPM-системы.
  • У меня тоже вопрос по производительности – какой скорости передачи сообщений в секунду из Rabbit реально удалось добиться и какой средний размер сообщения (в байтах, в чем угодно).
  • В байтах размер сообщения я точно не скажу. Самое большое сообщение в JSON, которое я гонял – это график платежей на 12 месяцев. У меня получилось порядка 400 сообщений в секунду на всю инфраструктуру. Не забываем, что там есть 1С, который отвечает не так быстро.
  • При каком железе? Чистый Rabbit?
  • Rabbit на виртуалке с параметрами процессор e5 и 128 Гб оперативной памяти. Сам RabbitMQ при двух выделенных ядрах и 4Гб оперативной памяти, из 1С давал 2000 сообщений в секунду. Но кто там сейчас тормозит – 1С или RabbitMQ, будем еще расследовать.
  • Вернемся к первому проекту. На слайде я увидел, что у вас роботы-сборщики, которые парсили публикации в инстаграме, они общаются с 1С не через RabbitMQ, а напрямую. Почему так? Это связано с объемом данных или с чем-то еще?
  • Это было сделано просто для удобства. Потому что из 1С было удобно вытащить HTTP-сервис. Там специфика работы этих роботов-разборщиков – они волнами идут. Сначала, допустим, много сообщений, а потом в конце дня, так как уже все закешировано (кеш 24 часа держится), их мало. Поэтому нам там придумывать RabbitMQ между роботами мы посчитали нецелесообразным. Остались на HTTP-интерфейсе. Когда будем новые соцсети подключать, наверное, перейдем на RabbitMQ.
  • Я не совсем понял, зачем там Redis?
  • Я напомню, сканер просматривает публикации, и ссылки на эти публикации кладет в Redis. ИД кладет в очередь, робот-разборщик берет ссылку по ИД и открывает публикацию полностью. В Redis мы использовали несколько функций. Во-первых, там хранятся ссылки, во-вторых, если публикацию мы прошли, то следующие 24 часа мы ее не трогаем. Мы просто отмечаем, что мы ее пробежали и устанавливаем “время жизни” - TTL.
  • По инстаграму – а публикации вручную просматривали? Как там выявлялось, что используется контент, который требует лицензии?
  • Когда мы запускали управляющую систему, там был поиск по хэштегам, этого было достаточно, потому что люди вообще не стесняются. А дальше там они планировали нейросеть и то, что нейросеть не разобрала, идет в отдельное место для верификатора, который уже глазами проверяет.

 

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

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

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

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

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. 🅵🅾️🆇 460 13.05.20 02:26 Сейчас в теме
Офигительно.
Хотел бы такой задачкой заняться.
Прям все как я люблю :3

Теперь какойнить Tensorflow подключить и анализировать схожесть изображений.

Кстати, 1С скоро выпустит родной брокер сообщений:
https://wonderland.v8.1c.ru/blog/integratsionnaya-shina/
Gilev.Vyacheslav; SergeyN; +2 Ответить
2. zurapa 13.05.20 04:08 Сейчас в теме
А почему такой секрет об имени организации, что занялась поиском нарушителей для правообладателей? Они же не наркотики распространяют. Страна должна знать своих "героев" в лицо. Михалкова мы все знаем. Это не его ли конторка?

Мне нравится подход в ИТ. Человек на серьёзных щах рассказывает, как писал инструмент вымогания денег. Т.е. людям сначала дали попопстить отрекламировать ту или иную медиа, а теперь его ещё и оберём. Это получается, когда не тебе за рекламу платят, а ты платишь, за то, что рекламируешь кроссовки найк. И разработчики молодцы. Дай Бог им проект, в котором они будут писать приложение, для отслеживание и убийства их родителей. Думаю, у них и с этим никаких маральных и этических проблем не будет. Профессионалы же!
DonAlPatino; +1 1 Ответить
3. o.nikolaev 195 13.05.20 13:41 Сейчас в теме
"нового финансового продукта", да простит Создатель, уж не микрофинансирование ли?
Оставьте свое сообщение

См. также

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

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

26.04.2019    10266    0    Aleksey.Bochkov    7    

Выбор процессора для 1С: конец споров или начало?

Производительность и оптимизация (HighLoad) Бесплатно (free)

Периодически занимаясь исследованиями производительности я повидал много решений. Делюсь некоторыми выводами на основании теста Гилева и собственных мыслей.

25.05.2020    4612    0    starik-2005    157    

Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей

Производительность и оптимизация (HighLoad) Бесплатно (free)

Проводить мониторинг производительности вручную, выявляя закономерности в куче графиков и десятках таблиц, довольно сложно. Но это не значит, что разбираться с инцидентами нужно только после жалоб от пользователей. О том, как обучить нейронную сеть и заставить ее оповещать о проблемах, на конференции Infostart Event 2019 Inception рассказал начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков.

27.04.2020    2836    0    ivanov660    5    

Пример поиска ошибок в технологическом журнале

Технологический журнал Производительность и оптимизация (HighLoad) Бесплатно (free)

Примеры bash - скриптов для поиска ошибок в технологическом журнале.

23.04.2020    1955    0    vasilev2015    6    

Опыт миграции из собственного датацентра в облако AWS Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Хотя данная публикация и не имеет прямого отношения к 1С, она может быть интересна тем, кто занимается крупными базами данных на MS SQL Server. Описывается опыт миграции баз данных в облако AWS в компании glassdoor.com, где я занимался этим проектом. Это первый драфт текста, получившийся довольно скомканным - в процессе буду дополнять.

29.07.2018    10765    0    Aleksey.Bochkov    9    

Фреймворк "Мониторинг производительности". Руководство пользователя

Производительность и оптимизация (HighLoad) Бесплатно (free)

Описание и руководство "Мониторинг производительности": краткое описание конфигурации, сборник из статей, примеров - собрано в одном файле.

21.04.2020    2148    0    ivanov660    3    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    8547    0    YPermitin    0    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    9292    0    informa1555    21    

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    27879    0    MrWonder    42    

Анализ взаимоблокировок

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

20.03.2020    3427    0    vasilev2015    21    

Автоматизация магазина на Oracle Apex. Обзор аналога 1С Промо

Интеграция Розничная торговля Розничная торговля Бесплатно (free)

Как известно 1С - лидер в автоматизации учета в постсоветском пространстве. Есть ли достойные альтернативы (не дорогие, с возможностью конфигурирования, простые) ? Однозначно да ! Предлагаю Вашему вниманию обзор "буржуйской" технологии Oracle Apex

17.05.2013    58163    0    avhrst    295    

Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

Математика и алгоритмы Производительность и оптимизация (HighLoad) Бесплатно (free)

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

02.03.2020    3613    0    ildarovich    7    

Делаем быстрее POSTGRESQL COUNT (*)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Laurenz Albe "POSTGRESQL COUNT(*) MADE FAST". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/postgresql-count-made-fast/

28.02.2020    1816    0    w.r.    1    

Простое обнаружение проблем производительности в PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Hans-Jürgen Schönig "DETECTING PERFORMANCE PROBLEMS EASILY IN POSTGRESQL". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/detecting-performance-problems-easily-in-postgresql/ Актуально для всех 1С ников, перешедших с MS SQL на Postgres

20.02.2020    2978    0    w.r.    4    

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

05.08.2015    59577    0    Sergey.Noskov    119    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    6894    0    Evil Beaver    13    

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

Производительность и оптимизация (HighLoad) Бесплатно (free)

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    7742    0    a.doroshkevich    17    

Атака сервера кнопонажималкой

Нагрузочное тестирование Инструментарий разработчика Бесплатно (free)

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    4518    0    nixel    22    

Долго открывается конфигуратор Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    39365    0    Gilev.Vyacheslav    1    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    8567    0    ivanov660    16    

История роста и работы команд 1С в условиях HighLoad и BigData

Автоматизация ИТ-компании Производительность и оптимизация (HighLoad) Бесплатно (free)

Современные потребности бизнеса заставляют программистов 1С решать все более сложные задачи. А главные требования, которым необходимо соответствовать, – вовремя поставлять ценности высокого качества. С какими сложностями приходится сталкиваться в работе программистам в динамично развивающейся брокерской сфере, и как их решают, на конференции Infostart Event 2018 Education рассказал начальник отдела интеграции БКС Технологии Сергей Артемов.

11.11.2019    6360    0    user826155    11    

Обслуживание баз данных. Не так просто, как кажется

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    15048    0    YPermitin    28    

Повышенная нагрузка на диски сервера баз данных SQL Server Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

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

15.03.2015    38624    0    gallam99    17    

Набор скриптов для знакомства с SQL Server

Производительность и оптимизация (HighLoad) Администрирование СУБД Бесплатно (free)

Поговорим о скриптах, которые помогут быстро ознакомиться с состоянием SQL Server, в том числе с вопросами производительности.

30.09.2019    19423    0    YPermitin    14    

Облачные кассы и 1С. Интеграция, которой не было

Интеграция Кассовые операции Россия Бесплатно (free)

В кейсе расскажем о сценариях работы с арендованными онлайн-кассами (облачными кассами). Приведем общую схему работы, удовлетворяющую требованиям закона. Опишем интересное нетиповое решение интеграции с 1С.

24.09.2019    5118    0    antonovintervolga    15    

Оповещения боту из 1С за 31 минуту

Практика программирования Интеграция v8::УФ 1cv8.cf Бесплатно (free)

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

18.09.2019    14759    4    feva    35    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    65690    0    yuraos    112    

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Администрирование данных 1С Zabbix v8 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    16236    0    Sloth    24    

Подбор оборудования для информационных систем на платформе 1С

Интеграция Производительность и оптимизация (HighLoad) Бесплатно (free)

При подборе оборудования по рекомендациям с сайта ИТС возникает противоречие: проводить ли нагрузочные тесты, чтобы определить возможную нагрузку, или достаточно просто взять данные из таблиц статистики? О том, какую тактику применить в том или ином случае, на конференции INFOSTART EVENT 2018 Education рассказал начальник отдела разработки компании IBS Филиппов Евгений.

09.09.2019    7923    0    jf2000    8    

Руководство по SQL: Как лучше писать запросы (Часть 2)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    6637    0    w.r.    2    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

Не секрет, что многие пользователи, использующие партионный учет (а таких очень много, даже среди огромных холдингов, несмотря на пропаганду РАУЗ) при больших нагрузках сталкиваются с резким замедлением списания партий.

21.06.2013    52415    0    Антон Ширяев    116    

Анализ производительности APDEX

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    8981    2    YPermitin    7    

Руководство по SQL: Как лучше писать запросы (Часть 1)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    9493    0    w.r.    19    

Использование Union вместо OR

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

22.08.2019    3395    0    w.r.    35    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    53173    0    Gilev.Vyacheslav    46    

Тюнинг производительности запросов в PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Brady Holt "Performance Tuning Queries in PostgreSQL ". Оригинал доступен по ссылке https://www.geekytidbits.com/performance-tuning-postgres/

31.07.2019    6473    0    w.r.    5    

Неочевидные проблемы производительности: важность системного подхода при анализе

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

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

19.07.2019    7920    0    Филин    12    

Настройка параметров PostgreSQL для оптимизации производительности

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tuning PostgreSQL Database Parameters to Optimize Performance". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/31/tuning-postgresql-database-parameters-to-optimize-performance/

08.07.2019    6050    0    w.r.    19    

Параллельные вычисления в 1С 8 Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    29145    0    gallam99    19    

Сравнительное тестирование работы PostgreSQL с большими страницами Linux

Производительность и оптимизация (HighLoad) Бесплатно (free)

Представляю вашему вниманию перевод статьи Ibrar Ahmed "Benchmark PostgreSQL With Linux HugePages". Оригинал расположен по ссылке https://www.percona.com/blog/2018/12/20/benchmark-postgresql-with-linux-hugepages/

05.07.2019    4008    0    w.r.    6    

Настройка параметров ядра Linux для оптимизации PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tune Linux Kernel Parameters For PostgreSQL Optimization". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

05.07.2019    4772    0    w.r.    1    

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным

Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка v8 Бесплатно (free)

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

02.07.2019    9936    0    igordynets    119    

Бесплатный GPS-трекинг Промо

Интеграция Управление персоналом (HRM) Учет рабочего времени Управление персоналом (HRM) Учет рабочего времени Бесплатно (free)

Современные технологии и возможности становятся все более доступными для широких масс и повсеместно используемыми, как для частного лица, так и для мелкого и среднего бизнеса. Так и GPS-трекинг (отслеживание в реальном времени на карте местоположения водителей, курьеров, монтажных бригад, торговых представителей, детей, собак и т.п., а также просмотр статистики по их передвижениям и остановкам), становится сейчас все более востребованным сервисом, как для домашних условий, так и для предприятия. И, если крупные фирмы (например, транспортные предприятия) подписав договора с коммерческими сервисами, оплачивая своевременно счета за устройства и абонплату, эту проблему для себя решили, то это скорее подходит для крупных корпоративных клиентов. Что делать нам, простым смертным или небольшой фирме с несколькими водителями, например? Какие есть простые, надежные и недорогие решения?

05.01.2013    44246    0    venger    19    

Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE

Производительность и оптимизация (HighLoad) Бесплатно (free)

Данная статья является переводом оригинальной статьи Martin Kováčik "PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE" https://redbyte.eu/en/blog/postgresql-benchmark-freebsd-centos-ubuntu-debian-opensuse/ В ней рассматриваются тесты СУБД PostgreSQL 10.1 в приближенных к реальным условиям средах на различных unix-системах

30.06.2019    5498    0    w.r.    2    

Ускорение чтения правил обмена в УПП 1.3 в 20 раз!

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

27.06.2019    8876    0    YPermitin    16    

Непридуманные истории по оптимизации. История 1

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    11369    0    Repich    117    

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Практика программирования Производительность и оптимизация (HighLoad) v8 v8::Запросы Бесплатно (free)

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    21244    0    dmurk    144    

Не думать о секундах свысока...

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    7198    0    vasilev2015    21    

Мониторим тяжелые запросы, классифицируем результаты

Производительность и оптимизация (HighLoad) Бесплатно (free)

Дальнейшее развитие инструментария для мониторинга запросов.

08.05.2019    4531    0    ImHunter    0    

Мониторинг SQL Server с помощью Extended Events (и не только) для 1С. Как держать руку на пульсе?

Производительность и оптимизация (HighLoad) Бесплатно (free)

Что и как мониторить в работе SQL Server, чтобы держать Вашу систему в форме.

05.05.2019    29973    0    YPermitin    23