@@t0digital а я системный программист на С++ и понятия не имею что у вас происходит в мире веб-разработке. но всё в целом было понятно за исключением специфических названий nginx) мир С++ и дружит с многопоточностью и всегда за скорость работы на железе.
Вообще сам лого Apache, это перо - вызывает у меня чертовскую ностальгию:) 2004й, я в 11м классе, первая книга по веб-технологиям, тонкая такая брошюрка в мягком переплёте, рассказывающая, как поставить Apache на Windows и прикрутить туда PHP 3й или 4й версии. Это всё тогда, конечно, было просто космического, крышесносного уровня магией, захватывающей и интересной. Интернета почти не было - по модемным карточкам, которые стоили 60 руб за, если не ошибаюсь, пол часа доступа к сети, которых никак не хватало, чтобы хоть что-то оттуда выцепить. Да и 60 руб это была сумма тогда. Дааа:) Не могу не улыбнуться, вспоминая то время:) Может видос отдельный про это снять?
Благодарю! Снова всё, наконец-то, уложилось по полочкам в голове. Алексей, у вас великолепно получается подавать материал! Величайше благодарю за всю вашу работу!
Если в вопросе скорости, то как помню, как раз 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 вообще сильно упростилась и до сих пор не является чем то сложным.
Вообще к пониманию статистики веб-серверов стоит учесть, что чаще всего в highload проектах, то чаще всего идет nginx как frontend прокси для статики и балансировщик для нескольких apache, которые идут backend`ом. И в целом nginx все же чаще используется именно как проксирующий сервер, и это относится не только к понятию web-сервер
Делаю вклад в комюнити 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
Однажды меня заинтересовал 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-сервер, а для остального есть остальные инструменты.
Nginx, вообще-то, еще как настраивается на отдельные директории. Достаточно положить name.conf в любую директорию и заинклюдить этот файл в главный конфиг сайта.
Оч крутой видос!) Хорошо, что я знаю что такое процесс, поток, асинхронная обработка запросов и application-server)) Кстати, по поводу конфигов. Получается, что Apache считывает htaccess каждый раз, а Nginx считывает один раз и держит эту информацию в оперативной памяти? Интересно кстати, что получится если сравнить NginX и какой-нибудь сервер на платформе Node.js.
Привет. Можешь что-нибудь рассказать про 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
Лайк я под видео поставил(ровно 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
Расскажи пожалуйста про гуникорн. У тебя было как-то видео про весь стек Django сервера. А вот конкретного примера толкового нету:( И как ты относишься к docker?
Диджитализируй! АйТи студия как на счёт все это развернуть подробно в докере и запилить видос?) реально годного контента нету. Просто дефолтный сайт, но на сильном стеке
@@Yauheni-k7z докер не делает ваш стек сильнее, серьезно. Докер хорош, но он реально крайне редко нужен. Мы сделаем видео про разворачивание всего в докер - в реальности там всё сложнее в продакшн настройке, чем без докера, а бенефитов для 99% проектов - ноль.
Привет, у меня MacBook Pro 15, 2015 года. Машина зверь, мне хватает с головой и для разработки, и для монтажа 4K видео, хотя видеокарта в моей модели встроенная. 16Gb RAM, 256Gb SSD, i7 2.2GHz. С 2016 года в макбуках пошло очень много брака - с их новой клавиатурой, с экранами и тд, их брать уже стремновато, если честно:)
Жалко что у чувака мало просмотров и подписок, а то у всех кликбейтные видосы как стать программистом за 1 час и всё такое... Продолжай в том же духе, у меня есть темка - сделай сравнение например сервера на питоне и джаве - в питоне я знаю нельзя сделать многопоточность а в джаве можно, или все таки в питоне можно сделать?
Спасибо:)! В питоне можно и многопоточность, и асинхронность, сейчас обычно для этого asyncio / aiohttp используют. У нас есть в продакшн много асинхронного питон кода, работает оч бодро:)
@@t0digital сделай видео со сравнением сервера асинхронного и многопоточного на примере питона, где лучше юзать а где нет, где легче программировать а где нет, в общем плюсы и минусы
Пользовался изначально Apache. Единственное, что в нём могло бы понадобиться - это .htaccess. Как рассказали в ролике, других преимуществ у Apache нет. Зачем мне тогда на него ориентироваться при разработке? Ну да, если используешь какой-то готовый движок, то проще поставить Apache, чем вручную писать заменители .htaccess.
Читал в какой-то книге/статье, что огромные сайты используют сочетание nginx + apache. Не вникал, ибо тема была мне не интересна. Там вроде говорилось, что nginx встречает клиентов, распоряжается статическим контентом и говорит что делать апачу, а apache работает под ним и отвечает за динамический контент.
Не все cms используют htaccess, а те, что используют в основном используют их с mod_rewrite - просто переписываются правила на nginx механизм. Некоторые cms сразу дают конфиги для nginx
Я так и не понял, 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, да
Не всегда, но для ряда случаев его действительно легче настроить, под какие-то 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 на полную и требуемую работу сайта без апача? я не понимаю в чем преимущество данной связки
Много вариантов: за счет создания оптимизированных сборок своего софта "под ключ" + поддержка. Донаты. Реклама других поделок за счет известности самого своего бренда. Но главное, что в этой жизни нужно знать, - если ты не платишь в интернете за услугу\сервис(товар), значит этим товаром являешься ты) абсолютно все бесплатные "сервисы добра" зарабатывают на сливе контактов(почты, адреса, телефоны), поведенческих факторов, предпочтений. На основе слитых данных другие "добрые фирмы" откручивают у тебя 15 баннеров с рекламой на странице.
@@uhohwhy про опен сорс все совсем не так. Если разработчиков уличат в сливе данных - на проекте можно будет ставить крест. Основная статья доходов - это донаты сообщества и платная поддержка продуктов.
для Apache как организации http сервер перестал занимать лидирующую роль довольно давно, и очень печально, что они во время не купили 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 коннектор.
NginX отдаёт их коробки статику , именно отдает и все. Обработать без модулей или связки с аапачем какие-то хитрые запросы он не сможет. И он виигривает в статике
Проще поставить говно-пхп движки аля Битрикс, завязанных на использование .htaccess файлов, и для ненагруженнных таких сайтов Aoache вполне хорош. Это его ниша сейчас. Название - есть ли место апачу? Ответ - есть, ровно для таких сайтов. Никакой спекуляции.
@@t0digital но я не согласен, что конфиг Апача проще настроить (что заявляется в видео). Nginx за полчаса настроил или меньше, когда решил на локалхосте попробовать
@@EdwVee много пхп движков завязано на htaccess файлы, и повторить то же поведение на nginx бывает крайне утомительно, не уверен даже, что всегда возможно без влезания в код движка
все легаси технологии, которые использовались раньше будут ещё лет 10 лидировать в статистике, потому что владельцу продукта проще(дешевле) поддерживать старый легаси проект, чем заплатить за новые технологии и новый идентичный продукт. PHP тоже лидирует по числу написанных сайтов, но я не знаю новых крутых проектов, где начинают писать web на PHP, если только динозавры какие-то и говноконторки
Как можно сравнивать nginx и apache в 2019? А особенно как можно сравнивать в разрезе php и python? Для обоих вариантов "апач сосет". Когда-то было время, когда nginx не умел все ф-ии apache'а, но они давно прошли, а выигрыш по памяти и процу - очевидный.
Поставить говно-Битрикс на апач сильно проще, чем на nginx и поэтому для таких задач апач ещё как жив и 2019, и будет в будущем. В этой сфере всем плевать, что он сосёт))
Ничего подобного. Траты ресурсов на настройку nginx и apache для битрикса однозначны. Да, битрикс как таковой, не пользуется успехом среди разрабочтчиков. Но когда речь идет про более менее "не джуна" (т.е. человек занимается уже хотя бы пол года и интересуется своей сферой). А в остальных случаях засчитывать "в плюс" этот ньюанс - неуважение к разработке в принципе. Имхо
Ну и плюс ко всему - апач жив еще не только по причине неадекватных разработчиков "для битрикс", но и для java и вобще он достаточно много для чего является "окном в мир".
Примитивный и стереотипный коммент/отзыв по теме Apache vs Nginx))) @Sergey Larionov У вас на тестах в сравнении этих http серверов прямо такие результаты/показатели как вы написали. Я бы не смог доверить вам настройку или проектированию окружения под настоящий проект, с таким опытом как у вас)
Идеально рассказано, без воды.
Всю нужную информацию вместил в 13 минут, у некоторых это занимает час.
Спасибо, за такое лайк!
Спасибо!
@@t0digital а я системный программист на С++ и понятия не имею что у вас происходит в мире веб-разработке. но всё в целом было понятно за исключением специфических названий nginx) мир С++ и дружит с многопоточностью и всегда за скорость работы на железе.
Очень толковое видео, без воды, по полочкам все красиво разложил!)
Спасибо за простое и информативное объяснение , продолжай в том же духе!
Вообще сам лого Apache, это перо - вызывает у меня чертовскую ностальгию:) 2004й, я в 11м классе, первая книга по веб-технологиям, тонкая такая брошюрка в мягком переплёте, рассказывающая, как поставить Apache на Windows и прикрутить туда PHP 3й или 4й версии. Это всё тогда, конечно, было просто космического, крышесносного уровня магией, захватывающей и интересной. Интернета почти не было - по модемным карточкам, которые стоили 60 руб за, если не ошибаюсь, пол часа доступа к сети, которых никак не хватало, чтобы хоть что-то оттуда выцепить. Да и 60 руб это была сумма тогда. Дааа:)
Не могу не улыбнуться, вспоминая то время:) Может видос отдельный про это снять?
Эх, а я в 11 классе землю жрал.
Jamuel Sexon надеюсь, это было образное выражение)
Денвер в то или чуть более позднее время был спасательным кругом для новичков, у которых не было таких книг или они были сложны все-таки
Это что за город был? У меня за час дешевле было году в 2002-2004.
2004-й, это закат карточного интернета.
Благодарю! Снова всё, наконец-то, уложилось по полочкам в голове. Алексей, у вас великолепно получается подавать материал! Величайше благодарю за всю вашу работу!
Спасибо! Рад, что полезно!
самый недооцененный тек блогер в мире...
Спасибо:)
Спасибо большое за ваш вклад, все оч нравится, не прекращайте это дело, все круто, всех благ
Спасибо, будет продолжать!
Если в вопросе скорости, то как помню, как раз 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 вообще сильно упростилась и до сих пор не является чем то сложным.
Вообще к пониманию статистики веб-серверов стоит учесть, что чаще всего в highload проектах, то чаще всего идет nginx как frontend прокси для статики и балансировщик для нескольких apache, которые идут backend`ом. И в целом nginx все же чаще используется именно как проксирующий сервер, и это относится не только к понятию web-сервер
Было очень информативно, спасибо)
Отлично, все по полочкам. Спасибо 🤝 подписался
чётко, толково, коротко и по существу
подписываюсь на канал, жму колокольчик и лайк :)
спасибо:)!
Просто и понятно. Спасибо!
Отличное видео, поддерживаю такой же формат про субд
Сделаем:)
Делаю вклад в комюнити 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 принесет скорость обработки запросов, и статики в том числе.
С такой конфигурацией можно забыть о стереатипах стекла веб сервера, и идти в будущее, в ногу со временем.
Интересно будет увидеть цитату автора ролика к этому комментарию.
Вам отдельно лайк, потому, что пользователи в большей части не знают, что есть вообще Unix, Linux....
Дело мастера боится.
@@qa337 Вижу дилетантов из далека Хмм)
Во первых в Apache из коробки это тоже делается в пару строк, те включить модуль mpm event для fpm-fcgi и proxy_fcgi, и строчка в конфиге виртуалхоста proxyPass на php-fpm TCP socket(Софт может умереть из коробки или даже не запуститься только у тех кто не умеет его запускать).
Во вторых что за пару строк, если это для локалки и проекта аля hello world, тогда да, а если это окружение для какого нибудь проекта, то это уже не пара строк а полноценная настройка конфига.
А еще об этом мало говорят пользователи nginx но в нем есть такие же модули и расширения, у которых есть тоже доп настройки и даже конфиги, да и вобще оба сервера одинаковые по функционалу просто по разному реализованы и имеют разные модули или расширения вот и все.
Я бы закрепил ваш комментарий, будь на месте автора. Апач также умеет проксировать запросы на сервер приложения. и использовать разные версии интерпретаторов. Сам недавно настраивал несколько доменов на разных версиях рнр
Привет, коллега. Классный контент, подпишусь на канал. Я не согласен с тем что apache настраивается легче чем nginx, как по мне второе намного легче, и документация более понятная. И ещё ты не упомянул о куче модулей для nginx и о возможности расширении функционала с использованием lua
все видео из головы не лез вопрос: так все же вебсарвар или апликейшенсарвар. :D
как всегда, прекрасные объяснения, спасибо
Спасибо за видео без воды!
Спасибо, давно хотел себе именно это разъяснить.
Спасибо за обзор!
Полезно, понятно!
Четка, красива, лайк!)
мне казалось, что keep alive указывает, что tcp соединение должно висеть, а не http
++
Тоже не понял
Однажды меня заинтересовал 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-сервер, а для остального есть остальные инструменты.
Супер!
Хороший канал, судя по всему, подпишусь.
спасибо!
Nginx, вообще-то, еще как настраивается на отдельные директории. Достаточно положить name.conf в любую директорию и заинклюдить этот файл в главный конфиг сайта.
Спасибо.
Хорошо разложил
профессиональный обзор.
Все по делу сказал
Топовый контент
Спасибо!
Оч крутой видос!) Хорошо, что я знаю что такое процесс, поток, асинхронная обработка запросов и application-server))
Кстати, по поводу конфигов. Получается, что Apache считывает htaccess каждый раз, а Nginx считывает один раз и держит эту информацию в оперативной памяти?
Интересно кстати, что получится если сравнить NginX и какой-нибудь сервер на платформе Node.js.
Привет. Можешь что-нибудь рассказать про django + celery + rabbitmq на каких-нибудь реальных задачах? В каких случаях такую связку следует использовать, а в каких можно чем-нибудь заменить?
Привет, могу - нахрен celery:) дичайшая дичь, не работающая до сих пор на python 3.7
@@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
Я так и не понял что не может делать хорошо nginx то что может делать apache? В чем преимущество для nginx в данной связке?
Лайк я под видео поставил(ровно 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
Кто дизлайки поставил? Чудики :)
Годное видео, спасибо
Спасибо!
го теперь mysql vs postgresql
Поддержу! Интересная тема будет!
postgresql
@@dyadya_vasia а почему?
Расскажи пожалуйста про гуникорн. У тебя было как-то видео про весь стек Django сервера. А вот конкретного примера толкового нету:( И как ты относишься к docker?
Так в том видео мы настроили и гуникорн в том числе:) что именно интересно про гуникорн? Сравнение с uwsgi?
Диджитализируй! АйТи студия как на счёт все это развернуть подробно в докере и запилить видос?) реально годного контента нету. Просто дефолтный сайт, но на сильном стеке
@@Yauheni-k7z докер не делает ваш стек сильнее, серьезно. Докер хорош, но он реально крайне редко нужен. Мы сделаем видео про разворачивание всего в докер - в реальности там всё сложнее в продакшн настройке, чем без докера, а бенефитов для 99% проектов - ноль.
Привет
каким макбуком пользуешься? какого года ? есть ли смысл брать такой сейчас для работы
Привет, у меня MacBook Pro 15, 2015 года. Машина зверь, мне хватает с головой и для разработки, и для монтажа 4K видео, хотя видеокарта в моей модели встроенная. 16Gb RAM, 256Gb SSD, i7 2.2GHz. С 2016 года в макбуках пошло очень много брака - с их новой клавиатурой, с экранами и тд, их брать уже стремновато, если честно:)
@@t0digital спасибо. успехов тебе
@@morozota3415 спасибо, и тебе!
Жалко что у чувака мало просмотров и подписок, а то у всех кликбейтные видосы как стать программистом за 1 час и всё такое... Продолжай в том же духе, у меня есть темка - сделай сравнение например сервера на питоне и джаве - в питоне я знаю нельзя сделать многопоточность а в джаве можно, или все таки в питоне можно сделать?
Спасибо:)! В питоне можно и многопоточность, и асинхронность, сейчас обычно для этого asyncio / aiohttp используют. У нас есть в продакшн много асинхронного питон кода, работает оч бодро:)
@@t0digital сделай видео со сравнением сервера асинхронного и многопоточного на примере питона, где лучше юзать а где нет, где легче программировать а где нет, в общем плюсы и минусы
Отличное видео! Расскажи про варианты локального сервера на Mac) Или везде "консолька")))
Для пхп, питона, ноды, для чего сервачелло)?
Диджитализируй! АйТи студия интересует для пыхи, но думаю на питон тоже интересно взглянуть...
@@AndreyChursin для пыхи mamp, для питона консоль
@@t0digital mamp платная версия? в бесплатной автоматом только 1 хост верно?
@@AndreyChursin бесплатная версия норм. Хосты можно насоздавать сколько угодно
Пользовался изначально Apache. Единственное, что в нём могло бы понадобиться - это .htaccess. Как рассказали в ролике, других преимуществ у Apache нет. Зачем мне тогда на него ориентироваться при разработке? Ну да, если используешь какой-то готовый движок, то проще поставить Apache, чем вручную писать заменители .htaccess.
единственную причину использовать апач Вы сами и назвали, да
Толковое видео.
спасибо
Debian + Nginx + PHP-FPM + MariaDB =
классика:)
Почему не девуан?
Будет видео как настраивать Nginx?
Уже есть
@@t0digital Ооо... круто. На канале? Можно ссылку?
Читал в какой-то книге/статье, что огромные сайты используют сочетание nginx + apache. Не вникал, ибо тема была мне не интересна. Там вроде говорилось, что nginx встречает клиентов, распоряжается статическим контентом и говорит что делать апачу, а apache работает под ним и отвечает за динамический контент.
так бывает, кто-то такую связку использует, да
Хотелось бы узнать, о менее популярном, но - тем не менее громком - Roadrunner, что принципиально иного/полезного имеет в себе ?
а как nginx тогда обходиться без .htaccess файлов, если работаешь с cms'ками?
Не все cms используют htaccess, а те, что используют в основном используют их с mod_rewrite - просто переписываются правила на nginx механизм. Некоторые cms сразу дают конфиги для nginx
Я так и не понял, 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, да
@@t0digital Понял.
я так и не понял, воркеры это потоки или дочерние процессы? :(
Очень хорошее видео, хотя музыка джаза очень достает. Не то, что бы я против джаза, но лучше как-то его отдельно слушать.
Было бы круто сделать после видео секунд на 5-7 сек чёрного экрана с ссылками на другие видео.
Я так и не понял почему апач легче настроить? Из за .htaccess?
Не всегда, но для ряда случаев его действительно легче настроить, под какие-то 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 на полную и требуемую работу сайта без апача? я не понимаю в чем преимущество данной связки
что лучше, молоток или отвертка?
Молоток, конечно! Когда в руках молоток, все вокруг автоматически превращается в гвозди:)
@@t0digital
Ну а если открутить что-то надо блэт, например у пк кулер засорился, ломать шоле
@@AlekseiKazantcev да молоток всё что угодно прочистит, размахал им всё - нет кулера нет проблем!
меня вот всегда поражало, как зарабатывают эти опен сорс решения? типа nginx апача ? за счет чего
Много вариантов: за счет создания оптимизированных сборок своего софта "под ключ" + поддержка. Донаты. Реклама других поделок за счет известности самого своего бренда. Но главное, что в этой жизни нужно знать, - если ты не платишь в интернете за услугу\сервис(товар), значит этим товаром являешься ты) абсолютно все бесплатные "сервисы добра" зарабатывают на сливе контактов(почты, адреса, телефоны), поведенческих факторов, предпочтений. На основе слитых данных другие "добрые фирмы" откручивают у тебя 15 баннеров с рекламой на странице.
@@uhohwhy про опен сорс все совсем не так. Если разработчиков уличат в сливе данных - на проекте можно будет ставить крест. Основная статья доходов - это донаты сообщества и платная поддержка продуктов.
@@starikoff72 именно
для Apache как организации http сервер перестал занимать лидирующую роль довольно давно, и очень печально, что они во время не купили nginx или не перестроились когда он появился
Это было бы эпично, если бы nginx попал к ним под крыло :)
название трека в студию, пожалуйста.
Что-то из коллекции самого ютуба, уже не сохранилось название
Кесарю - Кесарево, Богу - Божье. Например на системе Умный дом MajorDomo используется Apache и на Nginx скорее всего он не заведется.
Thanks
Openlitespeed, самый быстрый с PHP, поддержка .htaccess с Apache, поддержка http3, быстрее NGinx
Рил?
@@linuxoidovich да
Всё хорошо, но мне кажется не хватает картинок для пояснения.
Да, с графикой в видео у меня пока не очень:)
Дак какой прок от апачей, если нгджинкс быстрее, ярче, выше и т.д.? Какие преимущества у апачей? Быстрее конфигурация? Ммм, нет.
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 коннектор.
NginX отдаёт их коробки статику , именно отдает и все. Обработать без модулей или связки с аапачем какие-то хитрые запросы он не сможет. И он виигривает в статике
Срочно в номер: "Рамблер пытается оспорить статус Nginx как открытого ПО"
Рамблер может пойти лесом. Всем на него плевать
А как же lighttpd? Отличный веб-сервер, незаслуженно недооцененный... Легкий, быстрый, отлично держит нагрузку.
Помню, ставил его поиграться на iPod touch 1 поколения:) но в продакшн не использовал
@@t0digital на самом деле, достаточно интересный веб сервер. Советую посмотреть на него повнимательнее.
Короче если меня спросят на собеседовании что лучше, я отвечу NGINX потому что он наш.(условно)
И будете правы (условно) :)
щаз слово "наш" ругательным щитается
жаль что лайк можно поставить только раз....
Гы. Если по статистике апача больше. Значит админы забили болт.
Или боятся что то менять!!!
Энджинэкс
Да, моё произношение далеко от идеала
Апач тоже умеет пркировать и точно также можно использвать несколько версий php-fpm
Короче, у Апача по факту нет преимуществ, а название видео - спекуляция.
Проще поставить говно-пхп движки аля Битрикс, завязанных на использование .htaccess файлов, и для ненагруженнных таких сайтов Aoache вполне хорош. Это его ниша сейчас. Название - есть ли место апачу? Ответ - есть, ровно для таких сайтов. Никакой спекуляции.
@@t0digital но я не согласен, что конфиг Апача проще настроить (что заявляется в видео). Nginx за полчаса настроил или меньше, когда решил на локалхосте попробовать
@@EdwVee много пхп движков завязано на htaccess файлы, и повторить то же поведение на nginx бывает крайне утомительно, не уверен даже, что всегда возможно без влезания в код движка
@@t0digital по сути весь сыр бор из-за того что ngnix не особо дружит с php, я правильно пониманию? из-за этого привлекается апач?
Привет из 2023. NGINX таки обогнал Apache
Nginx нет .httaccess и это плюс, что бы программеры на админили ресурсы
Да
@foi в htaccess файлах можно очень много накручивать всего помимо запрета доступа в папку. Но многое из этого можно сделать и в nginx, да
Кто такие катаны?
катаны это японские мечи
Не Эн-Жинс, а Энжин-Икс. Почему что бы стать прогером надо не знать английский. Недавно от одного услышал брик (break). Кровь из ушей потекла.
Мое произношение отстой, да, я знаю
Nginx и Apache одинаковы по сложности настройки.
Nginx и Apache одинаковы по легкости настройки
Как по мне nginx лучше.
Кто такой котан?...
Какие варианты?..
все легаси технологии, которые использовались раньше будут ещё лет 10 лидировать в статистике, потому что владельцу продукта проще(дешевле) поддерживать старый легаси проект, чем заплатить за новые технологии и новый идентичный продукт. PHP тоже лидирует по числу написанных сайтов, но я не знаю новых крутых проектов, где начинают писать web на PHP, если только динозавры какие-то и говноконторки
Apache есть место в 2019м - да ,как минимум эго модуль PHP-FRM (даже не смотев видео чисто по работе опыт) много ли коментаторов работают Dev-Opsа-ми
Как можно сравнивать nginx и apache в 2019? А особенно как можно сравнивать в разрезе php и python?
Для обоих вариантов "апач сосет".
Когда-то было время, когда nginx не умел все ф-ии apache'а, но они давно прошли, а выигрыш по памяти и процу - очевидный.
Поставить говно-Битрикс на апач сильно проще, чем на nginx и поэтому для таких задач апач ещё как жив и 2019, и будет в будущем. В этой сфере всем плевать, что он сосёт))
Ничего подобного. Траты ресурсов на настройку nginx и apache для битрикса однозначны. Да, битрикс как таковой, не пользуется успехом среди разрабочтчиков. Но когда речь идет про более менее "не джуна" (т.е. человек занимается уже хотя бы пол года и интересуется своей сферой). А в остальных случаях засчитывать "в плюс" этот ньюанс - неуважение к разработке в принципе. Имхо
Ну и плюс ко всему - апач жив еще не только по причине неадекватных разработчиков "для битрикс", но и для java и вобще он достаточно много для чего является "окном в мир".
Примитивный и стереотипный коммент/отзыв по теме Apache vs Nginx)))
@Sergey Larionov У вас на тестах в сравнении этих http серверов прямо такие результаты/показатели как вы написали.
Я бы не смог доверить вам настройку или проектированию окружения под настоящий проект, с таким опытом как у вас)
Уважаемый, когда есть Docker, Apache это третье колесо.
Уважаемый, когда есть бензопила, коты это третий Рим.
Мусье путает мягкое с жидким. Что, по твоему, работает внутри docker-контейнера? Тот же Apache, NGINX или более серьёзное.
Зачем ты постоянно гладишь свой телефон?) Зачем тебе вообще телефон в руках?)
Там сценарий
потому что ты не держал в руках пиксель :р
Энджин-Экс ;) Не инджинкс