SodaWater
Григорий Федорахин

Отличный вебинар, докладчики (как всегда) на 5+.
Из минусов - глючный микрофон, с которым я например так и не смог совладать, когда звук пропадает не сразу замечаешь. Потом с удивлением смотрел как Доржи (левым мизинцем)) нажимал эту глючную кнопку и звук шёл как надо - опыт однако.
Может ведущим фиксировать вопросы чата и зала, а потом самим задавать? Думаю будет гораздо эффективнее, особенно для чата.
А если по теме, то пытался донести до Алексея мысль, что дело не в Git или хранилище. Идеальный мир ИТ директора - это несколько систем(желательно от 1-2вендоров) с контрактами(лучше enterprise), в датацентре с пятью девятками, мониторингом с sms уведомлениями, поминутным планом восстановления в случае сбоя. Сверху к этому прикручены системы от утечек, дурака и всего остального )
И когда начальник разработки придёт к нему с новой схемой - отдельной cvs, то он будет отправлен "за огнивом", где сперва встретит 3-собак с глазами как чашки(разработчики), потом как мельничные колёса (админы) и последнее животное (не помню с чем) это СБ. Это я про разработку в крупном заказчике, у франчей думаю, зоопарк меньше.
Как "ERP -это не софт", так и Git - это ни разу не управление релизами, как процесс, а лишь малая его часть.
Вот когда "припрут" с внедрением процессов (изменения, релизы, конфигурации) , тогда и тема будет актуальна.
Ну это только моё "оценочное суждение" )

(19) V.Nikonov, Это не совсем так. Есть такие правила ACID Wiki, которые придуманы еще в 70-х, но уверен соблюдаются в SQL серверах по сей день. Например у нас есть 2 базы - одна в 10раз больше чем объем ОЗУ, а другая в 10раз меньше ОЗУ. Если мы сделаем UPDATE 10000 записей, то нагрузка на дисковую в обеих базах будет сравнима. SQL серверу надо сначала записать все эти изменения в LOG, а потом уже в базу(на диске) и в память. При запуске этого теста на наших серверах очень хорошо видно как SQL сервер начинает проседать под нагрузкой и от размера базы это не сильно зависит. Другое дело, если тестить только чтение(%записи=0). На базе, которая влезла в память будет более высокий результат.

(17) V.Nikonov, размер пока фиксированный и зависит от выбранного кол-ва клиентов. Если размер БД необходимо менять, то можно сделать в след. версии. Хотя это имеет смысл только при проценте записи=0..3%, т.к. при проценте от 5 и выше SQLсерверу и так тяжко(даже если БД влезает в память).
Симбиоз не планировал. Причина в том, что тест задуман как замер производительности. Мне хотелось опуститься на уровень ниже и максимально абстрагироваться от конкретной конфигурации. Иначе это будет "тест кода" со всеми его плюшками в виде блокировок и т.д. В текущей версии каждый "клиент" изолирован и вероятность блокировок очень мала.

(15) sanfoto,
Возможно такие обработки(летящие в инет без предупреждения) тут есть. Эта точно не такая. Мне уже много лет, а с годами приходит не только маразм ), но и понимание того, что репутацию нельзя купить, а прос..ть можно за минуту. Всем понятно, что закрытый код это фикция, но в свою очередь готов предоставить исходники по запросу(контакты есть на форме обработки), если случится острая жизненная необходимость.

Олег, спасибо за подробный обзор! Сами сейчас в процессе выбора системы, перебираем примерно такой же список. Больше всего удивили представители от Инталев. Свою презентацию начали с предупреждения, что они работают с фирмами, чей оборот от 5ярдов/год и видимо у вас есть такие деньги. Консультант не смог приехать на заранее запланированную встречу (типа очень занят). Представители БиТа и УКФ все подробно показали и ответили на все вопросы, дали ключи/доступ для "посмотреть".

(7) sanfoto, не, не так ) "давайдосвидания" )) Александр, видимо для тестирования дисков,памяти,процессоров, Вы используете только тесты с открытым кодом. В любом случае, спасибо за отклик.

(9) KV1s, Методика проста - берем конкретный сервер1С и SQL и гоняем тест, получаем средний результат. Берем другой(ие) сервер1С и SQL и гоняем тест не меняя настроек. Сравниваем полученные результаты. Код простой до безумия - прербираем объекты БД(имитация чтения) и в части из них изменяем данные и записываем в БД. Открою код, когда будут аналоги таких тестов для 1С(СНТ не в счет там другие задачи). В идеале такой тест должен быть отдельной программой, но в связке с 1С этот вопрос труднореализуемый, потому и написано в рамках платформы.

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

(4) Confucius, если просто запустить 1 раз, то ничем не поможет. Как минимум надо запускать 2 раза на разном железе или при разных настройках(железа, SQL, сервера 1С), не меняя при этом настройки теста. Можно запускать на 1 сервере несколько раз, меняя процент записи - мне это помогло понять, где уже SQL начинает притормаживать.

(5) tolyan_ekb, Спасибо! видимо отвалились в процессе публикации. Сейчас прицеплю.