По 18 мбайт/с с диска чтоли? Несеръезно.
Оба метода и через sendfile и через aio (речь об nginx'е, правильно?), не гарантируют, что к диску не будет параллельных обращений. Потому и так плохо.
По крайней мере 2-е точно должно сходить с рук.
Кому-то тяжело извиниться, кому-то нет, кто-то может извиниться, а потом подстеречь в темном переулке. Все люди разные, но все люди.---------- Добавлено 21.07.2013 в 18:24 ----------
Не соглашусь. Лучше согласитесь, что мы все люди и у всех есть эмоции, и грубить и хамить вполне по человечески.
Не храню графики многолетней давности, сори.
UPD: ТС если еще надо, пиши в личку, из спортивного интереса посмотрю, что можно выжать в текущей конфигурации.
Что вы там реализовывали? Физические возможности как раз достаточные, нужно всего по 60 мбайт с диска тянуть, а это случайными 2+ мегабайтными блоками любой диск сможет. Только вот никаких "сколько потоков" быть не может, поток один на диск, отдельный и читать с диска он должен мимо кэша файловой системы. Клиентов может быть столько, сколько хватит оперативки под их буферы.
Есть еще вариант попроще, это read ahead, читать с диска в обычном режиме мелкими запросами, но давать ему складывать в кэш фс по пару мегабайт наперед, пока не много клиентов - будет работать, а потом в какой-то непредсказуемый момент резко начнутся тормоза.
Мое если было только одно, чтобы метаданные влазили в память и не вижу причин, чтобы контент ТСа не прокатывал.
Эти "чтобы" и есть настройки, а не исключение. Оперы может и хватить, хз сколько у него одновременных клиентов.
Неправда это, я тоже этим занимался когда-то, когда еще SSD дисков не было и вижимали с дисков все, что могли. Если метаданные всех файлов влазят в память, т.е. их не миллионы, то они вообще не помеха и диск не дергают, главное чтобы они не вытеснялись из кэша и в кэш не лезли сами файлы без надобности, ну и чтобы с каждым диском работал только один отдельный процесс.
Можно взять сервер с SSD дисками и некоторое время может и не придется тратиться на админов :)
