Добрый день.
Как показала практика лично мне, для небольших, но грузящих вебсайтов, lighttpd самое оно.
В конфигурировании тоже достаточно гибок, прозрачен и имеет юзерфрендли конфигуратор.
Вот вопрос: какие камни могут встретиться при такой миграции?
Один найден: htaccess/htpasswd/mod_rewrite обходятся достаточно нестандартным способом, через конфиг.

Какие еще если отличия от "стандартного" апача?
Заранее спасибо.

Как лайти не крути а nginx быстрее будет

Успешно перешел на лайти.
Ударился головой очень больно об rewrite .
Как оказалось, встроенных средств рерайта в зависимости от существования файла сей вебсервер не имеет. (Ключи -f -d)
Как альтернатива - видится mod_magnet + скриптинг на lua . Но это через какие-то дальние дали, хотя появление такого инструмента расцениваю положительно.
Может сталкивался кто?
Заранее спасибо.

А можно было поставить nginx и не мучаться.

либо у меня карма такая, либо руки, что даже примеры с сайта nginx не заработали
В любом случае, бездаунтаймные миграции с лайти на nginx будут проще, чем с апача

Зачем рубить дерево топором если легче пилить бинзопилой?
Учите nginx, пригодится!

Лайти по настоящему хорош только под свои проекты, если они изначально пишутся с учетом такого сервера. Иначе - ngnix куда предпочтительнее.
Если не заработали базовые примеры, то что - то очень странное - ставится он безпроблемно

может потому что из пакетов ставил?
Да, знаю, что хорошо бы и собрать.

В любом случае, php@fastgi один, nginx много не съест, буду пробовать до победного конца.

+1 за nginx.
Мигрировали несколько своих проектов на сервер с nginx'ом и с реврайтами проблем небыло. Да поначалу немного не привычно, но потом... Вопросов нет.
Как и говорилось ранее:

Так-же, +1

nginx заработал.
Вот оказывается, документация на английском куда проще и понятнее оригинала.
Только вот для каждого виртхоста(16шт) по запущенной пачке fastcgi, не очень ресурсосберегающая затея.
Но это уже много менее серьезная проблема, чем первая

Зачем пачку fastcgi к каждому виртхосту?
Одна пачка способна обслуживать все виртхосты. Читая маны еще и обдумывать надо прочитанное...

Понял. Даже представляю как оно выглядит(что куда убрать).

Делаете спавнер fastcgi, запускаете php-cgi процессы им, каждый виртуальный хост в nginx натравливаете на на сокет или на порт fastcgi.

я уже решил проблему именно этим способом(через порт)
Но все равно спасибо.

В общем все проблемы с nginx, какие возникли решились очень просто.
Основная их причина в том, я по какой-то непонятной причине боялся его собирать (после сборки оно видимо должно было поработить мир, но этого не произошло*, а жаль), все прекрасно заработало.

Даже жалко, что всё так просто решилось. :(

-----
*а вот апач поработил и продолжает это упорно делать.

В корне не согласен. Для nginx есть замечательный модуль mod_aclr. Ставите на апач этот модуль, перед апачем вставляете nginx и получаете очень быструю и производительную схему. При этом ни реврайты переписывать не нужно, ни каких либо других манипуляций выполнять. Апач как был так и есть, просто перед ним прозрачно встает nginx и отлично разгружает апач. Дело в том, что апач беспроблемно может обработать много запросов в секунду, если не будет заниматься отдачей контента. mod_aclr как раз призван переложить отдачу контента на nginx, если apache разрешит такое действие. Дело в том, что mod_aclr отрабатывает самым последним, т.е. указывает nginx'у что делать только после того как уже отработал mod_rewite и прочие, а значит Вы можете легко писать апачевские реврайты, паролировать директории средствами апача и быть уверенным в том, что статический контент будет отдаваться nginx'ом и будет отдаваться правильно, т.е. только по запросам, которые успешно пройдут всю внутреннюю логику апача (фильтры, пароли и т .д.), а те, кто не должен получить контент (не авторизовались, ip в бане) - его не получат.


Глупости Вы делаете. Право слово. Смотрите в сторону mod_aclr. Не пожалеете.
P.S. Апач умеет спавнить fcgi процессы на лету при поступлении запроса и прибивать после N минут бездействия.

Угу, но работает только для apache1.3

Вообще, проблема не столько в отдаче статики nginx'ом, сколько в уходе fork-per-request и тяжелый-процесс-per-request.

Спасибо за рекомендации, но я уже "переехал" и возиться с nginx намного приятнее, чем с апачем.
Он позволил достаточно просто снять часть работы с нагруженных скриптов, и сервер стал реально тратить меньше процессора и памяти и без особых проблем пережил очень легкий флуд, который достаточно просто был задавлен средствами фаервола.
По поводу "поставить апач на зад": рассматривал и даже реализовал, все работало неплохо, но необходимость в апаче отпала, я натренировался писать рерайты и оперировать синтаксисом nginx что называется с листа

Сейчас прекрасно справляются 4 процесса CGI и один отдельный у мониторинга с другими uid|gid.

То решение, которое искал, я нашел, благодарю всех высказавшихся за помощь и советы.