@@t0digital а я системный программист на С++ и понятия не имею что у вас происходит в мире веб-разработке. но всё в целом было понятно за исключением специфических названий nginx) мир С++ и дружит с многопоточностью и всегда за скорость работы на железе.
Вообще сам лого Apache, это перо - вызывает у меня чертовскую ностальгию:) 2004й, я в 11м классе, первая книга по веб-технологиям, тонкая такая брошюрка в мягком переплёте, рассказывающая, как поставить Apache на Windows и прикрутить туда PHP 3й или 4й версии. Это всё тогда, конечно, было просто космического, крышесносного уровня магией, захватывающей и интересной. Интернета почти не было - по модемным карточкам, которые стоили 60 руб за, если не ошибаюсь, пол часа доступа к сети, которых никак не хватало, чтобы хоть что-то оттуда выцепить. Да и 60 руб это была сумма тогда. Дааа:) Не могу не улыбнуться, вспоминая то время:) Может видос отдельный про это снять?
Делаю вклад в комюнити Apache, и вы знаете меня постоянно поражает стереотип о сравнении nginx Vs apache. И я могу с уверенностью сказать что Apache есть место и в 2020 году, да и в будущем тоже. Но вот мой ответ на стереатипное утверждение что apache не для highload. 1. Не секрет что у apache есть те же самые воркеры в mpm modules, возьмите mpm_event настройте, и будет такой же функционал воркеров-потоков. 2. Так же не секрет и поддержка php-fpm в apache, а в конфигурации fastcgi, php-fpm(UDS), apache обходит nginx по скорости выполнения скриптов, даже unity режим nginx'a обходит. 3. Этого еще нет в оф релизе apache, но это уже заложено в исходники apache, поддержка PCRE2, что может говорить нам об улучшения в производительности apache модуля Rewrite который отвечает за работу htaccess. Я даже написал статью по этой теме на хабре, Как сделать поддержу PCRE2 в Apache 2.4. 4. Финальный момент для статики положительно будет поддержка Pcre2, Ну и конечно поддержка HTTP 2.0 принесет скорость обработки запросов, и статики в том числе. С такой конфигурацией можно забыть о стереатипах стекла веб сервера, и идти в будущее, в ногу со временем. Интересно будет увидеть цитату автора ролика к этому комментарию.
@@qa337 Вижу дилетантов из далека Хмм) Во первых в Apache из коробки это тоже делается в пару строк, те включить модуль mpm event для fpm-fcgi и proxy_fcgi, и строчка в конфиге виртуалхоста proxyPass на php-fpm TCP socket(Софт может умереть из коробки или даже не запуститься только у тех кто не умеет его запускать). Во вторых что за пару строк, если это для локалки и проекта аля hello world, тогда да, а если это окружение для какого нибудь проекта, то это уже не пара строк а полноценная настройка конфига. А еще об этом мало говорят пользователи nginx но в нем есть такие же модули и расширения, у которых есть тоже доп настройки и даже конфиги, да и вобще оба сервера одинаковые по функционалу просто по разному реализованы и имеют разные модули или расширения вот и все.
Я бы закрепил ваш комментарий, будь на месте автора. Апач также умеет проксировать запросы на сервер приложения. и использовать разные версии интерпретаторов. Сам недавно настраивал несколько доменов на разных версиях рнр
Благодарю! Снова всё, наконец-то, уложилось по полочкам в голове. Алексей, у вас великолепно получается подавать материал! Величайше благодарю за всю вашу работу!
Привет, коллега. Классный контент, подпишусь на канал. Я не согласен с тем что apache настраивается легче чем nginx, как по мне второе намного легче, и документация более понятная. И ещё ты не упомянул о куче модулей для nginx и о возможности расширении функционала с использованием lua
Вообще к пониманию статистики веб-серверов стоит учесть, что чаще всего в highload проектах, то чаще всего идет nginx как frontend прокси для статики и балансировщик для нескольких apache, которые идут backend`ом. И в целом nginx все же чаще используется именно как проксирующий сервер, и это относится не только к понятию web-сервер
Если в вопросе скорости, то как помню, как раз mod_php для apache самое быстрое решение. Но оно обладало огромным (для некоторых случаев) недостатком это невозможность разделение ресурсов по пользователям. Все скрипты выполнялись от имени владельца apache, и пользователи могли свободно шариться по соседним каталогам. Как раз FastCGI решило это проблему, но за счет некоторого снижения производительности ввиду необходимости стартовать новые процессы (php-cgi), а не выполняться в уже запущенном apache. Nginx со своей асинхронностью привнес снижение нагрузки на железо, более шуструю работу со статикой, соответственно появилась возможность обслуживать большие нагрузки. Его часто стали ставить на фронт перед апачем. Он отрабатывал статику и проксировал php на апач, а тот в свою очередь на FastCGI. Проблема htaccess уже тут начала вырисовываться. Так как от апача было бы интересно отказаться, но очень много CMS тогда использовали htaccess (собственно и сейчас так, но именно сейчас крайне много информации по переносу htaccess на правила nginx и это уже не вызывает сложности, так же панели управления серверами научились автоматом вставлять эти правила в конфиг nginx). Могу ошибаться, но вроде бы быстро fast-cgi сменился на php-fpm. Это повысило скорость выполнения php и, опять же на сколько могу помнить, сравнялось по скорости с модульным php. Но при этом оставалась возможность выполнять скрипты от имени владельца. После этого апач стал ну вообще ни при делах. Оставалась только загвоздка с htaccess, но, если это был не сервер шаред хостинга, то решалось однократной настройкой на этапе установки ПО и запуска сайтов. Варианты с версиями php для apache были и ранее, помню были шаблоны конфигов которые по расширению файла выбирали версию модуля для обработки. В этом случае дописывалась версия php после расширения файла, например, index.php5. С переходом на FastCGI задача выбора версии PHP вообще сильно упростилась и до сих пор не является чем то сложным.
Nginx, вообще-то, еще как настраивается на отдельные директории. Достаточно положить name.conf в любую директорию и заинклюдить этот файл в главный конфиг сайта.
Однажды меня заинтересовал NGINX. Рекламировали, что держит большой трафик посещений... Повелся и попробовал. На счет того, что NGINX тянет высоконагруженные сервисы, а Apache нет или же ему это делать тяжелее, это же брехня. Да NGINX легче чем Apache и на небольших нагрузках разница есть. Но только начинаешь грузить по-сильнее, как разница по-тихоньку "уходит в туман". Есть, конечно же, сугубо частные случаи, но они не всчет. В сравнении с Apache, какой-то разницы в потере производительности не заметил. ~1500 запросов в секунду перед тем как сервер с Apache начал захлебываться, сервер с NGINX лег где-то уже после 1000. Нагрузка поднималась экспоненциально. В добавок Apache может намного больше. А на высоко нагруженных сервисах можно использовать FastCGI и сэкономить ресурсов дополнительно (если вы разрабатываете эти сервисы). На счет того, что Apache не может работать с двумя версиями PHP... И ты не можешь назвать профессионалами людей, которые не умеют работать с обоими (NGINX и Apache) серверами? Я лично поднимал сервер, который работал и с PHP5, PHP7 и Python... Просто нагуглил и ради интереса поднял. Было несколько лет тому назад, вспомнить тяжело, но принцип работы такой: задаются условия и указывается модуль *.so, который будет обрабатывать запрос. Этим методом можно обработать скрипт, практически, на любом языке (с оговорками, конечно). Да, это костыли, но по-другому никак и даже в NGINX... PHP (5 или 7) и Python использовать еще можно, но PHP5 и PHP7 одновременно использовать без боли и слез уж никак (да и не знаю где это нужно вообще, на хостинге разве). Я уже молчу про пляски с одновременной установкой их на один сервер. Проксировать запросы это просто фигня полная. Как это можно записывать в положительные качества не понимаю. Это просто есть по-умолчанию (такое можно написать на коленке для любого сервера), да и как оно проксирует? Костыли же...
Ох дичи то сколько ты написал. Ну начнем по порядку.. > ~1500 запросов в секунду перед тем как сервер с Apache начал захлебываться, сервер с NGINX лег где-то уже после 1000. Это какие запросы? К статике, или к пхп? Если к статике, то ты нагло врешь, если к пхп, то ты уверен что лег nginx а не php-fpm? > На счет того, что Apache не может работать с двумя версиями PHP Может, но это либо на разных mime-types (.php на php5, .php7 на php7), либо через переопределением .htaccess (и то, емнип, при suexec нельзя через .htaccess переопределять интерпритатор) > Да, это костыли, но по-другому никак и даже в NGINX... PHP (5 или 7) и Python использовать еще можно, но PHP5 и PHP7 одновременно использовать без боли и слез уж никак Эта дичь только показывает твою некомпетентность в настройке nginx. В nginx управлять различными бекендами (а php-fpm, spawn-fcgi, и т.д. это именно бекенды) делается легко, через блок upstream, и соответственно в том локейшине в котором тебе необходимо чтоб твой пхп обрабатывался другим интерпретатором указываешь другой апстрим. Управлять на уровне локейшина, регекспов, и т.д. Делается гораздо проще чем в апаче. > Я уже молчу про пляски с одновременной установкой их на один сервер. А в чем проблемы с одновременной установкой различных версий пхп на сервер? Сейчас у многих дистрибутивов разделяется в путях версии пхп, и можно ставить прямо из пакетного менеджера. По сути ты просто не разобрался в том как работает nginx, и сложил негативное мнение о нем. Плюс немного дичи. Советую тебе поработать побольше, и почитать побольше инструкций. Не даром nginx занимает большой % вебсерверов в мире. Ну и nginx это не только ВЕБ-сервер, это и tcp-proxy (этого апач не умеет), и почтовый, и мультимедиа (rtmp).
@@sysadmincomua - Это какие запросы? К статике, или к пхп? Если к статике, то ты нагло врешь, если к пхп, то ты уверен что лег nginx а не php-fpm? Я не знаю где еще сейчас статику используют... Лег именно nginx, даже если бы это был php-fpm, мне глубоко ... что легло. Почему с Apache такого не произошло? - Эта дичь только показывает твою некомпетентность в настройке nginx. И? Меня это должно огорчить? Не умею настраивать какое-то дно, которое используют только изза того, что оно быстрее, но на самом деле оно для этого не годится? Конец света. У меня нет необходимости использовать несколько интерпретаторов php на одном сервере. - А в чем проблемы с одновременной установкой различных версий пхп на сервер? Сейчас у многих дистрибутивов разделяется в путях версии пхп, и можно ставить прямо из пакетного менеджера. Особенно рассмешило: "Сейчас у многих дистрибутивов разделяется в путях версии пхп, и можно ставить прямо из пакетного менеджера." Да ты по ходу "пороху не нюхал", а еще говоришь, что я не компетентен))) Я даже не буду пытаться объяснить... - По сути ты просто не разобрался в том как работает nginx, и сложил негативное мнение о нем. Плюс немного дичи. Я и не собираюсь - уже давно забросил и забыл. - Советую тебе поработать побольше, и почитать побольше инструкций. Не даром nginx занимает большой % вебсерверов в мире. У меня достаточно более полезной читанины... Большой процент, это сколько? Это примерно половина от того, что занимает в серверном мире Apache. - Ну и nginx это не только ВЕБ-сервер, это и tcp-proxy (этого апач не умеет), и почтовый, и мультимедиа (rtmp). Он не умеет нормально WEB-сервер, а для остального есть остальные инструменты.
Оч крутой видос!) Хорошо, что я знаю что такое процесс, поток, асинхронная обработка запросов и application-server)) Кстати, по поводу конфигов. Получается, что Apache считывает htaccess каждый раз, а Nginx считывает один раз и держит эту информацию в оперативной памяти? Интересно кстати, что получится если сравнить NginX и какой-нибудь сервер на платформе Node.js.
Жалко что у чувака мало просмотров и подписок, а то у всех кликбейтные видосы как стать программистом за 1 час и всё такое... Продолжай в том же духе, у меня есть темка - сделай сравнение например сервера на питоне и джаве - в питоне я знаю нельзя сделать многопоточность а в джаве можно, или все таки в питоне можно сделать?
Спасибо:)! В питоне можно и многопоточность, и асинхронность, сейчас обычно для этого asyncio / aiohttp используют. У нас есть в продакшн много асинхронного питон кода, работает оч бодро:)
@@t0digital сделай видео со сравнением сервера асинхронного и многопоточного на примере питона, где лучше юзать а где нет, где легче программировать а где нет, в общем плюсы и минусы
Лайк я под видео поставил(ровно 400тый 😊), но все же как то однобоко. По статистике вопрос, в графике nginx на котором крутится сайт или просто он отвечает клиенту, а сам стоит как кэширующий прокси и сайт на том же апаче. Апач работает не только в связке с mod_php, но и fastcgi который с некими оговорками очень схож с php-fpm. В большинстве случаев использую fastcgi, но к примеру разработчики битрикса рекомендуют использовать mod_php со своим продуктом, поскольку в других режимах бывает не правильная работа движка. С производительностью nginx не поспоришь, но в жизни он хорош в синтетике, или когда это твой сайт который ты "вылизываешь", или очень крупный проект с хайлодом и распределением между серверами. В остальном производительности достаточно для связки нгинкс как прокси и апач, и она гораздо дешевле времени спеца. Зачастую после сдачи проекта весь прирост нивелируется напихиванием скриптов метрик и статистик, а так же заливкой 10 мегабайтных картинок. Отсутствие .htaccess добавляет уйму гемора, если это не твой сайт или крупная фирма с своим ресурсом и четко выстроенной вертикалью сотрудников. Обновление CMS рано или поздно вызовет проблемы. Не каждый программист умеет править конфиги nginx(да и апача) но ключевые параметры в .htaccess могут. Так же не уверен обрабатывает ли nginx ini_set() в скриптах. Тут уместно сравнить с python и с++. Если вдаваться в крайности то можно сайт написать и скомпилить в виде модуля веб сервера, скорость будет пушка 😂 Для меня золотая середина в львиной доле nginx proxy + apache.
Добрый день, спасибо за классный контент, хочу немного уточнить, апач в режиме прокси + режим worker по производительности схож с тем же nginx, не подтягиваем mod php и живём как в nginx
Nginx не может обрабатывать внутри себя языки программирования?) Автор ну блин... nginx.org/ru/docs/http/ngx_http_perl_module.html perl_set $perl_random_digit 'sub { return int rand 10; }'; Работает асинхронно. Воркеры не блокирует. Также есть модуль lua и php. В lua даже есть redis коннектор.
Привет. Можешь что-нибудь рассказать про django + celery + rabbitmq на каких-нибудь реальных задачах? В каких случаях такую связку следует использовать, а в каких можно чем-нибудь заменить?
@@t0digital Хм, и какой аналог celery ты можешь посоветовать для управления распределенными вычислениями, когда в очередь будет валиться большое количество cpu bound задач, которые должны разгребать и обрабатывать 20-30 серверов?
@@DmitryB876 Да можно и свой написать, любой брокер и в путь. Или искать-тестить аналог. У нас нет задачи параллелить задачи на десятки серверов, но Celery бы не стал туда привлекать.
@@t0digital Своё как я как раз и использовал python + RabbitMQ. Не удобно. Всё приходиться самому писать. Celery потестил - понравилось. И нагрузку держит. В продакшн пока не выпускал, но планирую. python 3.7 уже поддерживается c 01.04.2019 (celery 4.3): github.com/celery/celery/issues/5210
@@DmitryB876 Мы на celery в продакшн, но будем уходить. Задачи для нас это запуск долгих процессов из http запросов, чтобы запрос не ждал их, и запуск тасков по времени или периодически, обе задачи проще реализовать в отвязке от Celery
Пользовался изначально Apache. Единственное, что в нём могло бы понадобиться - это .htaccess. Как рассказали в ролике, других преимуществ у Apache нет. Зачем мне тогда на него ориентироваться при разработке? Ну да, если используешь какой-то готовый движок, то проще поставить Apache, чем вручную писать заменители .htaccess.
Расскажи пожалуйста про гуникорн. У тебя было как-то видео про весь стек Django сервера. А вот конкретного примера толкового нету:( И как ты относишься к docker?
Диджитализируй! АйТи студия как на счёт все это развернуть подробно в докере и запилить видос?) реально годного контента нету. Просто дефолтный сайт, но на сильном стеке
@@ЕвгенийОмельчук-э1ы докер не делает ваш стек сильнее, серьезно. Докер хорош, но он реально крайне редко нужен. Мы сделаем видео про разворачивание всего в докер - в реальности там всё сложнее в продакшн настройке, чем без докера, а бенефитов для 99% проектов - ноль.
Читал в какой-то книге/статье, что огромные сайты используют сочетание nginx + apache. Не вникал, ибо тема была мне не интересна. Там вроде говорилось, что nginx встречает клиентов, распоряжается статическим контентом и говорит что делать апачу, а apache работает под ним и отвечает за динамический контент.
Привет, у меня MacBook Pro 15, 2015 года. Машина зверь, мне хватает с головой и для разработки, и для монтажа 4K видео, хотя видеокарта в моей модели встроенная. 16Gb RAM, 256Gb SSD, i7 2.2GHz. С 2016 года в макбуках пошло очень много брака - с их новой клавиатурой, с экранами и тд, их брать уже стремновато, если честно:)
Много вариантов: за счет создания оптимизированных сборок своего софта "под ключ" + поддержка. Донаты. Реклама других поделок за счет известности самого своего бренда. Но главное, что в этой жизни нужно знать, - если ты не платишь в интернете за услугу\сервис(товар), значит этим товаром являешься ты) абсолютно все бесплатные "сервисы добра" зарабатывают на сливе контактов(почты, адреса, телефоны), поведенческих факторов, предпочтений. На основе слитых данных другие "добрые фирмы" откручивают у тебя 15 баннеров с рекламой на странице.
@@uhohwhy про опен сорс все совсем не так. Если разработчиков уличат в сливе данных - на проекте можно будет ставить крест. Основная статья доходов - это донаты сообщества и платная поддержка продуктов.
Я так и не понял, nginx+php-fpm чисто для php скриптов имеет преимущество в сравнении с apache+mod_php? Я понял, что сам nginx работает с соединениями более оптимально... но как работают с соединениями сервера приложений, на которые перенаправляются запросы, тот же php-fpm? Или при равных количествах одновременных запросов nginx+php-fpm всё же меньше создадут процессов и меньше употребят ресурсов, нежели apache+mod_php? Уточню, при условии что весь контент - исключительно динамический php.
__«Я так и не понял, nginx+php-fpm чисто для php скриптов имеет преимущество в сравнении с apache+mod_php»__ - ну так и mod_php, и php-fpm только php и запускают:) nginx + php-fpm обслужит больше одновременных запросов меньшим количеством процессов, чем apache+mod_php, да
Не все cms используют htaccess, а те, что используют в основном используют их с mod_rewrite - просто переписываются правила на nginx механизм. Некоторые cms сразу дают конфиги для nginx
NginX отдаёт их коробки статику , именно отдает и все. Обработать без модулей или связки с аапачем какие-то хитрые запросы он не сможет. И он виигривает в статике
для Apache как организации http сервер перестал занимать лидирующую роль довольно давно, и очень печально, что они во время не купили nginx или не перестроились когда он появился
Не всегда, но для ряда случаев его действительно легче настроить, под какие-то php движки (и это самый частый случай использования Apache по-прежнему), которые чересчур сильно завязаны на .htaccess файлы
@@t0digital но там в основном реврайты хранятся, так что немного натянуто. Что до самого лампа, просто он везде. Покупаешь сервер или впску, тебе сразу предлагают этот стек, ищешь мануалы, кругом лампы. Проще говоря, нгинкс не очень в маркетинге. Думаю после его продажи они в этом направлении поменяют политику.
@@Funny-rus в htaccess вообще говоря можно перезаписать любые настройки апача для директории, там не только реврайты. Реврайты настроить не проблема в nginx (хотя это надо делать ручками, а в апач заведётся само - это и есть усложнение настройки), но не все там в принципе можно красиво настроить в nginx из этих htaccess файлов. Много cms используют их очень тесно, вплоть до разных настроек php в разных директориях, прокидывают флаги в mod_php. А почему у nginx не очень в маркетинге? У него все хорошо. Homepage и мелкие сайты останутся какое-то время ещё на Apache, а все бодряе ребята уже давно на nginx переехали:)
@@t0digital ну переехали не из-за маркетинга, а из за того что как сайт переваливает за 10к в сутки он начинает дико лагать в часы пик. Я говорю именно про статьи на сайтах, те же ваши воспоминания про книжечку в 11 классе, у моего брата была такай же. Готовые стеки у хостингов, да что там если берешь хостинг, а не впс или сервер, то там о боги, апач! На самом деле нгинкс готов к работе после того как вы поставите php-fpm и раскоментируйте несколько строк в конфиге по умолчанию.
@@Funny-rus (для меня как новичка) то есть по сути можно настроить ngnix на полную и требуемую работу сайта без апача? я не понимаю в чем преимущество данной связки
Проще поставить говно-пхп движки аля Битрикс, завязанных на использование .htaccess файлов, и для ненагруженнных таких сайтов Aoache вполне хорош. Это его ниша сейчас. Название - есть ли место апачу? Ответ - есть, ровно для таких сайтов. Никакой спекуляции.
@@t0digital но я не согласен, что конфиг Апача проще настроить (что заявляется в видео). Nginx за полчаса настроил или меньше, когда решил на локалхосте попробовать
@@EdwVee много пхп движков завязано на htaccess файлы, и повторить то же поведение на nginx бывает крайне утомительно, не уверен даже, что всегда возможно без влезания в код движка
Как можно сравнивать nginx и apache в 2019? А особенно как можно сравнивать в разрезе php и python? Для обоих вариантов "апач сосет". Когда-то было время, когда nginx не умел все ф-ии apache'а, но они давно прошли, а выигрыш по памяти и процу - очевидный.
Поставить говно-Битрикс на апач сильно проще, чем на nginx и поэтому для таких задач апач ещё как жив и 2019, и будет в будущем. В этой сфере всем плевать, что он сосёт))
Ничего подобного. Траты ресурсов на настройку nginx и apache для битрикса однозначны. Да, битрикс как таковой, не пользуется успехом среди разрабочтчиков. Но когда речь идет про более менее "не джуна" (т.е. человек занимается уже хотя бы пол года и интересуется своей сферой). А в остальных случаях засчитывать "в плюс" этот ньюанс - неуважение к разработке в принципе. Имхо
Ну и плюс ко всему - апач жив еще не только по причине неадекватных разработчиков "для битрикс", но и для java и вобще он достаточно много для чего является "окном в мир".
Примитивный и стереотипный коммент/отзыв по теме Apache vs Nginx))) @Sergey Larionov У вас на тестах в сравнении этих http серверов прямо такие результаты/показатели как вы написали. Я бы не смог доверить вам настройку или проектированию окружения под настоящий проект, с таким опытом как у вас)
все легаси технологии, которые использовались раньше будут ещё лет 10 лидировать в статистике, потому что владельцу продукта проще(дешевле) поддерживать старый легаси проект, чем заплатить за новые технологии и новый идентичный продукт. PHP тоже лидирует по числу написанных сайтов, но я не знаю новых крутых проектов, где начинают писать web на PHP, если только динозавры какие-то и говноконторки
@@t0digital А почему бы мне просто не написать свой собственный сервер. Ведь в свою разработку гораздо легче и быстрее внедрять функционал, чем в чужие разработки
@@Николай-у4у7о помню писали сервер на php (многопоточность, http1.1 с tls на низком уровне и даже заготовки для http2 лежали). Закончилось 5 модулями для php, написанными на С, лютым геморроем с работой с памятью (потому что php, как оказалось не освобождает память до окончания работы скрипта) и несильно высокой производительностью (потому что интерпретируемый язык). А так, побаловаться можно.
