После появления сертифицированной версии КриптоПро CSP 5.0 мы получили обращения от клиентов, что при использовании некоторых носителей КриптоПро CSP “зависает” примерно на 30 секунд в процессе поиска и перечисления присутствующих контейнеров.
Мы обратились в службу технической поддержки КриптоПро с данной проблемой, которая дала рекомендацию отключить работу КриптоПро CSP 5.0 с активными носителями путем создания параметра в реестре.
Проблема быстродействия таким образом решилась, но при этом все остальные программы потеряли возможность работать с некоторыми функциональными ключевыми носителями.
В итоге мы сами нашли иное решение, не мешающие другим программам использовать КриптоПро CSP.
Этот параметр никаким образом не влиял на безопасность закрытого ключа и возможность его копирования. Тип ключа — экспортируемый или неэкспортируемый определяет его владелец в момент формирования запроса на сертификат.
Предположение о том, что закрытый ключ куда-то копируется является не более чем домыслом.
Нет, ClickHouse не подымали через ZooKeper. Сначала сделали кластер из двух узлов, потом отдельно к каждому узлу обращались. Вариант с кластером был медленнее.
А почему должен помочь индекс включающий больше колонок?
Если мне нужно выбрать по датевремени и названию запроса, или по датевремени и названию сервиса, то очевидно тут разные индексы нужны. Ибо в этом случае индекс из трех колонок:
сервис, название запроса, дата время
будет точно работать неэффективно для запросов обоих видов.
А нам в радость рассказать об этом. В ближайшее время удаленный помощник портируется на linux и os x системы. Дальнейшее развитие проекта еще на стадии обсуждения.
Про СБИС Плагин — это, конечно, не по теме статьи, однако могу лишь намекнуть, что разрабатывается его новая реализация. Надеюсь, вы оцените! ;)
К сожалению, до полноценного TCP дойти точно не удастся, т.к. вся нагрузка по гарантии доставки и очередности сборки пакетов лежит все-таки на приложении, а не драйвере.
Бенчмарки чего? Самой системы управления? Или установки соединения? Если вопрос касается только установки соединения — не более пары секунд, в зависимости от канала.
Если говорить о качестве самой работы, то очень многое зависит от клиентского аппаратного обеспечения. Но в среднем достаточно комфортно.
Если я не ошибаюсь, сеть DHT подразумевает наличие постоянно запущенного приложения. В наших реалиях — средство управление запускается по мере необходимости оказать или получить помощь.
Плюс торрентоподобные сети подразумевают возможность ретрансляции трафика через других участников сетей. Уверен клиентам это понравилось бы.
Ну и да, как отметили чуть выше, STUN или аналогичный способ определения своего внешнего IP все же необходим.
Спасибо за комментарий. Конечно, юнит-тесты не являются серебряной пулей, способной излечить все проблемы проекта. Но их использование в процессе разработки способствует созданию прочного фундамента, позволяющего поддерживать и развивать долгосрочные проекты. А тестирование совместной работы модулей, как вы справедливо заметили, это уже задача следующего уровня — интеграционных, нагрузочных, функциональных и прочих-прочих-прочих тестов :)
В принципе, в приведенном примере так, конечно, сделать можно. Но в этом случае, при работе над реальным проектом в перспективе может возникнуть ряд сложностей, связанных с поддержкой тестов, а также читабельностью кода боевого класса.
Немножко поутрирую. Например, пусть у нас есть класс, обладающий внешними зависимостями в количестве 100 штук, а для создания боевой версии объекта используется конструктор с 5 параметрами, часть из которых также задается по умолчанию. В таком случае, человеку, который разбирается с нашим кодом, придется потратить определенное количество времени, чтобы понять, какие из 105 параметров нужны для боевой версии, а какие — для тестирования. А если сроки горят, то все совсем нехорошо складывается. Так вот, чтобы избежать потенциальной агрессии с его стороны, все-таки рекомендуется разграничивать предназначения конструкторов, что и было сделано в указанном примере)
Спасибо за комментарии. Вы правы, можно применять GoogleMock для автоматизированного создания Mock-объектов. Но, как было сказано ранее, к числу важнейших характеристик хорошего юнит-теста следует отнести его читабельность, а также легкость его дальнейшей модификации и поддержки. Возможно, с помощью GoogleMock Mock-объекты можно быстрее создавать, но в дальнейшем, по моему опыту, тесты, их использующие, сложнее читать и тем более поддерживать.
Таким образом, в примерах, представленных в статье, GoogleMock намеренно не использовался, чтобы не усложнять рассказ о принципах создания тестируемого кода.
Касательно применения EXPECT_XXX и ASSERT_XXX. Как было сказано в статье, одна из рекомендаций заключается в том, чтобы использовать в каждом тесте только один assert. В этом случае, если сработал assert, то можно однозначно определить root case — найти причину его непрохождения.
Спасибо за отклик на статью. Вы правы, можно сделать проще. Но при написании тестов и соответствующего тестируемого кода нельзя выделить один путь, который является единственно верным. Как правильно, на мой взгляд, в своей книге отметил Roy Osherove, написание юнит-тестов — это есть искусство. Следует развивать умение чувствовать в каком случае и как лучше поступить. Возвращаясь к статье, мне хотелось показать основные принципы работы с fake-объектами, поэтому и был приведен указанный вами тест.
Спасибо за комментарии к приведенным примерам. Насчет указанных Вами замечаний хотел бы сказать следующее.
1. Вы правы, что крайне желательно писать тесты, которые понятны для чтения и прозрачны для понимания.
Однако при написании тестируемого кода мы, по сути, создаем его для еще одного пользователя — наших тестов. В указанном вами примере всю ответственность за создание необходимых для выполнения программы объектов мы возлагаем на фабрику. Это позволяет разграничить нам зоны ответственности классов. Но в этом случае для написания теста нам следует привести тестируемые объекты в требуемое состояния, что и является целью выполнения этапа Arrange.
2. В зависимости от особенностей архитектуры тестируемого класса, описанная вами ситуация потенциально, конечно, может возникнуть. Но если вы знаете такие архитектурные особенности, то целиком в вашей власти разорвать в тестируемом классе зависимость от БД полностью. В противном случае, как вы справедливо заметили, написанный тест будет взаимодействовать с реальной БД, что не даст ему права являться хорошим юнит-тестом.
Спасибо за положительный отзыв! Очень рад, что вы нашли статью для себя полезной. Действительно, и я тоже на это надеюсь, она способна развить желание писать надежный тестируемый код.
Отсутствие серьезного выигрыша по месту хранения, устроило бы >50%. На самом деле мы еще не оставили до конца опыты с ClickHouse, но с ним мы все-таки несколько в тупике.
Там конечно не 32 Тб текста. 32Тб это данные + индексы. Индексы это где-то 50%. Т.е. на данные 16Тб. Из них текст составляет около 40% от других данных, т.е. на него тратится < 8Тб. Без текста трассировка была бы бесполезна, поиск по части текста довольно распространенное явление.
Насчет удобства в сравнении с другими системами — наша очевидно удобнее в плане интерфейса чем GrayLog2. Имею счастье пользоваться обеими.И наша существенно сильнее заточена на нашу специфику.
Да, фактически для логов мы Postgres не используем как SQL базу. Но меня, например, поразило, что он существенно менее требователен к памяти, чем Elastic и ClickHouse.
С Elastic нам все понравилось, он тратит меньше IOPs на запись, несколько побыстрее отдает ответ, но как написано в статье, не устроило, что он выигрыш по месту хранения дал маленький. Это основная причина почему мы на него пока стремимся перейти.
Мы обратились в службу технической поддержки КриптоПро с данной проблемой, которая дала рекомендацию отключить работу КриптоПро CSP 5.0 с активными носителями путем создания параметра в реестре.
Проблема быстродействия таким образом решилась, но при этом все остальные программы потеряли возможность работать с некоторыми функциональными ключевыми носителями.
В итоге мы сами нашли иное решение, не мешающие другим программам использовать КриптоПро CSP.
Этот параметр никаким образом не влиял на безопасность закрытого ключа и возможность его копирования. Тип ключа — экспортируемый или неэкспортируемый определяет его владелец в момент формирования запроса на сертификат.
Предположение о том, что закрытый ключ куда-то копируется является не более чем домыслом.
А почему должен помочь индекс включающий больше колонок?
Если мне нужно выбрать по датевремени и названию запроса, или по датевремени и названию сервиса, то очевидно тут разные индексы нужны. Ибо в этом случае индекс из трех колонок:
сервис, название запроса, дата время
будет точно работать неэффективно для запросов обоих видов.
Про СБИС Плагин — это, конечно, не по теме статьи, однако могу лишь намекнуть, что разрабатывается его новая реализация. Надеюсь, вы оцените! ;)
Если говорить о качестве самой работы, то очень многое зависит от клиентского аппаратного обеспечения. Но в среднем достаточно комфортно.
Плюс торрентоподобные сети подразумевают возможность ретрансляции трафика через других участников сетей. Уверен клиентам это понравилось бы.
Ну и да, как отметили чуть выше, STUN или аналогичный способ определения своего внешнего IP все же необходим.
Немножко поутрирую. Например, пусть у нас есть класс, обладающий внешними зависимостями в количестве 100 штук, а для создания боевой версии объекта используется конструктор с 5 параметрами, часть из которых также задается по умолчанию. В таком случае, человеку, который разбирается с нашим кодом, придется потратить определенное количество времени, чтобы понять, какие из 105 параметров нужны для боевой версии, а какие — для тестирования. А если сроки горят, то все совсем нехорошо складывается. Так вот, чтобы избежать потенциальной агрессии с его стороны, все-таки рекомендуется разграничивать предназначения конструкторов, что и было сделано в указанном примере)
Таким образом, в примерах, представленных в статье, GoogleMock намеренно не использовался, чтобы не усложнять рассказ о принципах создания тестируемого кода.
Касательно применения EXPECT_XXX и ASSERT_XXX. Как было сказано в статье, одна из рекомендаций заключается в том, чтобы использовать в каждом тесте только один assert. В этом случае, если сработал assert, то можно однозначно определить root case — найти причину его непрохождения.
1. Вы правы, что крайне желательно писать тесты, которые понятны для чтения и прозрачны для понимания.
Однако при написании тестируемого кода мы, по сути, создаем его для еще одного пользователя — наших тестов. В указанном вами примере всю ответственность за создание необходимых для выполнения программы объектов мы возлагаем на фабрику. Это позволяет разграничить нам зоны ответственности классов. Но в этом случае для написания теста нам следует привести тестируемые объекты в требуемое состояния, что и является целью выполнения этапа Arrange.
2. В зависимости от особенностей архитектуры тестируемого класса, описанная вами ситуация потенциально, конечно, может возникнуть. Но если вы знаете такие архитектурные особенности, то целиком в вашей власти разорвать в тестируемом классе зависимость от БД полностью. В противном случае, как вы справедливо заметили, написанный тест будет взаимодействовать с реальной БД, что не даст ему права являться хорошим юнит-тестом.