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

Но чтобы приготовить апчхач надо всё-таки постараться, nginx работает более-менее удовлетворительно из коробки, реврайты в нём намного проще, чем у индейца. Да и проксирование организовать тоже намного проще в жинксе, чем у апача. Если не хочется терять время на раскуривание апача в проде, то берёшь nginx и раскуриваешь его.

Заминка в том, что если ты берёшь apache httpd, то про mod_{perl,python,php} надо сразу же забыть. А формально это то, ради чего и поднимают апчхач. Кроме того, .htaccess/реврайты тоже работает более, чем странно, когда у нас на приложение идёт проксирование, то есть он тоже отпадает. Это вторая киллер-фича апача, ради которой ставят апач. Остальное настраивается более сложно/странно, чем в случае с nginx-ом.

Собственно, если у тебя апач работает фронтом, кэширует или раздаёт статику и проксирует запросы в бэкэнд... то по скорости он +/- nginx, но, правда, по набору функций он победнее будет.

Если у тебя httpd работает бэкэндом, то его роскошное api можно использовать для написания приложений на c/c++ и это будет работать очень быстро, но.... есть различные либы, которые умеют в fcgi/http и мультиплексирование и на основе этого можно сделать отличное приложение и в таком случае апач нам не понадобится.

А с момента появления uwsgi-2.0.9 и nginx-unit апачовый passenger для рубей тоже отошёл в историю (в своё время это был единственный по-настоящему продовый в смысле предсказуемости поведения и производительности способ завести рубёвое приложение, но сейчас пассажир уходит в закат).

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