ну берем пару сотен клиентов и среднее значения операций по записи будет одинаково...
Можно отдельно развести дискуссию по поводу SATA w. NCQ vs SCSI, что само по себе уже интересно, т.к. мало кто знает, что такое NCQ и на сколько с ним хард становится шустрее. Только харды для сравнения надо нормальные брать, а не всякий там рефабришед бутор, который даже на SCSI-320 более 40mb/s plain read дать не может.
могу... давай какую нибудь фоту посудную в hi resolution и я её почищу... а потом может и свет человечный наложу...
А та посуда, что ты привел, IMHO рендер в 3ds c vray. Если на моём домашнем мудрить, то получается, что работы максимум на пару-тройку часов, а рендеров потом с корректировками почти на сутки... хотя если presets у кого попросить, то может быть и меньше... но сам рендер часа на три это железно, хотя могу ошибаться, т.к. посуду еще не рендерил, а вот визуализацию интерьеров оч часто...
PS. Кстати, на одном из сайтов по реставрации фотографий заметил фото с CD из книженции Айсман... вот было прикольно.
вот с посудой фото одно... а там :)
PS. Посуду и я могу сделать.. работы не более чем на час.
SCSI 320 возможно и вымрет, а FC-AL IMHO будет более близок к пику... вот подешевеет и всё тип-топ будет.
В Инфобоксе просто FC или на кластере с кластерной FS?
этот параметр более чем постоянный, т.к. "средний по больнице" всегда будет средним.
Дмитрий, мы превращаем тему в SCSI лучше чем SATA, что само собой и так ясно. Если вернуться на несколько мессаг выше, то с моей стороны было утверждение как раз в конктексте, что SATA + ПАРУ ГИГОВ ОПЕРАТИВЫ лучше, чем просто SCSI без дополнтельной оперативы... вот как раз в контексте задачи с web сервером.
логотип настораживает... треугольничек, если заметили.
IMHO вторая фото с сайта производителя.
ЗЫ. Над ползунками, возле треугольников, лампочки кажется были... т.к. это, вполне очевидно, и есть основное отличие первой от второй 😂
и число кнопок на клавиатуре тоже... собственно клавиатура не основной нюанс.
Это скрин из портофолио профессиональной студии!
Это сказочная история, если уже на то пошло... года через два возможно оно станет реальностью.
Ужасы какие-то. СУБД надо выносить от веб на отдельное физическое железо и это совсем тема отдельная. Интенсивность изменения файлов веб скриптами ничтожно мала, тоже самое касается и ftp. SCSI диск на веб сервере фактически простаивает. Малый объём записи увеличивает эффективность read cache на всех уровнях.
Вот уж начинается 😂 в этом случае с большим количеством оперативы и sata потеть меньше, чем со scsi и оперативы с гулькин нос.
PS. Кстати, а Вы харды с NCQ саташные использовали? ну так, что бы еще в контроллере оператива + оптимизация была.
а чего на серверах виртуального хостинга такого критического?
Comand Queue может быть где угодно, в т.ч. и в харде и в контроллере... почитайте про SATA харды с Native Commad Queue. Я не говорю что SATA это непомерный рулез... но для файлопомоек, с которых надо выдувать от силы мегабит 500 этого ПО САМОЕ САМОЕ. А вообще, если не в курсе, то с SATA2SCSI рейдом можно выдувать 700mbps per server.
Если Вы не в курсе, то это называет Command Queue, которое может быть в надцати вариантах реализации, но в магазине вам про это не скажут...
Вопрос на самом деле в 500 баксах, т.к. по мне для этой задачи лучше SATA с NCQ + пару гигов ECC RAM дополнительно, чем хороший SCSI хард + хороший контроллер.
PS. По условиям задачи у нас никогда не будет более 70мегабайт на выход, т.к. больше через гигабитный канал выплюнуть сложно... не хочу сказать, что sata такое по силам, но не могу не заметить, что с дешевого scsi, который может быть вполне refactored, на plain read получается в р-не 80mb/s... вот лучше жить на куче хардов из sata + громаднейший кэш.
Ну а я говорю о том, что если надо выдавать файло до 100kb в 5000 активных сессиях, то scsi вообще не надо... эффективность кэша на подобном ресурсе может быть более 70%. Если предположить, что трафика 200-300kb per hit, а средний размер канал у клиента 64kbps, то получается, что каждый клиент у нас будет висеть не менее 31 секунды, что при минимальном hit rate в 150 per second будет составлять не менее 7 тыс активных соединений и т.д. и т.п...
Тут два варианта на самом деле... обратиться к профессионалам или изучать особенности построения подобных ресурсов на собственных ошибках и многодневных простоях... что само по себе подразумевает кучу непредвиденных расходов на всякие там платы за решение вопросов... imho лучше платить сразу, за то что бы это работало, а не за то что бы это потом чинили.
Не знаю о каких там целеронах идёт речь, но только на грамотную раздачу файла желателен сервер с размером оперативы под 4GB... с него можно выдавить тыс 10 активных сессий и жить достаточно долго.
PS. И еще за сетевые чипсеты речь встаёт иногда, т.к. на сдаваемом в аредну "Г" очень часто нет em, что само по себе огорчает... а иногда так хочется выставить hw.em.rxd с hw.em.rx_int_delay и пыжнуть бенчмарками.
