Странноватый тест от Sybase. По сравнению с Oracle и MSSQL была сильно слабей и/o, думаю это главная причина столь слабенького результата, в несколько раз отстающего от лидеров Oracle & MSSQL на сравнимом одно-процессорном железе. Еще одна странность - результат был опубликован в уже устаревшем TPC-C, а не в его заменившем TPC-E.
Sybase ASA позиционируется как небольшая субд рабочих групп с хорошим price/performance, одна при таком результате price/performance на транзакцию тоже вышел не впечатляющим.
Подробнее.
Подписаться на:
Комментарии к сообщению (Atom)
32 комментария:
а еще есть первый тест 1С
тоже забавная штука http://www.gilev.ru/1c/tpc
мысль конечно здравая, но имхо толжен быть некий независимый Council проверяющий достоверность результатов.
я ничерта не знаю про 1С, но как то закрадываются сомнения, что обработка 500 документов на нормальной технике создаст адекватную нагрузку. даже на ентри левел сервере они явно уместятся в оперативную память ...
увеличить количество документов можно хоть до миллиона
но технику для ентерпрайз рынка надо тестировать не умещение в кэше, готовиться к выпуску два дополнительных теста
но в любом случаи, в тесте важна не корреляция с tcp.org
а сама возможность бесплатного теста без каких либо знаний - все одной кнопкой и минимум установки и настройки
имхо, если уж делать, то скорее ориентироваться на SAP-SD. размер бд расчитывать от кол-ва пользователей. нагрузка микс OLTP и аналитических пользователей ну и прочие нюансы. а тут к стате не понятно даже сколько пользователей молотят ити документы. надеюсь не один ?
если поделитесь общей идеей алгоритма SAP-SD, то скорее всего она также будет реализована
>стате не понятно даже сколько пользователей молотят ити документы
как раз тут все понятно TPC-A-local Throughput - делал по спецификации теста А, локально
для многопользовательского режима другие задачи стоят, они уже реализованы в другом тесте http://v8.1c.ru/expert/tc/tc_overview.htm Сценарий "Продажи в конфигурации "Управление производственным предприятием"
в настоящее время прорабатывается тест не привязанный к приложению (руки кодера испоганят что угодно), а к платформе - будет оценивать максимальный порог "падения производительности" и максимальных параметров системы без падения производительности
где-то на ITblogs Елашкин выкладывал его статью о SAP бенчмарках, но с налету ссылку не нашел, попробую у себя в архиве поискать.
Кроме SAP я бы покапал Oracle Apps (http://www.oracle.com/apps_benchmark/html/description.html) и Siebel (http://itblogs.ru/blogs/worldnews/archive/2007/08/27/20185.aspx). Насколько я помню идея была у всех примерно одинакова: например на каждых 5 продавцов добавляется человек работающий со складом, а на каждые 20 бухгалтер. Начальный размер базы данных зависит от кол-ва пользователей, заявленых в тесте. Тест считается пройденым если респонс тайм каждого пользователя укладывается в некое время. в oracle apps помоему еще есть батч нагрузка.
что я думаю:
>Насколько я помню идея была у всех примерно одинакова: например на каждых 5 продавцов добавляется человек работающий со складом, а на каждые 20 бухгалтер.
Откуда такие цифры 5, 20 - у каждой компании это собственные цифры - получается что надо тест делать плавающим по количеству, но тогда бесмысленно сравнивать разные по количеству даже на 1го пользователя
> Начальный размер базы данных зависит от кол-ва пользователей, заявленых в тесте.
Тоже странный подход. Допустим я занимаюсь паевыми фондами. У меня информация в базе коррелирует от опираций конкретного клиента (не пользователя системы, а просто неких данных за период).
И потом, как можно делать корреляцию между количеством пользователей и объемом базы? Понятно, что один пользователь в день например вбивает 100 документов, тогда 10 пользователей в день должны вбивать в сумме 1000 документов, а значит и объем данных базы примерно тоже в 10 раз должен быть увеличен. Но тогда возвращаемся к исходной проблеме. Какая разница, сколько пользователей, ведь они не вбивают одинаково 100 документов, и даже усреднять нельзя, ведь это может быть разная бизнес-логика у документов.
Возможно я недавно занимаюсь тестами. Но очень хотелось бы сделать именно ПОЛЕЗНЫЙ тест.
цифры я взял с потолка, просто помню, что в Oracle Apps на пять продавцов кого-то добавляли. Понятно, что у каждой канторы будут разные клиенты, но вот оракл проведя исследование своих клиентов, что в среднем распределение нагрузки вот такое. Каждый пользователь открывает новый экран каждые 10 секунд. Задача тестов на сайзинг - нагрузка как можно близкая к среднестатистической компании. Я в свою очередь с ними согласен, такая нагрузка больше соответсвует реальности, чем один поток, без задержек перемалывающий документы.
На счет бизнес логики, да SAP понаделал с десяток разных тестов разных модулей, от Human Resources до Transaction Banking. Однако большинство вендоров на них забили и используют лишь Sales and Distribution как универсальный.
>оракл проведя исследование своих клиентов, что в среднем распределение нагрузки вот такое.
Очень удобная формулировка, когда нет ответов. Среднестатистическая картина компаний может и есть, а вот нужды у каждой компании в тестах не статистические, тогда бы тесты были не нужны, один раз подобрать конфигурацию и продавать всем.
>больше соответсвует реальности
ну тут должн быть критерии соответствия реальности
я специально указал точность TCP теста и специализированных тестов
ИМЕННО ДЛЯ 1С
задачи специализированных тестов отражены задачами конкретных проектов и такие я делаю за деньги
однако для такого, чтобы ответить заказчку предварительно, жизнь показала, что моего теста до обследования компании более чем достаточно, так как WORKLOAD до этого момента либо заказчик сам не знает (т.е. этот проект еще не реализован), либо у заказчика уже есть реальные проблемы, раз он обращаеться за помощью, и тогда задача сводиться не к TCP тесту, а 1) разбирательству - виновато железо или код
2) если код, то это нас сейчас это не касается, а если железо, то на сколько нужно лучше новое, и тут TCP как ни смешно реально поможет даже под одного запущенного пользователя
все выше сказанное не как религиозные убеждения, а текущее понимании ситуации
готов к возражениям
Yo, почитайте коментарий одного из ведущих разработчиков SA на эту тему:
http://sqlanywhere.blogspot.com/2008/08/sql-anywhere-11-makes-top-ten-tpc-c.html
я плохо понимай по англицки, но слово "абсурд" уловил :)))
конечно, тесты ведущих производителей не предоставляют нужной прозрачности, а посему вызывают мало доверия
в этом смысле мой тест прозрачен любому 1С-программисту - он открыт и туп как валенок
более того, уважаемые вендоры умудрились все как один совершить страшную ошибку - не проранжировали изменяемые параметры в порядке приоритета (и иерархии)
оракл вообще делает начальную колибровку теста от 5 Gb данных вместо того, чтобы померить RAM тестируемой СУДБ
дальше разбирать просто грусто и жалко свое время
:(
2Вячеслав
Не совсем понял, чем вам так среднестатическая нагрузка не нравится, но посмотрите, что получается с вашим тестом: прогнав его я не могу предположить как масштабируется моя конфигурация. может при сотне юзеров у меня получится та же картина, один пользователь залочит всю таблицу документов и будет один их обрабатывать, а все остальные 99 сидеть и ждать снятия блокировки. имхо, одно из главных задач сайзинга именно ответ на вопрос как масштабируется конфигурация. тем более, что у 1С репутация на эту тему версией 7 подмочена основательно.
>Не совсем понял, чем вам так среднестатическая нагрузка не нравится
это средняя температура по больнице, если будет понятней
одни присмерти, другие здоровые, а средне скажем 37,9
так и оракл, вместо внятных изменений параметров, сократили тест до взятых с потолка (а нуда взятых с потолка лучшими методистами оракла) цифр, так что ничего личного
>с вашим тестом: прогнав его я не могу предположить как масштабируется моя конфигурация
конечно не можете, потому что наверно даже по ссылке не ходили http://www.gilev.ru/1c/tpc
тест выполняется для оценки WORKLOAD монопольного потока, тест не решает задачу применимости конкретного приложения в многопоточном режиме
> а все остальные 99 сидеть и ждать снятия блокировки
последствие правильно замечено - в многопользовательском режиме ключевым становиться влияние блокировок
уверен, что вы не владете кухней 1С, но поверьте наслово, что блокировки в 1С будут очень сильно зависит от кода конфигурации (это не тестируемый мной код платформы) - это совершенно разные объекты тестирования, если угодно!!!
К тому же уже говорил, что для тестов конфигураций куда целесообразней специализированные тесты.
>одно из главных задач сайзинга именно ответ на вопрос как масштабируется конфигурация.
вот на этот вопрос (если конечно почестному) TPC тесты точно не способны ответить, если конечно не подходить к этому вопросы "философски" :))
>тем более, что у 1С репутация на эту тему версией 7 подмочена основательно.
а здесь в Вас видимо проснулся тот же "червячок", что и Елашкина, когда он в своей книге (свежей) про САП любит сравнить с 7.7, а не с 8.1
ну да ладно, здесь у меня претензий нет, у каждого свои слабости :)
p.s. тем не менее планирую воевать с ветрянными мельницами
многие из воспользовавшихся хотят тоже увидеть тест для многопользовательского режима
поставил вопрос на голосование переде коллегами - что тестировать 8.1 как существующую в промышленном варианте или 8.2 которая уже начинается в виде пилотных проектов у заказчиков
после принятия решения о версии, видимо последует поистине "адский" тест :)))
2alexeyk77
Ну для меня ничего не прояснилось. Что им помешало засунуть еще 40 дисков ? Факты говорят о том, что при в три раза более слабой и/о подсистеме ASA показал в три раза худший результат, сильно уступив даже в price/performance.
т.е. на вопрос может ли ASA масштабироватся ответа как бы в этом тесте нет.
ЗЫ. сравнения как круто на фоне 1997 года и 16,500 tpc-c юзеров - энтерпрайз улыбнули :)
2Вячеслав
кажется понял, вы клоните к тому, что раз код вы все равно не протестировать не в состоянии, то запускаете простенький тест на загрузку по полной железа. но не понял зачем тогда 1С (загрузить можно тонной других способов)?
если затык в приложении (например блокировки) и ребенок увидит по простаиваемым ресурсам, если проблема в конкуренции за ресурс железа - нужно разбираться за который. зачем ваш синтетический однопотоковый тест, когда перед глазами уже есть реальная нагрузка ?
я надеялся увидеть тест именно 1С:Предприятия платформы ...
Я думаю, что Они собрали сервер на железке того уровня, на которой наверное БД и крутится у большинства их текщих или потенциальных клиентов. Что логично. Лично меня железки за 100к интерисуют мало.
Кто такие "ASA"? не делайте пожалуйста как IBM, на сокращают все что можно а потом сами путаются.
>кажется понял, вы клоните к тому
да, уже теплее
синтетичская загрузка дает ответы в сравнении с другими, у меня есть точка отсчета и возможность оценить конечный результат при отладке конфигурации
когда пользователь говорит что все плохо, тест помогает
> зачем ваш синтетический однопотоковый тест, когда перед глазами уже есть реальная нагрузка
реальная нагрузка перед глазами штука конечно стоящая отдельной книги, но на это сил и желания пока нету
поэтому сокращу до:
видимо будет многопоточный синтетический тетс
и видимо будет синтетический тест только блокировок (оказалось, что еще надо мерять механизм генерящий эскалацию не только в СУБД, но и собственный блокировщий 1С)
>Они собрали сервер на железке того уровня, на которой наверное БД и крутится у большинства их текщих или потенциальных клиентов
у меня тоже сложилось мнение, что цифры подбирались НА ТО, ЧТО НАДО ПРОДАТЬ и независимым тестом тут и не пахло
2alexeyk77
и кому нужен тест с реальной конфигурацией синтетического теста ? да никому. если бы был сравнимый с остальными конфиг то тут же бы были бы сняты тучи вопросы. а так у меня осталось ощущение, что ASA позиционируется как рещение малых рабочих групп и наращивание и/о ему ничем бы не помогло т.к. затык,например, идет в менеджере блокировок. например так можно объяснить гигантские цифры в максимума отклика.
короче я не вижу в результате теста как он в сравнении с остальными.
Вячеслав, я вас не понимаю. Все эти тесты нужны только для того, что-бы продавать и никак не иначе.
У каждого свой рынок и каждый стремиться быть на нем как можно лучше.
Вот сегодня мне пришло от сайбэйза в рассылке инфа о выходе SA11 в релиз. Вот выдержка:
With SQL Anywhere 11, Sybase iAnywhere is the:
° First vendor to post TPC-C benchmark results on hardware under $20k
Т.е. они сознательно пошли на тест в этом диапазоне цен. Это их рынок. У оракла и ИБМ - другие приоритеты.
2Вячеслав
я понимаю синтетический тест, когда мне нужна нагрузка для колибровки настроек субд. но он должен хоть чуточку напоминать реальную нагрузку, хотя бы как tpc-c.
вот если бы был многопользовательская нагрузка с миксом аналитических и OLTP транзакций, с задержками по 10 секунд пока пользователь пялится на экран, тогда уже можно было бы смотреть помогает ли неблокируемое чтение постгрес 1С, где порог DB2-expressC с его ограничением в 1Gb RAM, стоит ли запускать сервер 1С на Linux и т.п.
порог неприязни пройден, вижу конструктив, замечательно :)
>мне нужна нагрузка для колибровки настроек субд.
да штука впринципе неплохая - регулировка нагрузки - но это не вопрос синтетического теста в текущем виде, ведь тогда надо нагружать последовательно:
только чтение, только запись, управлять размером данных в операции, управлять паралельностью данных (их размещением и плоскотью одновременного чтения), управлять размещение в RAM или I/O, ну и так далее
скорее тогда нужен просто генератор чего то еще
>чуточку напоминать реальную нагрузку, хотя бы как tpc-c
да хватит уже tpc-c возводить в ранг "небесного эталона правдености", грешны все тесты
а тесты в многопользовательском режиме лицемерны по своей сути, тут ничего доказывать не надо
на какой главный вопрос должен отвечать многопользовательский тест? именно главный?
>с задержками по 10 секунд пока пользователь пялится на экран, тогда уже можно было бы смотреть помогает ли неблокируемое чтение постгрес 1С, где порог DB2-expressC с его ограничением в 1Gb RAM, стоит ли запускать сервер 1С на Linux и т.п.
Вопросы по порядку:
1. объясните еще раз, зачем надо с задержками?
2. "помогает ли неблокируемое чтение постгрес 1С" - это и так очевидно, не помогает, так как 1С использует МОДИФИЦИРОВАННУЮ версию, в которой внесены искуственно табличные блокировки, подробней не хочу углубляться - этого достаточно
3. "где порог DB2-expressC с его ограничением в 1Gb RAM", ну во-первых для 1С он пока что 4Gb, во вторых ответ у меня из практики и так есть - все зависит от конфигурации, для УПП это 50 пользователей, мой тест тут не нужен
4. "Стоит ли запускать под линукс" - ну это сложный вопрос и тест на него несможет ответить, хотя сравнить надежность наверно сможет, если увеличить количество документов, тогда проявиться эффект на утечках памяти
> Вячеслав, я вас не понимаю. Все эти тесты нужны только для того, что-бы продавать и никак не иначе.
Удивитесь, но я создал тест, что бы траблшутить проблемы у моих клиентов с быстродействием
Тест помогает вправлять мозги :)
2Вячеслав
как раз раздельная нагрузка мало полезна. основные проблемы появляются когда аналитические запросы начинают сталкиваться с OLTP нагрузкой.
>да хватит уже tpc-c возводить в ранг "небесного эталона правдености"
как раз tpc-c - совсем не эталон, нагрузка очень простенькая, требования слабенькие, производители просто читят. эталон это tpc-e.
>1. объясните еще раз, зачем надо с задержками?
при отгрузке товара открывается форма, ее пользователь заполняет 10 секунд удерживая блокировки 10 секунд, а не доли секунды. это многое меняет в характере нагрузки.
>внесены искуственно табличные блокировки
как я понял это только в автоматическом режиме блокировок.
>для УПП это 50 пользователей
видите, это уже говорит о проблеме УПП, на quard-core процах и 4Gb RAM еще 5 лет это был энтерпрйз левел обслуживающий целые телекомы. наверника наращивание ресурсов под субд эфекта для УПП не произведет.
>на какой главный вопрос должен отвечать многопользовательский тест
на сколько эфективно используются ресурсы железа платформой 1С при жестком конкурентном потоке длинных и коротких транзакций.
Итак, начнем с определения задачи.
Т.е. главный вопрос, на который должен ответить наш тест, иначе наша дискусия бесконечно по определению.
Вы предлагаете:
на сколько эфективно используются ресурсы железа платформой 1С при жестком конкурентном потоке длинных и коротких транзакций.
Ну вопервых некоторые понятий других ERP систем не применимы. В 1С любая операция сложная, даже если в логике конфигурации очень простой код. Это "расплата" за универсальный быстрый код разрабочикам конфигураций.
Давайте не делить транзакции.
>как раз раздельная нагрузка мало полезна. основные проблемы появляются когда аналитические запросы начинают сталкиваться с OLTP нагрузкой.
Допустим, что нагрузка в многопоточном режиме может формироваться из:
1) независимо обрабатываемых данных
2) пересекаемых данных
1й способ дает "более" чистую загруженность сервера и позволяет ближе подобраться к "тупой, но максимальной" загрузке железа
2й способ соответствует действительности, но загружает менее эффективно
Что предлагаете, остановитсья на 2м менее загружаемом, но более реалистичном?
>10 секунд удерживая блокировки 10 секунд, а не доли секунды. это многое меняет в характере нагрузки.
как меняется загружености при разных интервалах понятно, непонятно какой интервал выбрать, либо тестировать в каком диапазоне интервалов и почему?
>как я понял это только в автоматическом режиме блокировок.
Да, в автоматическом. Но упрощу понимание проблемы, в управляемом режиме конфигураций от 1С нет.
в>идите, это уже говорит о проблеме УПП, на quard-core процах и 4Gb RAM еще 5 лет это был энтерпрйз левел обслуживающий целые телекомы. наверника наращивание ресурсов под субд эфекта для УПП не произведет.
Давайте не будем обсуждать УПП, это уводит разговор в сторону.
>1й способ дает "более" чистую загруженность сервера и позволяет ближе подобраться к "тупой, но максимальной" загрузке железа
вот тут не согласная я. я мало чего знаю об 1С, но рассуждая если бы ваш код был бы сторед поцедурой то:
1. обработка однотипных документов это скорее всего одна таблица и пара закешированных справочников. т.е. в лучшем случае происходит линейное чтение таблички с документами (хотя наверника она уже на втором документе целиком закешируется). в рузультате важна линейное чтение и по сути тесту пофигу SCSI или дешевенький SATA покажет эту скорость.
2. однопоточный тест скорее всего загрузить сможет лишь одно ядро (поток) проца и ему будет важно только его скорострельность, т.е. у вас SPARC T2 имеющий 8 ядер и 64 потока гарантировано проиграет dual-core XEON, просто по тому, что у T2 односительно медленый один поток, а остальные 63 будут простаивать.
3. сомнительно, что один пользователь сможет расшевелить всю память сервера, скорее всего будет интенсивный обмен лишь небольшого участка где живет кеш таблички документов и его справочники. в результате тесту будет по барабану, что NUMA что SMP архитектура сервера, со всеми вытекающими в реале.множество пользователей потребуют память на выполнение кода, блокировки и начнут своими запросами вытеснять кеш. соответсвенно на буферный кеш останется меньше памяти и характер доступа к памяти будет сильно разнообразней.
с определением задачи, надо подумать. задач, даже основных, получится несколько т.к. CIO от теста необходимо одно, производителям железа и субд несколько другое.
да, еще раз, тест однопоточный и ориентирован преимущество на определение скорости одного потока
по поводу выполняемых действий, Вы наверно не дооценили смысл моих слов, когда говорил, что простой код 1С выплескивается в сложную схему хранения и запросов
внизу страницы теста я добавил раздел технические подробности, где опубликовал sql-код одного такта
http://www.gilev.ru/1c/tpc/tpc.sql
да ... такого кода я не ожидал :)
однако я бы все таки не стал бы делать выводы о производительности по скорострельности одного потока.
ну и базу бы хотя бы в 2-3 раза большую чем памяти сгенерил бы до начала теста (чтоб и/о подсистему нагрузить).
Новый тест, а уже с высокой вероятностью он будет (этап проектирования заверешн, начата реализация)
будет включать себя многопоточность.
Тест будет давать две ключевый цифры (скорость и ширину). Т.е. сколько за единицу времени будет успевать будет обозначаться двумя параметрами.
Другим обязательным критерием будет узменение загрузки в сторону дисковой подсистемы. Тест будет строится изначально так, что сервер подефолту его качественно сделать скорее всего не сможет. Затем объем будет срезаться пополам и оцениваться снова. Если осилит качественно, то добавим половинку от уменьшенного, если не осилит, то на такую же половинку уменьшим еще. И так далее до выведения к нормальному I/O.
Ага? вот интересный комментарий из перых уст по поводу теста аса на tpc-c.
https://www.blogger.com/comment.g?blogID=10793757&postID=4500871361267212760
Отправить комментарий