Странное поведение. Если так Код (PHP): php -r "echo basename('/admin/русские файлы.jpg');" русские файлы.jpg А если ту же команду под сервером (ngnix + apache), то выводится только Код (PHP): файлы.jpg Добавлено спустя 6 минут 23 секунды:Нашёл ответ сам. Нужно setlocale с правильной локалью вызвать. Теперь бы как только это дело в elfinder засунуть, при его отладке всплыла проблема Добавлено спустя 23 минуты 33 секунды: Вот окончание поисков. Apache был настроен на LANG=C, файл /etc/apache2/envvars, я в нём раскомментировал строчку Код (PHP): . /etc/default/locale заставив использовать локаль сервера, и всё заработало.
Re: basename врёт Удалить апач надо было в самом начале. Есть хоть одна причина, оправдывающая его использование ?
Re: basename врёт Что любопытно, в интернете про эту ошибку нашёл несколько предложений написать свой basename И только одну ссылку на документацию, где написано, что его работа зависит от установок локали... Собственно, поэтому и не удалил тему, когда всё заработало.
ну так если ты позже пришел то наверное пхп-фпм в связке с нгинксом уже существовали. не вижу смысла в апачи.
я уже делился своим опытом. у меня apache оставался на проде и деве ради двух вещей - 1) для помощи по рерайтеру и 2) для bugzilla. вторую я за новогодние каникулы научил использовать fastcgi и всё, apache на продакшне мне больше не нужен. приведи мне пример с чем апачи справляется а nginx+любой бэкэнд - нет. правильно. тесты правил рерайтера. фигли их тестировать не под апачи?)))) рерайтер в нгинксе вполне доступный. а при том что подавляющее большинство правил звучат как "завернуть все что не файл и не каталог на корневой индекс.пхп" - для этого вообще не нужен рерайтер. гибкий прокси из коробки. изоляция процессов? ну так у тебя фпм будет запущен от нужного юзера-группы. и у каждого свой. даже для одного сайта но разных локаций можно свой пфм запускать. или несколько. причем без лишнего геммора в конфигурации вебсервера. гибкий кэш из коробки. а уж resty так вообще превращают nginx в полноценный сервер приложений. и при этом он не теряет своей главной черты по сравнению с апачи - молниеносной производительности и малой затраты ресурсов. подкиньте в общем идей зачем сейчас нужен апачи? желательно не в контексте mod_php и mod_rewrite.
Не холивара для, а просветительских целей из (ибо выпадал из уютного мира php), ну и почитав про нгинкс: * как у nginx'a с NLM авторизацией? * Nginx на сколько я понимаю мультиплексор как и например Apache Tomcat. * php-fpm такой-же prefork, как и prefork-сервера Apache (с трудом верится в сказки, что один префорк быстрее точно такого-же) единственный профит тут наверное может быть только в том, что чуть меньше покушает памяти fpm (ну пусть на мегабайта 4 от силы) на процесс. Соответственно поразмыслив логически - кажется, что выгоднее nginx как проксик для apache (статика, медленные клиенты ложатся на первого, второй счастлив и бурбулирует реврайтами, mod_php).
О, хорошая ссыль, пасиба. Там еще и продолжение нашлось. http://slonik-v-domene.livejournal.com/142305.html
Вот я тоже почитал это все и напрашивается вопрос - смысл ставить за нгинксом php-fpm, если можно поставить папач, который делает то же самое, но поддерживает .хтакссессы и разные веселые модули?
а смысл за nginx ставить apache+mod_php? только давайте без рюшечек вроде nlm. а то в тред будет внезапно приглашен IIS и вообще вся виндовая инфраструктура. речь о банальных вебсайтах. массхостинге если хотите. итак. ваши аргументы, зачем нужен apache + mod_php и чем это хуже php-fpm
Нужен кому? Массовому потребителю нужен блог или форум, а не поковыряться с оптимальным стеком. Он разворачивает архив, отвечает на несколько вопросов инсталятора и всё завертелось. Поэтому Apache с .htaccess и mod_rewrite будут процветать в обозримом будущем. Тут дело такое: лучше то, что не заставляет потребителя напрягаться. Что до моих личных предпочтений, то я давно пользуюсь nginx. Никаких собственных сравнений не проводил, просто верю окружающим, что nginx лучше держит нагрузку. )))
Но nginx не может в php. Он может проксировать запрос до php-машины. Этой машиной может быть префорковый php-fpm, а может быть префорковый папаче. И то и то, по сути своей, серверы. Только fpm - это чисто пхп-машина, а папаче может еще и в модули и всякие там хтаксессы. Нгинкс работает не быстрее. Он работает оптимальнее с высоким количеством запросов, независимо от скорости клиентов. И он не форкает пхп-машину для отдачи статики, как это делает папаче. Но в связке, по факту-то, этого не происходит. Там как раз оптимальное разделение обязанностей идет. Я к тому, что в таком случае что папаче что фпм работают под нгинксом одинаково, но папаче гибче.
Да ради бога. Когда мне понадобится что-то, что я не смогу реализовать без апачи, тогда вставлю его в уравнение, рожа не треснет. Добавлено спустя 6 минут 39 секунд: mr.akv, я слышал проблемы с уникодом есть и в пайтоне и в руби. В десктопных языках тоже косячат с интернационалом мама не горюй. Я недавно решил объявить свою винду по дефолту англоязычной. Так некоторые локализованные под русский язык проги тупо стали нерабочими. Вместо текста говно, файлы не находят и т.п.
вот тут полностью согласен)) Обслуживал терминалы МТС, на один из них залил англоязычную ХРюшу. Таких косяков я с роду не видывал.
нгинкс в принципе быстрее апача работает, просто потому что работает иначе с коннектами. Добавлено спустя 2 минуты 16 секунд: в винде ставится какую локаль применять когда локаль не понятна и не утф
Он быстрее только статику отдает, и все. Когда речь идет о работе с пхп, он по определению медленнее апача, потому что апач работает напрямую с пхп-машиной, а нгинкс проксит запрос к пхп-машине, порождая оверхед. В то же время апач при любом запросе на статику форкается "как есть", вместе с пхп-машиной, что намного затратнее по времени и ресурсам для отдачи ссаной CSS-ки весом 1 килобайтик. Связка нгинкс+пхпфпм работает так, что всю статику нгинкс отдает сам, а пхп-запросы отправляет пхпфпму, который их жует, а потом сплевывает в буфер нгинкса, который отдает это как статику. При этом обработка пхп в таком случае происходит медленнее. Работа нгинкса с апачем при этом происходит точно так же как с пхпфпм-мом. 1-в-1. Абсолютно один в один. ПХПФПМ - это сервер, который умеет только в пхп. Апач - сервер, который умеет не только в пхп, но и, например, в сжатие данных перед тем, как отдать их нгинксу, если в пыхе нет гзипа, к примеру. Но, если запросов очень очень много, включая запросы от медленных клиентов, при использовании голого апача мы получим кучу форков, большая часть из которых будет избыточной. Грузим 1 пхпскрипт, 4 ксски, и 5яваскриптиков? Ловим 10 форков папача. Полноценных в каждом по пхп-машине. Тратим нерационально ресурсы. В связке с нгинксом мы получаем 1 форк папача и 9 потоков нгинкса, которые ничего не весят. При этом, даже если клиент сидит на диалапе и тянет страничку 5 минут, то все эти 5 минут страничку клиенту будет отдавать поток нгинкса, а не процесс папача. Папач отработает скрипт за свои 0.001 секунду и сдохнет, отдав содержимое нгинксу. Вывод. 1) Нгинкс не быстрее апача, когда речь идет о работе с пхп. Он вообще не умеет в пхп, он проксирует его пхп-машине. Это по определению медленнее, нежели чистая работа пхпмашины. 2) Нгинкс+пхпмашина обработают запрос быстрее, нежели апач ровно настолько, насколько пропорционально будет статики от динамически генерируемого контента, потому что апач будет отдавать статику хуже. 3) Нгинкс+пхпмашина(которой может быть и апач, опять же), в целом работают не столько быстрее, сколько оптимальнее. Каждый занимается своим делом. Связка нгинкс+пхпмашина смогут выдержать гораздо бОльшую нагрузку, нежели голый апач. Но не потому что нгинкс волшебный, супер-быстрый, мега-оптимизированный и заряженный Чумаком, а потому, что стек обработки запроса, формируемый в таком случае более логичен. Чувствуешь разницу между "нгинкс быстрее, потому что технологичный" и "разделение обязанностей между нгинксом и пхпмашиной оптимальнее и логичнее"? Но сломанный телефон превратил это в "Нгинкс в тыщщу раз быстрее!11111!!!!11!". На вопрос "почему?" тебе отвечают "так это ж все знают!11". Вместо нгинкса можно поставить любой проксирующий легкий серверочек, могущий в отдачу статики, коих много, и результат будет плюс-минус тот же. просто потому что реализует стек, оптимизирующий обработку запроса. Работа с коннектами никак не влияет на скорость. Она влияет только на то, что он может держать действительно много соединений не роняя сервер в своп.
Мне кажется ты не очень понимаешь как работает апач я конечно ошибаться могу, но вроде как. Давай отдельную тему мутить.
Дык эцсамое, отрезай эту с момента, когда началось обсуждение. Добавлено спустя 2 минуты: Префорковый сервер, создающий кучу инстанстов-процессов, которые ждут запросы. Пришел запрос, они отработали его, ждут дальше. Вроде всегда так работал. ПХПФПМ работает так же на этом уровне абстракции.