Евгений Вольф

PHP там надо запускать в CGI режиме, что существенно снизит скорость работы

Есть же FCGI или как Вы уже успели заметить далее есть PHP-FPM... Из оставшегося, я бы посоветовал PHP-FPM, т.к. он есть уже готовый и настраивается "в два клика".

Изучил весь httpd.conf, перекопал кучу гайдов по highload (они старые и с сомнительными советами типа "отключить лишние модули"

Один из первых модулей, который стоит отключить у Apache'а, для скорости - это поддержку файлов .htaccess, сама эта поддержка производительности не добавляет, а наличие этих файлов - уж и подавно.

1) Это у всех VPS так называемый "мощный" процессор медленнее, чем на каком-то жалком хостинге, пусть и с VIP-тарифом?

Нет, возможно это у Вас, персонально, какой-то дрянной VPS-хостер, или того хуже, тариф аки "OpenVZ, мы не перепродаём проданные ресурсы... ну разве что раз 10, но больше не перепродаём"

2) Поможет ли в такой ситуации FastCGI?

FastCGI - это режим работы PHP, напрямую, на производительность в значительной степени он не влияет, более того, сама логика работы FCGI (если сравнивать Apache-FCGI и Apache-mod_php) будет медленнее, по тому как для взаимодействия FastCGI будет использоваться сокет ("обычный" или unix-сокет), что подразумевает сетевое взаимодействие, вместо непосредственной работы интерпретатора PHP "внутри" сервера. Думаю, Вам поможет несколько другое (постараюсь описать ниже).

3) Почему не популярны фишки типа eAccelerator (кеширование AST и т.п.)?

Понятия не имею, почему они не популярны и откуда у Вас такая статистика... Но, возможно, дело в том, что eAccelerator морально и физически устарел, и если верить например, вот такой банальной статье (нет, я не работаю с такой "шедевральной" CMS как "Битрикс", просто это первое упоминание про eAccelerator, которое пришло мне в голову) - с версиями PHP выше 5.3 не работает.

Я знаю, что многие из них заброшены, но это не причина, а следствие.

Не могу прокомментировать это, так как Вы не указали следствие - чего именно. Другими словами, я не совсем понимаю, что Вы хотели этим сказать.

4) Что еще может помочь?

Ну так, сходу, по памяти (варианты могут быть не связаны между собой):
1. Отказ от поддержки .htaccess в Apache или хотя бы сокращение их количества
2. Установка Nginx в качестве фронтального сервера, для отдачи статики
3. Полный отказ от Apache вообще и переход на Nginx+FCGI (только не подумайте, я очень люблю Apache за его гибкость в настройке и широкие возможности, другой вопрос, что мало кому эта гибкость фактически нужна и мало кто способен его грамотно, качественно и полноценно настроить... Nginx в этом плане будет куда попроще). Почему FCGI? По тому, что другой приемлемый способ взаимодействия Nginx'а с PHP мне не известен. Настройка FCGI-пула - обязательна.
4. OpCache - с версии 5.5 встроено "искаропки", к включению и настройке - настоятельно рекомендуется. Я не знаю, как обстоят дела с CMS и используете ли Вы CMS на сайте, но из моей практики, скорость работы PHP-фреймворков возрастает в среднем 8-20 раз.
5. HHVM, как альтернатива
6. Проверка:
а) Того, что дело действительно в PHP. В частности, стоит собрать все логи сервера, например, сколько длились запросы, в БД, их количество и так далее.
б) Проверка скорости работы дисковой подсистемы... Не буду "тыкать пальцем", но одно время я арендовал довольно большое кол-во VPS'ок у одного популярного хостера, и в какой-то момент, я заметил, что средняя скорость работы дисковой подсистемы - 1.4Кбайт/сек., при этом "отказы" (аки "невозможно записать блок") были примерно в 50% случаев... это продлилось не очень долго, но и через несколько месяцев, у этого же хостера, тарифы с "обычным HDD", почему-то обладали более быстрой дисковой подсистемой, нежели тарифы с "быстрыми SSD"... можно сделать выводы...
в) Проверить реальную скорость работы процессора, не редко она отличается от завяленной достаточно сильно.

P.S. Если Вы сформулируете вопрос(ы) более точно - я смогу дать более точные рекомендации, если конечно они Вам нужны :)

P.P.S. Есть вариант решения проблемы вообще "в лоб", самый наверное сложный и пожалуй самый производительный в ряде случаев. Это Varnish + тонкая настройка оного, позволяет выдавать большую часть страниц из кэша (оперативной памяти) за наносекунды, иногда позволяет обслуживать очень много тысяч запросов в минуту, при этом, это не просто кэширование кода или что-то подобное... это кэширование целиком страниц и/или ответов сервера. Среди прочего - позволяет "не трогать бэкенд вообще", т.е. при запросе страницы, может не быть ни обращений к БД, ни выполнения того же PHP (или любого другого) кода, на стороне сервера. Требует довольно тонкой настройки, не очень подходит для сайтов "на CMS", для сайтов на фреймворках - требует изначально корректного подхода к разработке и продумывания того, что и как будет/должно кэшироваться. При некорректном подходе - наиболее вероятный результат - работать будет, но не так быстро как хотелось бы, а часть сайта вообще может перестать нормально функционировать. Есть так же другие решения, но с учётом довольно общих формулировок вопроса - говорить о них довольно сложно.

Ах, да, забыл важную деталь... Почему "хостинги" используют Apache и не откажутся от него (совсем)? В большей степени по тому, что Apache позволяет делегировать часть настроек пользователю через .htaccess. При этом, для статики не редко стоит всё тот же Nginx, который, как Вы понимаете, подобным образом делегировать часть настроек пользователю не позволяет, в виду чего для этих задач не подходит и не "буксует" на этом (в отличии от Apache'а). В т.ч. и по этому, мы на 99% отказались от "хостингов" (по причине наличие Apache'а, и невозможности от него избавиться или самостоятельно настроить, и как следствие "тормозов" которые приходят вместе с подобным подходом).

Подскажите плз, как в апаче отдавать указанный файл на любой запрос?

У меня вот так работает:

RewriteEngine On
RewriteRule ^(.*)$ luboy_file.txt [L]

Ещё есть вот такой вариант:

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]

Он означает примерно следующее:
Если запрошенный адрес - не директория (т.е. такой директории не существует) и если запрошенный адрес (URL) не файл (т.е. такого файла не существует) - то отправлять все запросы на файл index.php и прекратить дальнейшие проверку/выполнение правил (флаг [L]).

Подскажите, пожалуйста, куда смотреть? Опыта мало, поэтому плохо понимаю, с чего вообще начать.

1. Смотреть трафик
2. Смотреть список процессов Apache

Apache, при неверной настройке может иногда натворить чудес :) Файлов больших нет? Версия Апача?

P.S. Банально запустите top и посмотрите, что процессор грузит, сколько этих процессов и т.д. Апач может быть "входом" в проблему, но неё источником.

Если они попали в индекс яндекса, соответственно, ссылки откуда-то взялись? Яндекс то сам по себе ссылки не придумывает, как мне кажется. Соответственно, нужно искать первопричину их возникновения (таких вот, "левых" ссылок, на сайте)

Далее, если у Вас в адресации используются напрямую файлы php, рекомендую отключить mod_rewrite (или другой аналогичный модуль), и проблема пропадёт сама собой.

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

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

1. Обратиться в поддержку провайдера и купить него внешний/"Белый IP", или получить подробности по этой теме.
2. Вывести ноутбук в DMZ (демилитаризованная зона) и/или настроить на роутере переадресацию всех входящих соединений на 80-ый порт на IP'шник ноутбука. 99% роутеров работают в режиме NAT, благодаря которому, пакеты из вне, самостоятельно не могут (в основном не могут) достигнуть получателя, если он сам не инициировал соединение. По другому это ещё может называться "проброс портов". Инстуркции можно найти в руководстве к роутеру.

P.S. Порядок действий именно такой.

P.P.S. Если IP уже белый, но динамический - можно воспользоваться сервисами типа тех, что описываются например здесь.

а если все сайты принадлежат разным пользователям, то как поступить в таком случае?

Установить права на файлы (в частности php-файлы) таким образом, что бы FPM-PHP мог их как минимум читать.

А вообще, в FPM-режиме, обычно создаётся столько пулов, сколько пользователей и каждый из них работает от своего пользователя, и проблема соотв. отпадает сама собой.

У меня два варианта:
1. Вписать в сам index.php проверку на текущий URL/Домен и отсутствие в нем доп. параметров и сделать простую конструкцию типа

if ($_SERVER['HTTP_HOST'] == 'domain1.com')
{
    require('domain1.html'; exit;
}
//Остальной код

Либо, попробовать как-то вот так:

<If "%{HTTP_HOST} == 'www.example.com'">
DirectoryIndex domain.html
</If>

*за правильность не ручаюсь, возможно оператор сравнения на равенство в .htaccess пишется как-то по другому...

Пример взят отсуда, раздел Canonical Hostnames.