hell

Кавычку после восклицательного знака поставьте, и будет вам великая радость

Вообще говоря, strip_tags позволяет оставить некоторые теги. Собственно оставляем набор типа "p", "a", "strong", "em", "br", а для пущей чистоты грузим сухой остаток как DOMDocument, пробегаемся по нодам и чистим атрибуты.
Ну или просто пробегаемся грузим как DOMDocument, пробегаемся по нодам и чистим лишние атрибуты, а лишние ноды удаляем. Работать должно побыстрее preg-replace.

По первому пункту:
Правильнее будет протестировать на актуальном железе и в актуальной конфигурации. Кроме того, ответ на ваш вопрос будет зависеть еще и от вашей возможности корректировать параметры ядра. На виртуалках у вас такой возможности может и не оказаться.

Полтора года назад я делал такие тесты для своего сервера.
Тестировались три варианта - nginx+php-fpm, nginx+apache+mod_php, nginx+nginx+php-fpm. результаты тестов на боевых сайтах показали:

при правильной настройке apache - nginx+php-fpm - наименее производительное решение
nginx+apache+mod_php и nginx+nginx+php-fpm выдерживают примерно одинаковую нагрузку, но второе решение чуть менее надежное (то есть именно чуть - в среднем, на 1000 натравливаний siege на боевой сервер, php-fpm слетел раз 7, а апач - раза 2)

Софт с тех пор поменялся, железка у вас заведомо другая (та, на которой я тестировал, погорела), у меня был debian без виртуалок, у вас - Centos, посему актуальные результаты тестов в вашем случае могут оказаться другими.

По второму - позволю процитировать себя же - "при правильной настройке apache". Правильная настройка апача на производительность включает полный отказ от .htaccess. Часть переносится в nginx, часть - напрямую в конфиги конкретного веб-сервера. Ну и из апача вообще выбрасываетс много-много-много всего. Нужно помнить, что правила рерайта в нгинксе огтличаются от апачевских - на хабре была пара правильных (особенно с учетом комментов) статей, ну и на самом сайте нгинкса примеров хороших более чем достаточно.

По третьему - если вы проведете тесты и убедителсь, что с надежностью у связки nginx+nginx+php-fpm все нормально на ваших сайтах, я бы перешел.
Поясню суть такой связки:
внешний nginx отдает статику, зипует на лету, частично рерайтит запросы, а также проксирует запросы к php на внутренний нгинкс. Кроме того, по необходимости и возможности, он может кешировать часть запросов. У внешнего нгинкса keepalive_timeout установлен в достаточно большое значение (то есть тоже стоит подбирать).
Внутренний нгинкс стоит с keepalive_timeout=0, и работает с php-fpm.

Прекрасной плюшкой такой связки является возможность кеширования страниц с одновременным, простым и наитивным отключением кеширования интерактивной части (то есть, к примеру, вы кешируете весь сайт кроме блока комментариев и блока каких-нить прикольных фишечек, которые выводятся по рандому).

Минусом - принципиальные отличия в логике рерайтов на nginx и в apache. Врочем, если потратить разок 2-3 рабочих дня на то, чтобы в этих разлиичях разобраться, дальше все будет проще.

и проверьте в etc/php5...conf.d, пролинковано ли расширение

From правильнее кодировать с помощью mb_encode_mimeheader до того, как кодировать прочие заголовки.
Т.е. алгортим примерно следующий:

Проверяем, что у нас есть mbstring (для старых версий php возможны варианты)
Проверяем, что у mbstring прописаны правильные значения кодировок по умолчанию (читаем доки, в том числе по функции mb_encode_mimeheader)
Кодируем поле FROM с помощью mb_encode_mimeheader
Устанавливаем все хидеры (имеет смысл посмотреть реализацию PEAR — там не без ошибок, как ни удивительно, но в целом оно рабочее)

Боюсь, что огребу за свой совет кучу минусов, но тем не менее:

Месяца три назад, я 2 недели посвятил тестам — что лучше. Правда — у меня стоял PHP 5.4, nginx 1.2 и все это на Debian
Тестировал (и, разумеется, в процессе тестов тюнил ОС и все прочие настройки) четыре варианта — nginx+PHP, nginx+ahache+PHP, nginx+nginx+PHP (в последнем случае есть внешний нгинкс, работающий со статикой и отправляющий запросы к PHP на внутренний нгинкс) и nginx+apache+PHP-FPM.

Внутренние нгинкс и апач запускаются в режиме keepAlive off
У апача отрублено все лишнее (в моем случае оставлены dir, auth, mime, rpaf). ,haccess не используется (если че-то нужно органичить — ставим напрямую в конфигах сайта, все перенаправления — через внешний нгинкс)
У внешнего нгинкса включен gzip, отключено кеширование
Внутренние сервера логируют только ошибки php

Во всех случаях на реальные сайты натравливался siege с увеличенным таймаутом и с 1000 конкурентных запросов.

Да — и машинка — Хетзнеровская с 24 GB памяти.

Результаты получились следующие:

nginx + php — не котируется вообще. выводит память в свап, нагрузка в top — 140 — 150 примерно через минуту после начала осады. Манипуляции с системой и настройками не помогли.

nginx+apache+php-fpm — жрет память и залезает в свап, процессор особо не грузит. Есть проблемы со стабильностью (siege стабильно отрабатывал с параметром не более -c 500)

nginx+apache+php и nginx+nginx+php — примерно одинаковые результаты — средняя нагрузка в top — 3, среднее потребление памяти — 14 — 16 Gb. Количество транзакций также примерно одинаково (apache показывал результаты примерно на 3-4 транзакции в секунду лучше)

nginx+nginx+php работал чуть менее стабильно, чем nginx+apache+php (не чуть, даже — чуть-чуть — то есть пару тройку раз сокет все-таки падал, а в случае apache тaкого не было)

Пришлось остановиться на классике (хотя очень хотелось ограничиться nginxом)

Впрочем — это все — лирика. Я бы рекомендовал провести серию тестов с вашим софтом (и с вашим админом) — возможно вы получите другие результаты. Впрочем — и это почти наверняка — вариант с реверс-прокси будет заведомо более производительным.

Если для опыта, то вам стоит двигаться примерно следующим образом:
1) Крепко-крепко подумать, а надо ли оно вам (потому как, если вдруг начнет получаться — процесс сам по себе затягивает и отвлекает от зарабатывания денег, личной жизни, да и жизни вообще)
2) Прикинуть, что вам не нравится в тех готовых движках, на которых вы делали сайты
3) Составить краткий список того, что должна уметь делать ваша CMS (в глаголах, желательно)
4) Поизучать фреймворки (на разных языках) и выбрать лучший, или, убедившись, что их авторы козлы полнейшие возможности, предоставляемые фреймворками избыточны, либо не достаточны — перейти к следующему пункту
5) Исходя из списка из пункта 3, выбрать хранилище данных. Критерий выбора — как ни удивительно — не его распространенность, но, скорее — возможность выборки требуемых данных минимальным количеством простых запросов.
6) Исходя из выбора хранилища данных, выбрать фреймворк/язык программирования
7) Подобрать хостинг, на котором есть все, что вам нужно
8) Пробежаться по списку из пункта 3 и быстро-быстро все написать. При необходимости — конкретизировать и расширить этот список. При необходимости — вернуться к пункту 4.

Как-то примерно так.

namespace указать надо в html.
типа примерно как-то так
<html xmlns:og="http://ogp.me/ns#">