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

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

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

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

Сегодня поговорим про такие замечательные технологии, как «Кролик» и «Редиска», то есть RabbitMQ и Redis Server. Меня вообще очень радует, что наша отрасль начала применять такие промышленные технологии. Спасибо Андрею Овсянкину, который приложил свою руку к тому, что они появились в мире 1С. Также большая благодарность Даниилу Коневу (//sib.vc/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 мы интегрировали очень просто. Есть публикация //sib.vc/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. 🅵🅾️🆇 462 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 196 13.05.20 13:41 Сейчас в теме
"нового финансового продукта", да простит Создатель, уж не микрофинансирование ли?
Оставьте свое сообщение

См. также

Обмен данными. Консистентность vs Многопоточность Промо

Интеграция v8 1cv8.cf Бесплатно (free)

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

03.09.2019    10500    0    m-rv    1    

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

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

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

25.05.2020    6058    0    starik-2005    186    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

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

Обычно предметом оптимизации являются заранее определенные ключевые операции, т.е. действия, время выполнения которых значимо для пользователей. Причиной недостаточно быстрого выполнения ключевых операций может быть неоптимальный код, неоптимальные запросы либо же проблемы параллельности. Если выясняется, что основная доля времени выполнения ключевой операции приходится на запросы, то осуществляется оптимизация этих запросов. При высоких нагрузках на сервер СУБД в оптимизации нуждаются и те запросы, которые потребляют наибольшие ресурсы. Такие запросы не обязательно связаны с ключевыми операциями и заранее неизвестны. Но их также легко выявить и определить контекст их выполнения, чтобы оптимизировать стандартными методами.

24.05.2020    4174    0    DataReducer    22    

Нейроконструктор

Интеграция Искусственный интеллект (AI) Прочие инструменты разработчика v8 Бесплатно (free)

Изучайте нейронные сети и экспериментируйте вместе с расширением конфигурации "Нейроконструктор". Навыки программирования не требуются.

20.05.2020    2806    19    user1404129    9    

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

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

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

26.04.2019    10332    0    Aleksey.Bochkov    7    

Синхронизация БИТ:СКУД 8 с Parsec.Net 2.5

Интеграция Внешние источники данных v8 1cv8.cf Бесплатно (free)

Настройка синхронизации БИТ:СКУД 8 с Parsec.Net.2.5, выгрузка данных из внешней системы контроля доступа.

04.05.2020    2933    0    RPGrigorev    0    

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

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

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

27.04.2020    2972    0    ivanov660    5    

Интеграция БИТ:СКУД с типовой конфигурацией

Интеграция v8 1cv8.cf Россия Бесплатно (free)

Интеграция БИТ:СКУД с типовой конфигурацией, обновление БИТ:СКУД в составе конфигурации и отдельно. Обновление системы защиты.

26.04.2020    3926    0    RPGrigorev    0    

И тогда наверняка нас захватят облака Промо

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

Внимание! Данный текст содержит достаточно мало технических подробностей и готовых рецептов. Главным образом некоторые размышления на предмет будущего технологий и профессий. Некое лёгкое чтение на досуге.

28.06.2019    8833    0    comol    36    

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

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

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

23.04.2020    2025    0    vasilev2015    6    

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

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

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

21.04.2020    2245    0    ivanov660    3    

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

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

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

06.04.2020    8748    0    YPermitin    0    

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

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

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

29.07.2018    10820    0    Aleksey.Bochkov    9    

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

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

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

31.03.2020    9655    0    informa1555    21    

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

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

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

20.03.2020    3539    0    vasilev2015    21    

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

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

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

30.10.2017    27956    0    MrWonder    42    

Интеграция "Библиотеки интеграции МДЛП 1.1.2.7" с типовой конфигурацией

Интеграция Конфигурирование 1С v8 Здравоохранение, медицина, стоматология Россия Бесплатно (free)

Инструкция для интеграции “Библиотеки интеграции МДЛП 1.1.2.7” в типовые конфигурации, на примере конфигурации “Управление нашей фирмой, редакция 1.6 (1.6.18.168)”.

02.03.2020    2759    0    RPGrigorev    3    

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

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

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

02.03.2020    3685    0    ildarovich    7    

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

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

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

17.05.2013    58228    0    avhrst    295    

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

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

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

28.02.2020    1877    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    3042    0    w.r.    4    

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

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

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

17.02.2020    7017    0    Evil Beaver    13    

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

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

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

05.08.2015    59718    0    Sergey.Noskov    119    

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

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

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

07.02.2020    7860    0    a.doroshkevich    17    

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

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

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

20.01.2020    4591    0    nixel    22    

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

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

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

19.12.2019    8777    0    ivanov660    16    

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

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

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

22.04.2015    39447    0    Gilev.Vyacheslav    1    

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

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

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

11.11.2019    6423    0    user826155    11    

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

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

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

14.10.2019    15233    0    YPermitin    28    

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

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

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

30.09.2019    19598    0    YPermitin    14    

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

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

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

15.03.2015    38727    0    gallam99    17    

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

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

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

24.09.2019    5239    0    antonovintervolga    15    

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

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

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

18.09.2019    14908    4    feva    35    

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

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

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

10.09.2019    16381    0    Sloth    24    

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

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

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

22.01.2014    65782    0    yuraos    112    

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

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

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

09.09.2019    8004    0    jf2000    8    

Интеграция 1С с промышленным оборудованием

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

Эффективность управленческой информации в производственном процессе зависит от данных, собираемых на нижних уровнях. Про автоматизацию получения этих данных с использованием технологии OPC (OLE for process control) на конференции Infostart Event 2018 Education рассказал Юрий Коноваленко.

06.09.2019    7840    0    user642664_yurkeshk    12    

Poka-yoke. Оператор производственной линии – пользователь 1С. Кто сказал, что 1С только для финансов?

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

Что такое Poka-yoke системы, зачем они нужны и как меняется работа на предприятии при их внедрении рассказал руководитель проектного отдела компании «Информационные технологии» Дмитрий Макаров на конференции INFOSTART EVENT 2018 EDUCATION.

04.09.2019    3453    0    pro-rok    16    

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

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

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

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

Руководство по 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    6703    0    w.r.    2    

Как должна выглядеть правильная интеграция. Использование Mule ESB и RabbitMQ с 1С

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

Чем масштабнее проект, тем сложнее настроить все связи. Каждый решает эти проблемы по-своему: кто-то пользуется конвертацией, кто-то пользуется xml и json. Руководитель управления ИТ компании WiseAdvice Олег Филиппов рассказал, как можно применить такие инструменты, как Mule ESB и RabbitMQ.

02.09.2019    8402    0    comol    3    

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

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

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

31.08.2019    9067    2    YPermitin    7    

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

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

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

19.02.2013    53275    0    Gilev.Vyacheslav    46    

Руководство по 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    9639    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    3443    0    w.r.    35    

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

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

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

31.07.2019    6567    0    w.r.    5    

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

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

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

11.02.2013    29195    0    gallam99    19    

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

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

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

19.07.2019    7995    0    Филин    12    

Бизнес-аналитика с помощью Power BI

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

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

11.07.2019    11545    0    pbazeliuk    18    

Настройка параметров 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    6121    0    w.r.    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    4065    0    w.r.    6