Если интересно, посмотрите "кино" о том как это было:
1. Получили доступ в машину через кодграбер (10 сек) — из-за работы кодграбера как раз «Он только запомнил, что пришлось несколько раз на кнопку постановки сигнализации жать»
2. После доступа в салон был прописан или свой имобилайзер, или использована свежая дырка Toyota и код имобилайзера был просто «считан» (10-30 сек)
Есть третья дырка — ретранслятор, который используется при Keyless доступе к авто, но судля по цитате из п.1 она тут не использовалась
Нет, на самом деле сейчас этим никто не занимается.
В статье вскользь указано про подключение к внутренним шинам управления авто через разъем OBD.
В большинстве случаев этого достаточно, чтобы прописать свой собственный имобилайзер с известной парой ключей. Обычно на это требуется 30-90 сек при свободном доступе к колодке OBD и другим блокам управления.
Для тестирования 1с в режиме многопоточности то же есть тест Многопоточный тест производительности 1с
Прикольно, попробую…
Жаль, что в отличие от Гилева в таблице на сайте не приводятся конфигурации серверов, на которых проводились испытания.
И вторая проблема — непонятно значение столбцов «Сумма одного потока» и «Сумма 96 потоков», точнее очень удивляет тот факт что эти значения не коррелируют между собой (при схожих значениях одного столбца большой разброс значений во втором столбце и наоборот)
1. Тест Гилева однопоточный — т.е. он показывает, грубо говоря, как быстро будет работать связка БД<=>1с-сервер<=>1с-клиент для одного сферического клиента в вакуме.
Этот тест предназначен для сравнения разного железа в одинаковых конфигурациях и не очень подходит для сравнения разных решений на одном железе.
Простой пример: на файловой базе тест Гилева дает, в среднем, в 4 раза более высокие результаты, чем _любое_ решение с реляционной БД, но в реальных условиях, когда количество пользователей > 3, за счет более высоких накладных расходов на блокировки, решение с файловой базой очевидно проигрывает решению с реляционной БД
2. К сожалению, 1с для PostgreSQL — несет так же более высокие накладные расходы на блокировки, чем решение 1c для MS SQL Конкретно: если с MS SQL, 1c-сервер как правило накладывает блокировки уровня строки или row range (как лучше сказать — набор строк?), то в случае с PostgreSQL 1c-сервер накладывает, как правило, блокировки на всю таблицу.
По этому, в теории, решение 1с+MS SQL в многопользовательском режиме будет всегда более производительно, чем решение 1c+PostgreSQL (и это не проблема PostgreSQL, а проблема того, как 1с работает с PostgreSQL).
Как жаль, что автор сравнивая разные решения на одинаковом железе решил использовать тест Гилева, а не тесты из 1с: КИП или другие многопоточные тесты, и, тем самым, не дал ответ на вопрос, на сколько сильно решение Linux+PostgreSQL+1c будет отставать от Win+MSSQL+1c в реальных конфигурациях для 5-20-50-100 пользователей
1. Получили доступ в машину через кодграбер (10 сек) — из-за работы кодграбера как раз «Он только запомнил, что пришлось несколько раз на кнопку постановки сигнализации жать»
2. После доступа в салон был прописан или свой имобилайзер, или использована свежая дырка Toyota и код имобилайзера был просто «считан» (10-30 сек)
Есть третья дырка — ретранслятор, который используется при Keyless доступе к авто, но судля по цитате из п.1 она тут не использовалась
В статье вскользь указано про подключение к внутренним шинам управления авто через разъем OBD.
В большинстве случаев этого достаточно, чтобы прописать свой собственный имобилайзер с известной парой ключей. Обычно на это требуется 30-90 сек при свободном доступе к колодке OBD и другим блокам управления.
Прикольно, попробую…
Жаль, что в отличие от Гилева в таблице на сайте не приводятся конфигурации серверов, на которых проводились испытания.
И вторая проблема — непонятно значение столбцов «Сумма одного потока» и «Сумма 96 потоков», точнее очень удивляет тот факт что эти значения не коррелируют между собой (при схожих значениях одного столбца большой разброс значений во втором столбце и наоборот)
1. Тест Гилева однопоточный — т.е. он показывает, грубо говоря, как быстро будет работать связка БД<=>1с-сервер<=>1с-клиент для одного сферического клиента в вакуме.
Этот тест предназначен для сравнения разного железа в одинаковых конфигурациях и не очень подходит для сравнения разных решений на одном железе.
Простой пример: на файловой базе тест Гилева дает, в среднем, в 4 раза более высокие результаты, чем _любое_ решение с реляционной БД, но в реальных условиях, когда количество пользователей > 3, за счет более высоких накладных расходов на блокировки, решение с файловой базой очевидно проигрывает решению с реляционной БД
2. К сожалению, 1с для PostgreSQL — несет так же более высокие накладные расходы на блокировки, чем решение 1c для MS SQL Конкретно: если с MS SQL, 1c-сервер как правило накладывает блокировки уровня строки или row range (как лучше сказать — набор строк?), то в случае с PostgreSQL 1c-сервер накладывает, как правило, блокировки на всю таблицу.
По этому, в теории, решение 1с+MS SQL в многопользовательском режиме будет всегда более производительно, чем решение 1c+PostgreSQL (и это не проблема PostgreSQL, а проблема того, как 1с работает с PostgreSQL).
Как жаль, что автор сравнивая разные решения на одинаковом железе решил использовать тест Гилева, а не тесты из 1с: КИП или другие многопоточные тесты, и, тем самым, не дал ответ на вопрос, на сколько сильно решение Linux+PostgreSQL+1c будет отставать от Win+MSSQL+1c в реальных конфигурациях для 5-20-50-100 пользователей