Спустя три года с момента прошлого обновления представлен новый выпуск Apache-модуля mod_perl 2.0.11. Mod_perl позволяет интегрировать интерпретатор Perl в http-сервер Apache и увеличить скорость выполнения динамического контента на Perl за счёт кэширования его байткода, а также обеспечить низкоуровневый доступ perl-скриптов ко внутренностям Apache, в том числе даёт возможность создавать модули на языке Perl, управлять конфигурацией, обрабатывать все стадии прохождения запроса...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51624
В 2019 это уже скорее не нужно
Причем, не "это", а "оба". И апач, и перл.
Если вам лично не нужно, то это ничего не значит.Старичок Apache ещё всей хипстоте даст фору https://w3techs.com/technologies/overview/web_server/all
Я уже привык, что местные анонимы все легко знают на свете.
В отличие от анонимов апач работает
Апач - это как php, давно уже ненужно, есть полно более лучших вариантов. Но кто-то продолжает пользоваться по инерции.
Всё так, вот только все эти "более лучшие" варианты "более лучши" только в головах упоротых по ним хипстеров, а реальных юзкейсов у них полторы штуки.
> Всё так, вот только все эти "более лучшие" варианты "более лучши" только
> в головах упоротых по ним хипстеров, а реальных юзкейсов у них
> полторы штуки.В случае с апачом - он жрёт больше ресурсов и может обслужить намного меньше запросов, при тех же равных, чем nginx. Есть и совсем запущенные случаи, когда ставят апач+nginx, чтобы совсем жизнь лёгкой не казалась. Я понимаю ещё когда на шаред-хостингах апач, а иногда апач+nginx - ещё можно как-то понять. Но, а так, если не нужны какие-то специфичные модули апача - нет смысла его юзать.
Я что-то проспал и нгинх стал уметь динамику без костылей?Открою секрет - и не будет уметь никогда. Его модель работы не предполагает серьёзных задержек внутри отработки запросов. Поэтому там, где динамика - либо апач, либо подпорки и костыли в виде fpm, nginx unit и т.п.
Да, вы проспали появление openresty и аналогов.
> Да, вы проспали появление openresty и аналогов.openresty - это самый жуткий костыль из всех костылей, которые я видел, если честно. Попытка закостылить незакостыливаемое. Я понимаю, что хайп, (ложное) чувство патриотизма и всё такое - но возьмите себя в руки: этот продукт пригоден в эксплуатацию, разве что если вам больше заняться нечем.
В каком месте это костыль?Встроили сервер приложений в вебсервер, чтобы убрать реверс-прокси и промежуточный протокол общения с сервером приложений. На нагрузке с большим rps это оправданное решение.
>Я понимаю, что хайп, (ложное) чувство патриотизма
Щитоа? Попуститесь, сударь.
> может обслужить намного меньше запросов, при тех же равных, чем nginxПропущено "на статику / в режиме прокси" после "запросов". Причём для второго haproxy выглядит куда продуманнее.
Жрет больше ресурсов чем что?
Если сравнивать php-fpm и mod_php, разница в расходе памяти будет на единицы процентов. Особенно если потюнить апач.
С тех пор, как угнездился мем об отсталости апача, в нем появилась быстрая отдача статики, которая мало уступает нгинксу.Так что если вам не нужны фичи нгинкс и разница в 5-10% производительности не является критичной - можно брать апач. Работать будет хорошо.
В случае perl все гораздо интереснее. Mod_perl вчистую выиграет у модулей, реализующих FCGI на уровне приложения. Потому что парсеры этих промежуточных протоколов написаны на самом перле и при разборе больших запросов могут даже подвесить сервер. Приличных, годных к продакшену http-серверов для perl нет. Да и большинство приложений написаны так, чтобы выполняться синхронно, в контексте CGI.
Недавно появился nginx unit, возможно он лучше, чем mod_perl. Но это пусть знающие люди комментируют.Короче, не надо лепить о том, о чем не имеете представления. Не повторяйте за дурачками, чтобы самому не казаться дурачком.
PS Я сам очень люблю nginx и умею его готовить ( ко всему ). Использую с версий примерно 0.7.
>он жрёт больше ресурсовэто про prefork? или при всех равных используемую нгинксом память мерили без учета чего-то типа php-fpm?
>может обслужить намного меньше запросовотключите обработку .htaccess.
Да, ресурсов (памяти) связка nginx+apache (mpm-prefofk) потребляет больше чем nginx+php-fpm - ну и что ?Если ресурсов сервера конкретного проекта (а не сферического коня в вакууме) хоть попой ешь и даже под максимальной нагрузкой для этого конкретного проекта памяти хватает для всего включая файловый кэш с запасом - то чем эта связка хуже то ?
В плане "быстродействия" сайта никак не уступает, для сайтов на Битрикс скажем такая связка вообще предпочтительнее. Так что не надо быть настолько категоричным.
Да и за доброй половиной нгинха/флейра там всё тот же апач.
Вопрос всем упоротым: на чем работает опеннет?
На ЭВМ.
> На ЦЭВМ.Не благодари.
Я не упоротый, но отвечу :)
nmap -sV www.opennet.ru
Starting Nmap 7.80 ( https://nmap.org ) at 2019-10-06 15:35 MSK
Nmap scan report for www.opennet.ru (94.142.141.14)
Host is up (0.59s latency).
rDNS record for 94.142.141.14: opennet.ru
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
53/tcp open domain dnsmasq 2.78
80/tcp open http nginx
443/tcp open ssl/http nginx
> Я не упоротый, но отвечу :)
> nmap -sV www.opennet.ru
> Starting Nmap 7.80 ( https://nmap.org ) at 2019-10-06 15:35 MSKА можно было сделать просто:
$ HEAD opennet.ru
200 OK
Connection: close
Date: Sun, 06 Oct 2019 12:57:17 GMT
Accept-Ranges: bytes
Server: nginx
Vary: Host
Кстати, опеннет уже на линухе или все еще на той самой, "рипнутой и старперской" ОС? ))
# nmap -A -T4 opennet.ru | grep ^OS
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.10 - 4.11, Linux 3.2 - 4.9
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# nmap -A -T4 pair.com | grep ^OS
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.10 - 4.11
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Судя по виду, на перле. Ну я так подумал до того как посмотрел в адресную строку. РИП, перл, кои8р, опеннет собрал всё самое лучшее из интернетов (лет 20 назад такое сошло бы конечно, не спорю).
Разрешив пользователю изменять настройки сервера, вдруг обнаружили что он этим воспользовался...Как он мог....
.htaccess предназначен для того, чтобы менять только настройки, относящиеся к отдельному каталогу. А тут полный доступ к управлению конфигурацией, если верить новости.
Ну дык юзер и изменял настройки каталогу. В одном включал перл, в другом - нет ;)
Впрочем, mod_perl в конфигурации со многими пользователями - это явно перебор. Он ведь не умеет от имени юзера работать.
Есть же PSGI/Plack и довольно производительные сервера, starman, Twiggy.
Использую связку nginx+starman+Plack.Mod_perl вспоминается с теплотой, но сейчас, все таки, немного устарел.
FCGI?
Я про это.
Вот ругают тут апач, а что думают, интересно, насчёт lighttpd, лайти вроде был неплохо, на то он и "лайт"...
Апач конечно неплох, но у нджикса конфиги удобнее.
А вы прямо ежедневно конфиги меняете, да?
У nginx'а уже запрет на симлинки освоили? Или таки продолжают бороться за производительность? ;)
Если юзеров на сервере больше одного, то Apache единственный и неповторимый.