Тестирование - не самоцель, а средство обеспечения качества программы. Humble Object (вы же прочитали статью по ссылке?) именно об этом. Вы никак не можете проверить что передано в конструктор. Просто потому что конструктор невозможно замокать. Никак. Ничем. Что-нибудь магическое из мира PHP не рассматриваю.
Дальше. Если рассматривать TDD, главный принцип которого "не писать код без упавшего теста". TDD не утверждает что упавший тест должен быть обязательно модульным. Интеграционные и приемочные тесты - точно такая же часть TDD, как и модульные. См. пирамида тестирования или Р. Мартина "Идеальный программист", главу 8 "Стратегии тестирования"
CityCat4, я не понимаю с чего у вас пригорает. Я ровно это же самое написал про недостатки ZFS.
Это всего лишь означает что администратор сервера должен учитывать данную особенность ZFS и заранее иметь rescue kit, чтобы без вот этого "LiveDVD неведомо какой" (на крайний случай уметь использовать данный LiveDVD чтобы быстро изготовить другой с поддержкой ZFS)
Учитывая что ZFS применяется в энтерпрайзе (причем именно в сочетании с Linux, а не Solaris/FreeBSD) - эти риски вполне возможно нивелировать, если подходить к вопросу грамотно.
Nordman99,
ext4 - если важна максимальная совместимость. Вероятно в паре с lvm (но реального опыта с lvm не имею, только игрался на виртуалке).
zfs - если хочется использовать все возможные "фишки" (снепшоты, сжатие, управление томами и т.д.)
Рекомендовал бы ZFS без вопросов, но есть крупный недостаток: не входит в состав стокового ядра. То есть, при необходимости загрузиться с LiveCD/LiveUSB начинаются "танцы с бубном". Поэтому лучше всего иметь собственный LiveCD с модифицированным ядром, в которое вкручена поддержка ZFS. Такое, например, легко сделать на базе ArchLinux. Отмечу что в интернетах пишут что LiveCD Ubuntu умеет ZFS (то есть Canonical собрали для своего дистрибутива ядро с поддержкой ZFS. Как они обошли лицензию - понятия не имею). Но на практике я убунту не ставил, так что не знаю.
Nordman99, про BTRFS не скажу, а у ZFS используется концепция пула. То есть вы берете в общем-то что угодно: целые диски, разделы дисков и даже файлы (что удобно для экспериментов) и создаете из них пул. Пул может быть опять же построен как угодно: чередование (stripe), зеркалирование (mirror), разные варианты рейдов. Например, из четырех дисков можно построить две пары зеркал и объединить их в stripe.
По вкусу добавляете диск для кэша на чтение (обычно SSD) и zil на запись.
Тут же находится сжатие, дедупликация, шифрование.
В любой момент в пул можно добавить новые диски, увеличив его объем (а если диски в зеркале - то заменить на диски большего объема). Единственное ограничение - уменьшать пул нельзя.
Собственно все. ZFS сама разложит данные по пулу. Дальше поверх пула создается dataset (сколько нужно), ему назначается квота (если нужно) и точка монтирования.
И какую роль при всех этих возможностях будет выполнять LVM?
Александр, а зачем их тогда столько? Погасите лишние, оставьте 300-500 (можно даже сконфигурировать динамическое количество). И посмотрите что будет с LA после этого.
Akina, ему надо не так, ему надо если параметр имеет значение NULL, то оставить значение поля CASE WHEN :test IS NULL THEN test ELSE :test END
Или, проще: UPDATE base SET test = IFNULL(:test, test)
Меня озадачивает 3500 php-fpm воркеров. Это как бы в разы больше наличных ядер процессора.
При этом 4-5 тысяч запросов в секунду. То есть, предполагая что у вас задействовано порядка 3000 воркеров (500 оставляем как резерв), то на обработку одного запроса уходит порядка 0,65 секунды. Не многовато ли?
У вас выходит порядка 55 воркеров на один поток процессора (и это я считаю только php-fpm, на деле будет больше). Это просто ужас сколько переключений между тредами (переключений контекста), что является космически дорогой операцией. Возможно что-то надо делать с этим?
Если уж смотреть в сторону btrfs, то почему бы не ZFS? Да, при установке проблем будет больше (стоковое ядро её не умеет), зато потом - та же сказка что и с btrfs, только ZFS уже давно как используется в продакшене и имеет репутацию надежной FS.
Тестирование - не самоцель, а средство обеспечения качества программы. Humble Object (вы же прочитали статью по ссылке?) именно об этом. Вы никак не можете проверить что передано в конструктор. Просто потому что конструктор невозможно замокать. Никак. Ничем. Что-нибудь магическое из мира PHP не рассматриваю.
Дальше. Если рассматривать TDD, главный принцип которого "не писать код без упавшего теста". TDD не утверждает что упавший тест должен быть обязательно модульным. Интеграционные и приемочные тесты - точно такая же часть TDD, как и модульные. См. пирамида тестирования или Р. Мартина "Идеальный программист", главу 8 "Стратегии тестирования"