Это очень обширная тема...

Sumo 18.06.2010 10:40

Выбор правильного решения сильно зависит от задачи, а не от типа запуска процесса Парсера (скорее всего в общем времени обработки запроса запуск интерпретатора не будет самым существенным этапом).

Простейшие шаги по оптимизации такие (порядок важен):
- Тщательно подойти к проектированию структуры базы данных и настройке СУБД. Как правило, именно БД является самым узким местом, которое и создает большинство проблем с производительностью. Крайне рекомендую почитать по этой теме книжку Шварц, Зайцев, Ткаченко, Заводны. MySQL. Оптимизация производительности, 2-е издание.
- Акуратно пишите код, не доставайте лишних данных из БД и т.д. и т.п. И не забывайте о профилировании - т.е. анализируйте время исполнения потенциально проблемых участков кода, sql-запросов и пр.
- Кешируйте все, что возможно. Правда возможно это не всегда, но простейшее кеширование Пасреровским ^cache новостей или rss-лент может дать значительный прирост производительности.
- Разделите веб-сервер на две части: reverse-proxy (фронтенд, скажем, тот же nginx), которы пересылает запросы на сервер приложений (бэкенд), для которого можно использовать связку apache+parser-cgi или apach13+mod_parser3. Второй вариант дает ощутимый прирост производительности, если в проекте используются xslt-шаблоны. При подобной схеме на фронтенде можно попробовать организовать умное кеширование, которое вообще не будет дергать бэкенд без необходимости.

p.s. Со сборкой Парсера, веб-серверов и СУБД и прочих компонентов вам все-таки прийдется разобраться.
p.p.s. Дмитрий Котеров. Заметки про фронтенды, бэкенды, балансировщики и тому подобное

---