За последний месяц участилось количество обратившихся которые хотят подбирать компьютеры под 1С на основании "сервер должен обеспечивать столько то флопсов и столько то iops". Вы с этим согласны? Почему?

короче я Выбираю "Другое"
т.к. Клиент-Серверная 1С 8.х зависит от:
1)скорости работы CPU
2) скорости работы с оперативкой
3)коммуникационно среды передачи данных "СУБД"<--"Сервер 1с"
4)Дисковая система

т.е. Диски всего лишь Часть Целого))

Этот параметр имеет не менее важное значение, нежели линейная скорость и скорость доступа. Однако ориентироваться только на значение IOPS неправильно.

1. Статья, кстати, не тупая. Несмотря на некоторые упрощения и некорректные обобщения. В ней явно написано: "Анализировать корректно Disk Reads/sec и Disk Writes/sec можно только с учетом текущей длины очереди Current Disk Queue Length и средней длины очередей чтения/записи Avg. Disk Read Queue Length и Avg. Disk Write Queue Length." Видимо заказчику лень даже статью внимательно прочтитать.
2. iops показателен только либо для примитивных систем (1-3 диска) - там всё равно нормально нагрузку сложно раскидать, либо для очень дорогих (когда ограничением может стать шина FC или storage processor).
3. Железо можно выбирать по iops в том случае, когда этот iops а) является ограничением б) применим для той нагрузки в которой будет эксплуатироваться система. Если "а" предсказать обычно возможно, то "б" - сильно зависит от условий.
Вообще о каком сервере идёт речь? 1С:Предприятия или СУБД? Какой СУБД? Какой сервер 1С (64/32, какая ОС, если винда, то какой редакции, особенно, если памяти больше 32ГБ :) )
Если навскидку, то у сервера 1С следующие заметные дисковые активности:
* ЖР - только последовательная запись, актуально если не отключен и если много изменений в данных.
* Временные файлы больших выборок - последовательная запись большого файла и последовательное чтение, но при большом количестве пользователей может быть несколько одновременных потоков (актуально скорее для отчетов и сложных алгоритмов)
* ТЖ - это скорее тестовые стенды и сервера разработки.
Для MS SQL:
* Последовательная запись при изменениях в журнал транзакций при правильной настройке сервера (т.е. достаточном размере заданном сразу). Простая модель восстановления не исключение (при обычной работе 1С). Часто является ограничением производительности, потому что выполняется в Write Through.
* Массовые случайные чтения файлов данных небольшими блоками при выборках (при хороших планах запросов). Глубина очереди может стать очень большой.
* Массовые чтения файлов данных где-то случайные, где-то последовательные блоками разного размера при плохих планах запросов. Глубина очереди будет очень большой.
* Массовые последовательные операции чтения и записи файлов данных и ЖТ с небольшой глубиной при резервном копировании. Да и при перестроении индексов похожая нагрузка. На хорошей дисковой системе и мощном железе можно упереться в шины и производительность дисковых процессоров.
* Случайные записи файлов данных при изменениях данных. Если памяти достаточно, то это НЕ является ограничением само по себе, так как для файлов даннх работает отложенная запись. Но вот при комбинации нагрузки (грубо говоря, когда есть очередь на чтение и на запись) может опечалить заказчика.
* Нагрузка на файлы данных tempdb (сильно зависит от запросов и объёма памяти)
* Нагрузка на файлы ЖТ tempdb - чтобы было ограничением я не встречал, но повлиять на другие нагрузки может

А теперь всё вышенаписанное смешиваем :) Учитывая, что:
* смесь случайных операций и последовательных даёт плохо предсказуемую производительность (в iops, конечно же)
* смесь больших и малых блоков даёт плохо предсказуемую производительность
* при больших глубинах очереди производительность плохо предсказуема
* смесь Write Through и Write Back - плохо предсказуема

4. Если заказчик так и молится на свои несуществующие иопсы, то пусть и требует этих иопсов с вендора. В зависимости от того, сколько заказчик платит на консультацию можно даже собрать стенд на простейшем железе (хоть в виртуалках) с отдельными дисками для каждой нагрузки и снять замеры СНТ или его реалистичной нагрузки с отслеживанием по apdex (параметры: средняя очередь, количество записей в секунду и чтений в секунду, снимать раз в 1-2-3-4-5 секунд). Те периоды, когда средняя очередь хотя бы на одном диске больше 1, потенциально ускоряются от дисковой системы. Считаем сумму операций ввода-вывода N за эти периоды суммарного времени T1, если всё время T0, то тупо арифметически говорим, что если при призводительности K iops общее время выполнения сценария будет (T0-T1) + N/K, где (T0-T1) зависит не от дисковой подсистемы. Правда с высокой верятностью K iops будет недостижимо по причинам, изложенным, но это пусть у вендора трясёт, чтобы вендор обеспечил.