Дело в том, что метаданные drbd при такой схеме, как я описал, не страйпятся. Возможно, это издержки fio, в том плане, что он бьёт в какие-то не совсем рандомные секторы.
Я перебирал массив с разным размером чанка, от 4K до 4M, в любом случае под тестом два диска из массива нагружены до максимума (120-130 иопсов), а остальные стоят холодные.
Если вынести метаданные в отдельный диск (магнитный), то производительность системы по иопсам оказывается на половине производительности диска с метаданными. Можно натыкать SSD, конечно, но это полумера.
Можно поступить иначе и собрать много маленьких drbd-устройств, а потом объединить их с помощью md-stripe или md-linear, тогда получаются разумные цифры по производительности (450 иопсов). Правда, тоже выглядит маразматично.
Правильный путь — понять, почему метаданные не страйпятся, или страйпятся неправильно.
Возвращает строку. Если следовать HMVC, то возврат нужно складывать в request->response. Тогда не нужно думать, первичный контроллер у вас вызван, или другой. Если очень хочется — можете напрямую его выводить, но тогда нужно помнить, откуда вы выводите.
С этого места поподробнее. Разве мне даст открыть listen-сокет на 80 порту для приема файла?
Кроме того, если я верно вас понял, это попахивает извращением, а именно — написанием простейшего веб-сервера на PHP.
Или я неправ?
Топикстартер хочет иметь одну версию исходников, и компилировать из этой версии само приложение с помощью препроцессинга (возможно в нескольких вариантах). В таком случае надо не исходники мучить и заниматься метапрограммированием (в каком-то смысле), а логику разделять.
#/bin/sh
/bin/cat file.txt | while read line; do
/sbin/route add $line dev wlan0
done
/sbin/route add 1.1.1.1 dev wlan0
/sbin/route del default
/sbin/route add default dev ppp0
2) вместо bla нужно написать конфигурацию, которая будет дергать ваш скрипт. proxy_pass/fastcgi_pass