Alex Klo

humbert:
А есть ли у кого примерная картина как это произойдет

Логистик:
Например есть определённый товарный знак
для примера назовём его так:
Prevet
у них допустим есть сайт Prevet.ru

при этом есть домен privet.ru
различие, как мы видим в одну букву
рискует ли владелец домена privet.ru, потерять свой домен?

База данных:
В некоторых таблицах использование MyISAM некорректно. Требуется InnoDB или XtraDB.
Пример: messages_*, profile_visit

Общая фрагментация БД небольшая.
База данных сильносвязная - нагрузка на БД при резком росте посещаемости будет расти нелинейно (степень - 3-5).
---------------------------------------

Файловая система:
-общий беспорядок, много файлов в корне, которые не имеют непосредственного отношения к сайту

---------------------------------------

Программинг:
-использование глобальных переменных вместо Registry [code-styling]
-отсутствует инкапсуляция программной логики, запросы пишутся явно, а не через специальный конструктор [code-styling]
-возможны SQL-инъекции (не используется принудительная фильтрация и(или) приведение типов) [critical!] : /account.php : 72
-курсы валют для Webmoney жестко захардкожены [flexibility] : /account.php : 97
-функциональный подход - код плохо читается, сложен в сопровождении [code-styling]
-SQL: используются запросы с большим количеством JOINов :: плохо сказывается на производительности (смотри "кеширование") [performance]
-SQL: плохое использование индексов, сканирующие (тяжёлые) запросы почти всегда [performance!!]
-плохой стиль программирования. Генерация шапки делается постоянно, вызовы функций генерации - везде.
как итог - очень много лишнего кода, уменьшается читаемость каждой страницы. Значительно более геморройная поддержка. [code-styling, support]
-торчат уши от переезда. Стоит удалить всё лишнее. [security]
-странный скрипт: /dating.php [security]
-поиск: используется достаточно слабая система поиска MySQL вместо мощного специализированного Sphinx [performance]
-нужно провести тесты на использование функций рендерера (лучше их выделять в отдельные файлы, собирать всё в кучу?) [ab -c 100 -n 1000 http://[TARGET_URL] ] [performance]
-вероятно, стоит перестроить модуль-страничную структуру сайта для уменьшения количества кода на запрос [performance]
-не используются стандартные функции php, вместо них - велосипеды [code-styling, performance] : /include/common.php : 79
-используется достаточно тяжёлая Smarty. На мой вкус - медленно и геморройно. [performance]
-не рекомендую хранить хуки и ссылки на хендлеры в БД. Для подобного существуют include и ram-диски
-вместо стандартного mbstring используются /include/utf [performance, code-styling]
-систему управления доменами лучше вынести из БД в подключаемые конфиги
-чрезмерное количество запросов на слабоменяющиеся данные при каждом запросе к серверу (нужно кешировать) [performance]
-низкий реюз кода и плодим сущности (comment-photos) [code-styling, performance]

---------------------------------------


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