Shuhard http://v8.1c.ru/tc_web/tc_overview.htm
Microsoft Benchmark Tool
Сергей - поправьте ссылку, Ваша с http://axapta.mazzy.ru/lib/axapta_benchmark/ на http://www.microsoft.com/Rus/BusinessSolutions/Solutions/Axapta/Scaling/Production.mspx не работает

Адекватны ли результаты тестирования ?
Э-э-э... Есть еще http://axapta.mazzy.ru/lib/axapta_benchmark_2005/

Дело в том, что в Аксаптовском тесте сознательно использовался инструмент, встроенный в Аксапту.
Причем сознательно делался тест, который не требует модификаций кода.

Любой, у кого есть Аксапта может запустить этот же тест на стандартном приложении.
В условиях тестирования Аксапты приведены все параметры для генерации такого же теста.

В 1С используется отдельная конфигурация (не знаю есть ли она на ИТС, просто еще не интересовался). Как эта отдельная конфигурация связана с типовыми и как влияет на типовые - не ясно. А в методичке об этом не написано.

Кроме того, до тестирования Аксапты специально генерилась база данных достаточно большого размера, чтобы данные гарантировано не помещались в кэш SQL-сервера. А размер базы 1С не указан.

Кроме того у 1С указано: " Каждый тестовый пользователь создает документы со своим уникальным набором товаров, то есть все движения документов записываются параллельно, не приводя к блокировкам. "


Я не очень понимаю вопроса "Адекватны ли результаты тестирования ?"
Скорее всего, вы хотели спросить "сопоставимы ли результаты тестирования?"

Смотрите сами.

1С: "при одновременной работе 200 пользователей на 1С:Предприятии 8.1 тестовый пользователь вводил 965 строк в час"
Axapta: "Стандартный пользователь Axapta - ASU (Axapta Standard user). 1 ASU соответствует той нагрузке, которую создает пользователь, обрабатывающий 50 строк заказов в час."

Значит 200 пользователей 1С примерно соответствуют 965/50*200 = 3860 ASU

1C:
* Тестовых пользователей 200, что примерно соответствует 3860 ASU
* среднее время записи и проведения одного документа составило 3.47 секунды.
* 190 000 строк документов в час
* Размер тестируемой базы данных: ???

Axapta
* Стандартных пользователей Axapta (ASU): 1086
* Среднее время отклика: 0.925 сек
* Среднее количество обрабатываемых строк заказов: 54.3 тысячи в час
* Размер тестируемой базы данных: 15 Gb

==================
Тестовый стенд 1С
* Сервер MS SQL 2000 SP4: ? * (2 * DualCore Intel Xeon, 2666 МГц, 8GB RAM, 6 дисков в режиме Ultra320 SCSI RAID 0 (stripe)
* Сервер 1С:Предприятия ? * (2 * Intel Xeon MP, 2800 МГц, 4 GB RAM , 2 * Ultra320 SCSI RAID 0 (stripe))

Тестовый стенд для тестирования Axapta

* сервер баз данных: 1 * IBM eServer xSeries 455 (4 * Itanium 2 1.5 GHz , 8 GB RAM )
* серверы приложений: 5 * IBM HS 20 ( BladeCenter ) (2 * Xeon 3.6 GHz , 3 GB RAM )


Вроде цифры похожи. НО!

Каков был объем тестируемой базы? Когда мы начали тестировать Аксапту на пустой базе, у нас были такие запредельные цифры, что мы сами им не поверили. Поэтому перед всеми нашими тестированиями мы создавали базу достаточного объема этим же штатным инструментом тестирования.

Если еще учесть условие о том, что "Каждый тестовый пользователь создает документы со своим уникальным набором товаров"... Скажу честно, мы до такой "оптимизации" не додумались...

Кроме того, хотелось бы понять фразу 1Совского пресс-релиза "Расчет себестоимости списываемых товаров не производится." Это значит, что себестоимость проданного товара = 0? В Аксапте при расходе всегда выполняется расчет себестоимости по среднему.


А вообще говоря, спасибо 1Су за публикацию результатов тестирования.
Интересно было бы увидеть подобные тестирования и для других систем.

==================
Спасибо, ссылку поправлю.

И еще.
Со времен тестирования http://axapta.mazzy.ru/lib/axapta_benchmark/
были и другие. Вот некоторые в публичном доступе:

http://axapta.mazzy.ru/lib/axapta_benchmark_2005/
http://axapta.mazzy.ru/lib/axapta_itanium/
http://www.microsoft.com/dynamics/ax/product/hpbenchmark.mspx
http://corp.cnews.ru/news/line/index.shtml?2006/09/29/212560

Может есть ссылки на результаты тестирования других ERP и учетных систем?
А также на инструменты для тестирования.

gybsonНе проводилось списание по партиям я думаю. Один из методов ведения учета - списание партий в конце каждого месяца.
Партионный учет был. По крайней мере так написано в документе.

ФлеймерТе надо проделать тест при запущенных отчетах. Если запуск тяжелых отчетов не тормозит ввод в систему, а увеличивает время выполнения отчета, то система вполне адекватна.
Отчет - читает. Отчет не пишет в базу.

Тяжелые отчеты могут тормозить только в том случае, если чтение не приводит к блокировкам.
Аксапта работает на Оракле и SQL2005, где проблема блокировок на чтение не является острой.
Вот для Аксапты на SQL2000 такая проблема действительно была.

А в 1С используется грязное чтение. Там эту проблему "обошли".

gybson
А в 1С используется грязное чтение


С каких это пор?
Всегда, насколько я помню. Я ошибаюсь?

Если я ошибаюсь, то проблема блокировок есть и в 1С.
Тогда действительно тестирование надо проводить одновременно с отчетами.

gybson
Если я ошибаюсь, то проблема блокировок есть и в 1С.
Тогда действительно тестирование надо проводить одновременно с отчетами.


У всех есть проблема блокировок, что-нибудь, да не резиновое, хотя бы сеть. При проведении документа идет контроль остатков, что можно считать "миниотчетом" :)

Щас рыдать буду...
Проведение документа проводится в транзакции... Если вам это о чем-то говорит...

Да, "что-нибудь, да не резиновое". Только к такому выводу и можно прийти...
А где, что... Какие решения принимать, а какие не принимать... Какая разница, ведь "что-нибудь, да не резиновое"
"8.1 лучше 8.0"!

gybson
Проведение документа проводится в транзакции... Если вам это о чем-то говорит...


И? Давайте разовьем мысль и потом еще раз вернемся к отчетам, которые, как ни странно, тоже в транзакции выполняются.
Да! Вы уже почти на финишной прямой!

И транзакции в отчетах и документах отличаются чем?

gybsonУровень изоляции совершенно одинаковый, сериалайзбл, извините за мой англиский.
Разве?

Хорошо, не будем спорить в этой ветке.
Это значит, что отчет в 1С эквивалентен проведению документа с такой же продолжительностью.
Поэтому отчеты отдельно не тестировались.
(ужасный вывод, ну да бог с вами).

Вернемся к теме?
" Re: Сравнение инструментов тестирования производительности учетных систем "

gybson
Это значит, что отчет в 1С эквивалентен проведению документа с такой же продолжительностью.


Нет....
Тогда тестирование должно проводится и на отчетах тоже :)

gybsonИнтенсивный ввод документов еще хоть как-то близок к реальности. Какой отчет предлагается формировать и с какой частотой? :)
Вы меня спрашивете?
Вам же сказали "тяжелый". Добавлю: часто испольуемый пользователями.
С той частотой которая чаще всего возникает при реальной работе.

ясно.
давайте про грязное чтение в отдельный топик.

здесь тема "Re: Сравнение инструментов тестирования производительности учетных систем"

gybsonТак в том и суть, что он по сравнению с документами не заиграет никак.
Обоснуйте.

skeptikСоответсвенно указание объема базы без детельного описания ее структуры, объема каждой таблицы и всех используемых запросов (а также последовательности их выполнения и еще ряда факторов) это, протите, попытка ввести в заблуждение. Сознательная или нет - судить не берусь.
Вовсе даже нет.
Это первое приближение.

Для того, чтобы ответить на вопрос "помещаются ли все таблицы в кэш" достаточно знать, что размер базы меньше размера оперативной памяти.

Чтобы быть более-менее уверенным, что диск задействован достаточно знать, что размер базы в полтора-два раза (или больше) больше размера оперативной памяти.

Детальное описание структуры нужно в пограничной зоне.

Не заговаривайте зубы.
Просто тесты надо проводить на базе, которая больше размера ОЗУ.
Чем больше, тем меньше влияет кэш.

vde69а почему Вы хотите исключить влияние кеша?
А я не хочу "исключить".
Я хотел бы видеть результаты и в том, и в другом случае.
Но это трудоемко.
Если приводится только один результат, я бы предпочитал видеть результаты, не сильно "оптимизированные" кэшем

vde69если система работает быстрее то пользователю какая разница кеш или нет???
И в самом деле?
Большие ОЗУ на сервере всем! И путь никто не уйдет обиженным.

skeptikЕще раз, для тех кто в бронепоезде: база 100 Гиг, ОЗУ 1 Гиг, таблица 10 Мег, запросы только к этой таблице .
skeptik, перечитайте тему и начало топика.
Пожалуйста, перестаньте обсуждать сферического коня в ваккуме.

Если вы при тестирования документа "Расходная накладная" сможете обойтись одной таблицей, флаг вам в руки.

С вашего позволения, я, как участник обсуждения, буду игнорировать ваши дальнейшего вопросы.

Shuhard mazzyА я не хочу "исключить".
Я хотел бы видеть результаты и в том, и в другом случае.
Но это трудоемко.
Если приводится только один результат, я бы предпочитал видеть результаты, не сильно "оптимизированные" кэшем

тогда ,на мой взгляд, к размеру базы стоит добавить режим рейда и режим сиквела(Full/Simple) , иначе определять не размер , а количество записей.
Не против.