Победа производительности системы достаётся одной строке
System.out.println("1, 2, 4, 8, 16, 32, 64");
Я всё равно буду стоять на своём, что надо показывать примеры эффективного использования разных конструкций. На практике, бывает настолько не эффективное использование. Например, старый добрый интерфейс итератора. Итератор удаляет пустые строки.
List<String> list; // размер списка, порядка 20-30 записей
for(Iterator<String> it; it.hasHext(); ) {
String val = it.next();
if (val == null || val.isEmpty()) it.remove();
}
return list;
Превращается в поток, фильтр и преобразование в новый список. Красиво — да. Эффективно — нет. Если усложнять задачу, возможно, будет эффективней переход на потоки.
Возвращаясь к оператору for, методу iterate не всегда применим. Скажем, нам нужен бесконечный цикл и выход по некоторому условию. В замыкании нет break, для прерывания цикла и нет return для остановки потока. Или всё это есть?
Вы читать умеете статью? И так, имеется базовый цикл
/ Java 8
for (int i = 1; i < 100; i *= 2) {
System.out.println(i);
}
Переменная i, это не Java Object, а вполне себе, достаточная переменная, внутри стека. Посмотрим на конструкцию
.iterate(1, i -> i < 100, i -> i * 2)
Тут, как минимум, 2 замыкания. Как вы думаете, что быстрее выполнится, просто операция или замыкание, выполняющее эту операцию?
Если уж приводить пример, надо показывать действительно то, что не будет выглядеть на столько бессмысленным.
Статья очень старая. Тем не менее, опишу свой путь.
Как и многие, я начинал со Spring и Blueprint.
Не стартовавшие компоненты, висящие в постоянном статусе запуска. Главная причина — отсутствие описания связывания компонентов друг с другом. Есть API сервиса, есть реализация сервиса, есть потребитель. Потребитель стартует раньше и ждет запуска реализации. Подождал и завис. Ни ответа, ни привета.
Неправильная система слежения изменения конфигурации. Создание proxy оболочек над классами не дает воспользоваться новыми свойствами сервиса.
Всё это было. Было мучительно. Перешел на механизм динамических сервисов. Получил набор аннотации org.osgi.service.component.annotations для описания параметров сервиса и описания зависимостей от других сервисов. На уровне framework идет распознание запуска потребителя и реализации.
В потребителе, на уровне активации компонента (@Activate) идет создание и запуск Apache Camel маршрутов. На уровне остановки компонента (@Deactivate) выполняется остановка Apache Camel маршрутов.
Теперь, при изменении настроек реализации сервиса происходит остановка и запуск потребителя.
Если реализация сервиса настроена неправильно, потребитель не запустится и не зависнет в режиме постоянного ожидания, как в Spring DM или Blueprint. Настроил параметры реализация сервиса, потребители стартуют автоматически.
В маршрутах Apache Camel очень часто используются cron. Для профилактических нужд приходится менять расписание доступа к внешним серверам. В конфигурации компонента (Component) меняем параметры cron. Компонент, на уровне изменения (@Modified) производит остановку и запуск Apache Camel маршрутов.
При всех манипуляциях перезапуска маршрутов, система не выкидывает старых процессов обработки данных, давая им время завершится. При этом, новые данные, на стадии остановки, не обрабатываются.
В затрагиваемой технологии микросервисов я так и не нашел решения плавной остановки этих самых микросервисов.
Раньше ездил на гоночном велосипеде по трассам. Был случай. Догнал местного деревенского жителя. Смотрю, вроде едет довольно резво, но как-то его шатает. Поравнялся, а он пьяный. Пришлось ехать параллельно с ним, чтобы его случайно не вынесло под колеса машин. Так и сопровождал его около 5 км, от одной деревни к другой. Пару раз пришлось поднимать его. Честное слово, не советую я вам судьбу испытывать. Не всегда рядом может оказаться добрый попутчик.
Еще раз ехал с другим местным жителем. Он рассказывал, что довольно часто приходится искать местных с велосипедами в придорожных канавках. Попадет и вылезти не может, пошатается рядом с велосипедом и засыпает. Потом вся улица в деревне пол ночи не спит. Родственники вспоминают о бедолагах, когда уже темно. Пойди, разыщи бедного с фонариками возле дороги. Он ведь и на мобильник не реагирует, так его на солнышке разморило, что к ночи крепко спит.
Хочешь пить, пей, но на велосипед — ни ни.
Местные жители рассказывали, что ГАИ и ГИБДД не отбирали велосипед, а передавали дело участковому. Он то и забирал на пару недель велосипед. А деревенскому жителю без велосипеда ой как тяжело. Надо к остановке идти и деньги платить. Велосипед в деревне — это жизнь.
Сейчас езжу на А образном велосипеде с маленькими колесами, в 16 дюймов. Вот, почти все подряд спрашивают, а где мотор и батарейки. А у меня Garmin показывает каденс 90-120 и скорость 26-32. И ГИБДД на перекрестках смотрит, что за сумасшедший на детских колесах едет. Советуют по зебре на перекрестках переходить.
Велосипед и алкоголь не надо совмещать. Велосипед — это нагрузка на сердечно-сосудистую систему. Вас может запросто вырубить на солнышке, даже от малой дозы. Потом, велосипед — это всё же транспортное средство и пользуется дорогами общего пользования. Прав вас не лишат, а вот штраф и конфискацию транспортного средства могут сделать. Уж лучше такси или общественный транспорт, раз выпить хочется.
Подумать только, какой повод для смеха — лишение ТС, велосипеда, и несколько лет нельзя управлять велосипедом, а заодно и личным автомобилем, если он у вас есть.
Я не так уж и часто катаюсь на велосипеде. Тем не менее, сотрудникам ГИБДД иногда интересно поговорить о велосипеде. Иногда, подходят на перекрестках и рекомендуют переходить по зебре, а не ехать. Не дай бог сотрудник заподозрит, что вы выпили.
Удачи вам.
Как владелец Strida, с ремнем, отвечу. Учитываем, что ремень должен быть с кивларом. При уменьшении температуры данный материал растягивается. При увеличении температуры сжимается. В связи с этим, на велосипеде стоит подшипник, который не дает ремню соскочить с задней втулки.
Сам ремень тоже требует ухода. Надо периодически брызгать силиконовой смазкой. Если этого не делать, будет противно скрипеть.
Нельзя делать резких рывков, типа встал на педали и рванул. Тут конечно, сказывается геометрия рамы велосипеда Strida. Но это не самое важное. Хуже, это эффект прострела, как будто твой пистолет дал осечку вместо выстрела.
Еще одна проблема — износ задней звездочки. У меня за 4 года эксплуатации стерлись 4 звёздочки. Последний раз решил купить звездочку из пластика. На момент покупки, в магазине не было звезды из металла.
Износ металла от взаимодействия с ремнем мне понять очень тяжело, так как на машинах ролики не истираются так быстро, как на велосипеде. Может быть, всему виной незащищенность узла от пыли, воды и грязи. В машине, все же, все под капотом.
Износ приводит к необходимости шаговой доступности к магазину запчастей производителя. Ждать 2-3 недели доставки из другого города, это тяжко для велосипедиста.
Вы бы заглянули на сайт wiki статью PKCS. Запрос на сертификат — это PKCS#10. Разные устройства, типа eToken, это стандарт PKCS#11.
Что смотреть в этой карточке или USB token? Микроконтроллер. Разве, что, на специальном оборудовании снимать с него стружку. Эти устройства хороши, но очень медленные. Вот, вы, пишите ответ в данной статье. Обмен с сервером идет в зашифрованном протоколе TLS. Теперь, ваш поток мыслей должен пройти через эту карточку / USBToken. После этого, данные уйдут на сервер. Данных не много. А теперь представьте, что этот сервер так же, весь трафик, все HTML статьи, будет гонять через USB Token. Данная технология имеет право на жизнь в некоторых областях применения.
PKCS#7 — это контейнер, используемый в криптографии. Сертификат, обычно, передается в контейнере PKCS#7, вместе с подписью.
В контейнер можно положить несколько сертификатов. И будет у нас хранилище сертификатов.
Можно положить CRL файлы. Можно положить подписываемое сообщение. Можно положить зашифрованное сообщение.
Отсюда и идут все сложности в понимании.
Да, в самом сертификате есть подпись издателя и сведения о сертификате издателя. Но сам сертификат не является контейнером формата PKCS#7.
Для чтения и записи сертификата и контейнера используется стандарт ASN1.
Отсюда и все сложности на этапе освоения всего этого нагромождения.
Скажу крамольную истину. Если вам надо только проверять подписи и не заниматься подписыванием сообщений, вы можете использовать КриптоПро JCP и не платить. Да, это не честно, но работает.
Вы считаете, что ваше ПО выступает в качестве автономных сервисов. Поймите, что слово сервис — это клиент шины. Сервер — это средство хранения и обмена в вашей шине. По аналогии, это SMTP/POP сервера электронной почты. У вас всего лишь почтовый клиент.
То же самое в MQ или JMS. Есть один или несколько серверов, на которые поступают сообщения и они передают их клиентам. Клиент может публиковать сообщения, может забирать корреспонденцию. Но при этом, он остается для шины клиентом.
С точки зрения, вы делаете клиента. Сервер у вас пассивный.
В рамках Java программ, мы создаем сокеты. Для понимания, о чем я говорю, можно посмотреть статью Создаем клиент-сервер на сокетах.
Если вы создаете ServerSocket, это сервер. Если создаете Socket, это клиент.
Теперь представим такую ситуацию. У нас есть SOAP сообщение от клиента. Он подписывает сообщение и отправляет на сервер. Сервер отправляет ответ. Если ответ сервера должен быть подписан, ему нужна серверная лицензия.
Еще раз повторю, что сервис в шине — это клиент.
Он спрашивает у сервера наличие сообщений и получает сообщения в ответ. То что ваш сервис, это клиент, понятно?
После получения ответа, ваше ПО отключается от сервера и может не спеша подготовить ответ на полученное сообщение. После этого, ваш сервис подключается к серверу обмена и передает туда свое сообщение для отправителя исходного сообщения. Получает ответ от сервера, что он получил сообщение. То что ваш сервис — это клиент, понятно?
В чем же главное отличие сервера от клиента? Сервер не может самостоятельно установить соединение с клиентом. А вот, клиент может установить соединение с сервером.
Вам хватит клиентской лицензии на средства криптографии.
Вы пишете клиента или вы пишете сервер?
Обратите внимание на этот вопрос. Клиенты могут воспринимать вашу систему как сервер. Но ваша система может являться промежуточным звеном на этапе передачи данных во внешнюю систему. Другими словами, вы выступаете инициатором передачи сообщения — вы клиент. Это главное понимание.
Если же ваша система является получателем, вы выступаете в качестве сервера — стоите и слушаете, когда кто-то к вам подключится.
Точно так же в установке TLS соединения. Ваш browser выступает в роли клиента и ему не нужна серверная лицензия на КриптоПро CSP.
То же самое происходит и с лицензированием КриптоПро JCP/JCSP и JTLS. Для Клиентского ПО, JTLS бесплатно — так утверждают сами сотрудники КриптоПро. JCP так же идет по лицензии клиента.
Я предлагаю всё же разобраться в том, что написано другим человеком.
На самом деле, я хочу вам показать пример реализации с Apache CXF. Здесь нет надобности вообще каким-то образом обрабатывать XML документ. JAXB и JaxWS делают много вещей для вас. Вы используете обычные классы. Далее, поднимаем SOAP клиента на основе WSDL и вкладываем в качестве параметра нужный Java класс.
Вся работа с криптографией, прописывание подписей в XML, извлечение и проверка подписей, это удел Apache CXF. Ваш код должен быть «мягким и пушистым», а не вызывать сложные рефлексы.
Самое основное понимание XML подписи — не надо стремится сохранить текстовое представление документа. В подписи указывается алгоритм нормализации. Он убирает все отступы и упорядочивает названия атрибутов в тегах. Полученная каша, в кодировке UTF-8 поступает в хеш функцию. Значение функции находится в разделе digest. Подпись собирает все эти дайджесты вместе и уже подписывает.
Не в качестве рекламы, а в качестве учебника по работе с надфилем XML-Security Java and MS CryptoIAPI for CXF WS-Security signature. Меня умиляют эти слова о Apache Santuario и код работы с DOM деревом. Apache Santuario — это для XML SAX разбора. Для DOM дерева используется JSR105.
Да, проект опубликован давно, но отнюдь не означает, что он не работает. Там идут JUnit тесты и работаю. Заметьте, работают под Linux и под Windows.
Зачем сражаться с контейнерами закрытых ключей? Покупка КриптоПро CSP по цене соизмерима со стоимостью некой утилиты. И не факт, что она сможет извлечь ключи с аналогов eToken.
Посмотрите на недавно сертифицированную CSP 4.0. Там есть куча компонентов с полюбившимся OpenSSL.
Я не сильно разбираюсь в оптимизации JIT. Разве генерация дополнительного кода не вносит затраты на его исполнение?
Уточню вопрос. Дело в том, что система генерирует байт код для каждого нового DataSource, используя старый код только в виде шаблона.
У меня вопрос. Этот самый пул соединений, он стоит поверх JDBC пула.
Какова производительность этого пула при достижении максимума соединений или запросов в базовом пуле?
Имеется в виду, что остановка некоторых потоков в режиме ожидания новых ресурсов, не влияет на производительность других потоков.
Ведь там используется не честная блокировка (первый запросил, первый получил).
Еще один вопрос можно? Как данный пул можно использовать, скажем в WildFly с исходным XADataSource?
Не в упрек автору данной темы.
Не поленился, сходил на github проекта. Посмотрел код. Я в шоке.
Тут рассказывают о том, как удалось сократить количество JVM инструкций с 35 до 34, забывая про генерацию кода с помощью javassist.
Может кто-то объяснит доходчиво, как динамическое создание класса, с помощью javassist ускоряет работу 34 инструкций перед 35 инструкциями.
Вопрос не по теме. Вы практик или теоретик?
Генрих Форд придумал конвеер, тем самым повысив производительность труда на производстве.
Теперь дело за малым, повторно открыть гениальное открытие или сделать гениальное закрытие.
Получением исходных данных занимается один процесс. Второй, из переменной X не занимается тем же самым. Он делает совсем другую работу. И если эта работа требует больше затрат, читай тактов процессора, тогда можно организовать несколько потоков обработки данных от первого процесса.
Текстовые записи в журналах не однородны. Их так же можно разнести на группы обработчиков.
Получаем, что однородные данные будут обрабатываться за одинаковое количество шагов.
Поскольку данные не однородные, мы получаем разное количество шагов для каждой строки журнала.
Ваша математика рассыпалась на кучу условий если.
Скажу больше. Если в журнале все строки однородные, это уже не журнал, а суть поток однородных данных. И только в этом случае Ваши формулы становятся детерминированными и верными. И даже в этом случае можно применить конвеерную обработку данных.
Применение алгоритмов O(logN) на одном или нескольких участков конвеера даст прирост производительности. Вам понадобится гораздо меньшее количество процессов (автоматов) на этом участке. Высвободившийся ресурс можно задействовать на более тяжелом участке.
Решаем задачу Генриха Форда. Один мастер собирает 1 машину за 1 неделю. 50 мастеров за неделю соберут 50 машин. Маловато. Но для производства 100 машин надо построить еще один цех и нанять еще 50 мастеров. Продолжать?
А по теме ничего путного сказать не смог.
Я что-ли графики показал на всеобщее обозрение?
Там производительность падает. Мне как-то до этого проекта совсем нет дела. Это так, Вам, к сведению,
>> Статья оставляет впечатление недосказанности:
Во-первых, зачем для сервиса накопления и анализа логов Cassandra?
За это ставят плюсы.
>> Линейная зависимость обработки данных от количества обрабатываемых данных, это главная проблема.
За это ставят минусы.
Ставьте еще.
Как только идет неудобная тема, сразу минус.
Мое мнение, попытка авторов проекта была интересная в плане самообучения. Но совсем провальная в плане производительности. Не удивлюсь, если следующая версия этой системы будет от другого производителя.
И честно, тут проблема не в том, используется ли реляционная база данных или нет.
Сумели переложить задачу с одной машины на несколько — «круто», «зачет», «так держать», «дай пять».
Производительность системы тает по линейному закону, а может, даже по экспоненте — полный провал.
Первый график после 57 идет вверх гораздо быстрее — плохо.
Второй график после 71 идет вверх гораздо быстрее — плохо.
Минусы надо ставить автору такой производительности, а не тому, кто вздумал критиковать.
Линейная зависимость обработки данных от количества обрабатываемых данных, это главная проблема.
Если бы была экспонента, было бы очень плохо. А вот логарифм — это то, к чему надо стремиться.
То есть, затраты растут гораздо ниже, чем объем данных. Я по оси X представляю объем данных, а по оси Y объем затрат или время обработки.
Для этого нужно отказываться от последовательной обработки данных.
Пример. У вас на машине 4 ядра.
1) Последовательно берем данные, обрабатываем, отправляем куда-то.
2) Если это не конец данных, возвращаемся к первому пункту.
Итого: у нас занято 1 ядро, а 3 простаивает.
Это не эффективно. Надо организовывать очередь из задач обработки и определять набор обработчиков. Так мы загрузим все 4 ядра и тем самым увеличим скорость обработки данных. У нас уже не получится линейного графика. Он будет больше напоминать логарифмическую кривую. При этом, части получения исходных данных и отправки результата, могут остаться последовательными.
На самом деле, на 4-х ядрах можно использовать несколько десятков обработчиков (потоков).
Ну ни как не получается у меня прямой линии. Что я делаю не так?
Честно, в статье так и сказано. У нас был Oracle и он работал быстро. И вот однажды нам его стало не хватать. Мы решили поставить вместо одного Oracle кучу NoSQL машин. О чудо, система стала быстрее работать. Но чуда нет. Производительность системы растет линейно. Нам нужно поставить еще несколько физически/виртуальных машин.
>> У этой системы был ряд недостатков:
>> Плохая массштабируемость: первой проблемой стала динамика роста регистраций и использование сервисов во всех органах власти.
Вы сократили время обработки одного запроса, но с задачей увеличения производительности не справились.
>> После настройки (fine tuning) Hadoop мы получили такие производительности. Разбор 300 млн строк из Cassandra занимает примерно 100 минут. Построение агрегата на 300 млн записей занимает в среднем 170 мин.
Hadoop — это ваш MapReduce. А вы мне, «График никакого отношения к MapReduce не имеет».
Я всё равно буду стоять на своём, что надо показывать примеры эффективного использования разных конструкций. На практике, бывает настолько не эффективное использование. Например, старый добрый интерфейс итератора. Итератор удаляет пустые строки.
Превращается в поток, фильтр и преобразование в новый список. Красиво — да. Эффективно — нет. Если усложнять задачу, возможно, будет эффективней переход на потоки.
Возвращаясь к оператору for, методу iterate не всегда применим. Скажем, нам нужен бесконечный цикл и выход по некоторому условию. В замыкании нет break, для прерывания цикла и нет return для остановки потока. Или всё это есть?
Переменная i, это не Java Object, а вполне себе, достаточная переменная, внутри стека. Посмотрим на конструкцию
Тут, как минимум, 2 замыкания. Как вы думаете, что быстрее выполнится, просто операция или замыкание, выполняющее эту операцию?
Если уж приводить пример, надо показывать действительно то, что не будет выглядеть на столько бессмысленным.
Это вообще, садизм. Как надо было заоптимизировать цикл for, что бы нативный инкремент регистра процессора стал медленнее stream.
Как и многие, я начинал со Spring и Blueprint.
Не стартовавшие компоненты, висящие в постоянном статусе запуска. Главная причина — отсутствие описания связывания компонентов друг с другом. Есть API сервиса, есть реализация сервиса, есть потребитель. Потребитель стартует раньше и ждет запуска реализации. Подождал и завис. Ни ответа, ни привета.
Неправильная система слежения изменения конфигурации. Создание proxy оболочек над классами не дает воспользоваться новыми свойствами сервиса.
Всё это было. Было мучительно. Перешел на механизм динамических сервисов. Получил набор аннотации org.osgi.service.component.annotations для описания параметров сервиса и описания зависимостей от других сервисов. На уровне framework идет распознание запуска потребителя и реализации.
В потребителе, на уровне активации компонента (@Activate) идет создание и запуск Apache Camel маршрутов. На уровне остановки компонента (@Deactivate) выполняется остановка Apache Camel маршрутов.
Теперь, при изменении настроек реализации сервиса происходит остановка и запуск потребителя.
Если реализация сервиса настроена неправильно, потребитель не запустится и не зависнет в режиме постоянного ожидания, как в Spring DM или Blueprint. Настроил параметры реализация сервиса, потребители стартуют автоматически.
В маршрутах Apache Camel очень часто используются cron. Для профилактических нужд приходится менять расписание доступа к внешним серверам. В конфигурации компонента (Component) меняем параметры cron. Компонент, на уровне изменения (@Modified) производит остановку и запуск Apache Camel маршрутов.
При всех манипуляциях перезапуска маршрутов, система не выкидывает старых процессов обработки данных, давая им время завершится. При этом, новые данные, на стадии остановки, не обрабатываются.
В затрагиваемой технологии микросервисов я так и не нашел решения плавной остановки этих самых микросервисов.
Еще раз ехал с другим местным жителем. Он рассказывал, что довольно часто приходится искать местных с велосипедами в придорожных канавках. Попадет и вылезти не может, пошатается рядом с велосипедом и засыпает. Потом вся улица в деревне пол ночи не спит. Родственники вспоминают о бедолагах, когда уже темно. Пойди, разыщи бедного с фонариками возле дороги. Он ведь и на мобильник не реагирует, так его на солнышке разморило, что к ночи крепко спит.
Хочешь пить, пей, но на велосипед — ни ни.
Местные жители рассказывали, что ГАИ и ГИБДД не отбирали велосипед, а передавали дело участковому. Он то и забирал на пару недель велосипед. А деревенскому жителю без велосипеда ой как тяжело. Надо к остановке идти и деньги платить. Велосипед в деревне — это жизнь.
Сейчас езжу на А образном велосипеде с маленькими колесами, в 16 дюймов. Вот, почти все подряд спрашивают, а где мотор и батарейки. А у меня Garmin показывает каденс 90-120 и скорость 26-32. И ГИБДД на перекрестках смотрит, что за сумасшедший на детских колесах едет. Советуют по зебре на перекрестках переходить.
Подумать только, какой повод для смеха — лишение ТС, велосипеда, и несколько лет нельзя управлять велосипедом, а заодно и личным автомобилем, если он у вас есть.
Я не так уж и часто катаюсь на велосипеде. Тем не менее, сотрудникам ГИБДД иногда интересно поговорить о велосипеде. Иногда, подходят на перекрестках и рекомендуют переходить по зебре, а не ехать. Не дай бог сотрудник заподозрит, что вы выпили.
Удачи вам.
Сам ремень тоже требует ухода. Надо периодически брызгать силиконовой смазкой. Если этого не делать, будет противно скрипеть.
Нельзя делать резких рывков, типа встал на педали и рванул. Тут конечно, сказывается геометрия рамы велосипеда Strida. Но это не самое важное. Хуже, это эффект прострела, как будто твой пистолет дал осечку вместо выстрела.
Еще одна проблема — износ задней звездочки. У меня за 4 года эксплуатации стерлись 4 звёздочки. Последний раз решил купить звездочку из пластика. На момент покупки, в магазине не было звезды из металла.
Износ металла от взаимодействия с ремнем мне понять очень тяжело, так как на машинах ролики не истираются так быстро, как на велосипеде. Может быть, всему виной незащищенность узла от пыли, воды и грязи. В машине, все же, все под капотом.
Износ приводит к необходимости шаговой доступности к магазину запчастей производителя. Ждать 2-3 недели доставки из другого города, это тяжко для велосипедиста.
Что смотреть в этой карточке или USB token? Микроконтроллер. Разве, что, на специальном оборудовании снимать с него стружку. Эти устройства хороши, но очень медленные. Вот, вы, пишите ответ в данной статье. Обмен с сервером идет в зашифрованном протоколе TLS. Теперь, ваш поток мыслей должен пройти через эту карточку / USBToken. После этого, данные уйдут на сервер. Данных не много. А теперь представьте, что этот сервер так же, весь трафик, все HTML статьи, будет гонять через USB Token. Данная технология имеет право на жизнь в некоторых областях применения.
В контейнер можно положить несколько сертификатов. И будет у нас хранилище сертификатов.
Можно положить CRL файлы. Можно положить подписываемое сообщение. Можно положить зашифрованное сообщение.
Отсюда и идут все сложности в понимании.
Да, в самом сертификате есть подпись издателя и сведения о сертификате издателя. Но сам сертификат не является контейнером формата PKCS#7.
Для чтения и записи сертификата и контейнера используется стандарт ASN1.
Отсюда и все сложности на этапе освоения всего этого нагромождения.
То же самое в MQ или JMS. Есть один или несколько серверов, на которые поступают сообщения и они передают их клиентам. Клиент может публиковать сообщения, может забирать корреспонденцию. Но при этом, он остается для шины клиентом.
С точки зрения, вы делаете клиента. Сервер у вас пассивный.
В рамках Java программ, мы создаем сокеты. Для понимания, о чем я говорю, можно посмотреть статью Создаем клиент-сервер на сокетах.
Если вы создаете ServerSocket, это сервер. Если создаете Socket, это клиент.
Теперь представим такую ситуацию. У нас есть SOAP сообщение от клиента. Он подписывает сообщение и отправляет на сервер. Сервер отправляет ответ. Если ответ сервера должен быть подписан, ему нужна серверная лицензия.
Еще раз повторю, что сервис в шине — это клиент.
Он спрашивает у сервера наличие сообщений и получает сообщения в ответ. То что ваш сервис, это клиент, понятно?
После получения ответа, ваше ПО отключается от сервера и может не спеша подготовить ответ на полученное сообщение. После этого, ваш сервис подключается к серверу обмена и передает туда свое сообщение для отправителя исходного сообщения. Получает ответ от сервера, что он получил сообщение. То что ваш сервис — это клиент, понятно?
В чем же главное отличие сервера от клиента? Сервер не может самостоятельно установить соединение с клиентом. А вот, клиент может установить соединение с сервером.
Вам хватит клиентской лицензии на средства криптографии.
Обратите внимание на этот вопрос. Клиенты могут воспринимать вашу систему как сервер. Но ваша система может являться промежуточным звеном на этапе передачи данных во внешнюю систему. Другими словами, вы выступаете инициатором передачи сообщения — вы клиент. Это главное понимание.
Если же ваша система является получателем, вы выступаете в качестве сервера — стоите и слушаете, когда кто-то к вам подключится.
Точно так же в установке TLS соединения. Ваш browser выступает в роли клиента и ему не нужна серверная лицензия на КриптоПро CSP.
То же самое происходит и с лицензированием КриптоПро JCP/JCSP и JTLS. Для Клиентского ПО, JTLS бесплатно — так утверждают сами сотрудники КриптоПро. JCP так же идет по лицензии клиента.
На самом деле, я хочу вам показать пример реализации с Apache CXF. Здесь нет надобности вообще каким-то образом обрабатывать XML документ. JAXB и JaxWS делают много вещей для вас. Вы используете обычные классы. Далее, поднимаем SOAP клиента на основе WSDL и вкладываем в качестве параметра нужный Java класс.
Вся работа с криптографией, прописывание подписей в XML, извлечение и проверка подписей, это удел Apache CXF. Ваш код должен быть «мягким и пушистым», а не вызывать сложные рефлексы.
Самое основное понимание XML подписи — не надо стремится сохранить текстовое представление документа. В подписи указывается алгоритм нормализации. Он убирает все отступы и упорядочивает названия атрибутов в тегах. Полученная каша, в кодировке UTF-8 поступает в хеш функцию. Значение функции находится в разделе digest. Подпись собирает все эти дайджесты вместе и уже подписывает.
Я извиняюсь, если не совсем доходчиво объясняю.
Да, проект опубликован давно, но отнюдь не означает, что он не работает. Там идут JUnit тесты и работаю. Заметьте, работают под Linux и под Windows.
Зачем сражаться с контейнерами закрытых ключей? Покупка КриптоПро CSP по цене соизмерима со стоимостью некой утилиты. И не факт, что она сможет извлечь ключи с аналогов eToken.
Посмотрите на недавно сертифицированную CSP 4.0. Там есть куча компонентов с полюбившимся OpenSSL.
Уточню вопрос. Дело в том, что система генерирует байт код для каждого нового DataSource, используя старый код только в виде шаблона.
У меня вопрос. Этот самый пул соединений, он стоит поверх JDBC пула.
Какова производительность этого пула при достижении максимума соединений или запросов в базовом пуле?
Имеется в виду, что остановка некоторых потоков в режиме ожидания новых ресурсов, не влияет на производительность других потоков.
Ведь там используется не честная блокировка (первый запросил, первый получил).
Еще один вопрос можно? Как данный пул можно использовать, скажем в WildFly с исходным XADataSource?
Не поленился, сходил на github проекта. Посмотрел код. Я в шоке.
Тут рассказывают о том, как удалось сократить количество JVM инструкций с 35 до 34, забывая про генерацию кода с помощью javassist.
Может кто-то объяснит доходчиво, как динамическое создание класса, с помощью javassist ускоряет работу 34 инструкций перед 35 инструкциями.
Генрих Форд придумал конвеер, тем самым повысив производительность труда на производстве.
Теперь дело за малым, повторно открыть гениальное открытие или сделать гениальное закрытие.
Получением исходных данных занимается один процесс. Второй, из переменной X не занимается тем же самым. Он делает совсем другую работу. И если эта работа требует больше затрат, читай тактов процессора, тогда можно организовать несколько потоков обработки данных от первого процесса.
Текстовые записи в журналах не однородны. Их так же можно разнести на группы обработчиков.
Получаем, что однородные данные будут обрабатываться за одинаковое количество шагов.
Поскольку данные не однородные, мы получаем разное количество шагов для каждой строки журнала.
Ваша математика рассыпалась на кучу условий если.
Скажу больше. Если в журнале все строки однородные, это уже не журнал, а суть поток однородных данных. И только в этом случае Ваши формулы становятся детерминированными и верными. И даже в этом случае можно применить конвеерную обработку данных.
Применение алгоритмов O(logN) на одном или нескольких участков конвеера даст прирост производительности. Вам понадобится гораздо меньшее количество процессов (автоматов) на этом участке. Высвободившийся ресурс можно задействовать на более тяжелом участке.
Решаем задачу Генриха Форда. Один мастер собирает 1 машину за 1 неделю. 50 мастеров за неделю соберут 50 машин. Маловато. Но для производства 100 машин надо построить еще один цех и нанять еще 50 мастеров. Продолжать?
Я что-ли графики показал на всеобщее обозрение?
Там производительность падает. Мне как-то до этого проекта совсем нет дела. Это так, Вам, к сведению,
Во-первых, зачем для сервиса накопления и анализа логов Cassandra?
За это ставят плюсы.
>> Линейная зависимость обработки данных от количества обрабатываемых данных, это главная проблема.
За это ставят минусы.
Ставьте еще.
Как только идет неудобная тема, сразу минус.
Мое мнение, попытка авторов проекта была интересная в плане самообучения. Но совсем провальная в плане производительности. Не удивлюсь, если следующая версия этой системы будет от другого производителя.
И честно, тут проблема не в том, используется ли реляционная база данных или нет.
Сумели переложить задачу с одной машины на несколько — «круто», «зачет», «так держать», «дай пять».
Производительность системы тает по линейному закону, а может, даже по экспоненте — полный провал.
Первый график после 57 идет вверх гораздо быстрее — плохо.
Второй график после 71 идет вверх гораздо быстрее — плохо.
Минусы надо ставить автору такой производительности, а не тому, кто вздумал критиковать.
Если бы была экспонента, было бы очень плохо. А вот логарифм — это то, к чему надо стремиться.
То есть, затраты растут гораздо ниже, чем объем данных. Я по оси X представляю объем данных, а по оси Y объем затрат или время обработки.
Для этого нужно отказываться от последовательной обработки данных.
Пример. У вас на машине 4 ядра.
1) Последовательно берем данные, обрабатываем, отправляем куда-то.
2) Если это не конец данных, возвращаемся к первому пункту.
Итого: у нас занято 1 ядро, а 3 простаивает.
Это не эффективно. Надо организовывать очередь из задач обработки и определять набор обработчиков. Так мы загрузим все 4 ядра и тем самым увеличим скорость обработки данных. У нас уже не получится линейного графика. Он будет больше напоминать логарифмическую кривую. При этом, части получения исходных данных и отправки результата, могут остаться последовательными.
На самом деле, на 4-х ядрах можно использовать несколько десятков обработчиков (потоков).
Ну ни как не получается у меня прямой линии. Что я делаю не так?
Честно, в статье так и сказано. У нас был Oracle и он работал быстро. И вот однажды нам его стало не хватать. Мы решили поставить вместо одного Oracle кучу NoSQL машин. О чудо, система стала быстрее работать. Но чуда нет. Производительность системы растет линейно. Нам нужно поставить еще несколько физически/виртуальных машин.
>> У этой системы был ряд недостатков:
>> Плохая массштабируемость: первой проблемой стала динамика роста регистраций и использование сервисов во всех органах власти.
Вы сократили время обработки одного запроса, но с задачей увеличения производительности не справились.
>> После настройки (fine tuning) Hadoop мы получили такие производительности. Разбор 300 млн строк из Cassandra занимает примерно 100 минут. Построение агрегата на 300 млн записей занимает в среднем 170 мин.
Hadoop — это ваш MapReduce. А вы мне, «График никакого отношения к MapReduce не имеет».