Уважаемые друзья!

Как правило, на свободном сервере проблем с PHP не возникает, проблемы возникают в последствии, при загруженности сервера, хотя явных причин для этого нет. Исследуя уже на уровне системных вызовов, была найдена основная причина и это вызов команды lstat

Интересно? Более подробная информация размещена на PHP от HT-SYSTEMS.RU

С уверенностью говорим, что наша компания добилась максимальной производительности PHP для массового использования на хостинге. Не верите? Попробуйте!

Браво. Мысль хорошая.

А безопасность не пострадала, ведь не зря же openbasedir так писали?

Учитывая, что это находиться в разделе продажа, цена вопроса за патч?

А директивы realpath_cache_size и realpath_cache_ttl вам знакомы? Не думаю, что разработчики PHP просто так их сделали и на каждый include по 5 lstat'ов делают. В вашем примере в худшем случае будет всего 8 lstat'ов на все include.

Ну так проведите иследование ;-) Кто вам мешает.

А чего его проводить-то? В мануале русским по белому написано

Чудные люди, речь не о командах в php stat и lstat :-)
Речь о сисколах которые и без вас делаются, и никакой вам кеш не моможет, а и наче запускаешь два скрипта и получаешь дуступ куда не надо.

Как раз о них То что они вызываются не пользовательским скриптом непосредственно - значения не имеет.
Правильно, делаются без нас. Но эти сисколы происходят внутри php функций lstat и stat, поэтому мы и дали ссылку на мануал по этим функциям.
ТС говорит об избыточных вызовах lstat/stat в пределах одного скрипта. Вышеупомянутая цитата из мануала четко говорит о кэшировании так же в предалах одного скрипта. Поэтому никакой проблемы с 2 скриптами не будет.

edogs, вы явно не понимаете суть проблемы, lstat функция для пользователя в php использует все ваше вами описаное, я про это не спорю, а вот когда речь идет о привилегиях то ни о каком кешировании и не может идти речи, смотрите исходники php и убедитесь. К тому же системную команду realpath php прокешировать ни как не может, кто же ему это позволит.

Как вы думаете почему например один из пуктов оптимизации Apache звучит примерно так: выключите поддержку .htaccess
знаете почему?
А потомучто на всем следовании пути к файлу к которому идет запрос идет lstat на наличие .htaccess

а интересно во сколько раз увеличится скорость если убрать open_base_dir?

Про это как раз в статье написано, чем больше там путей куда вы разрешаете лазить пользователю, тем больше времени это занимает.

Ваша фраза про "два скрипта" нас убила настолько, что даже спорить не будем здесь ни по какому поводу.
Оставайтесь при своём мнении, мы останемся при своём.

rustelekom,
Встречали еще в интернете мнение что запрет симлинков резко ушустряет работу, интересно много ли где они работают и действительно ли это так?

Рассмешили Более нам комметрировать нечего.

В принцыпе всё правда. Кому не лень:

http://httpd.apache.org/docs/2.2/misc/perf-tuning.html
http://www.opennet.ru/base/dev/perf_tuning.txt.html
http://www.serverwatch.com/tutorials/article.php/3436911
http://wiki.iblink.ru/optimization/server-level

Есть множество ресурсов на эту тему. Хотя для типового хостёра Apache 2.2.X с стандартными настройками и eaccelerator более чем достаточно. Для спец решений есть лучше чем Apache, это и Lighttpd, NGNIX, Litespeed.

Мне интересно как технически HT-SYSTEMS.RU планирует внедрять и поддерживать своё решение на серверах. Это большая головная боль и связанно с дополнительным персоналом.

Хорошая рекламная статья. Как в любой рекламе есть сравнение вида "в 10 раз больше" по отношению к неконкретизированному объекту.
Готов поспорить, что даже если инклюдить совсем пустые файлы, то повышения производительности в 5 раз (уменьшения времени работы скрипта) не будет (говорим о "пустом" сервере.
Интересно, а сколько на нормальном хостинге попаданий к кеш файлововой системы при пхп инклбде.
edogs, попробуйте сравнить время исполнения 100 кратного инклюда пары файлов в одном скипте и 20 кратного вызова срипта один раз инкюдящего эти файлы.
p.s. если пользователю зпретить все функции php, кроме phpinfo скорость выполнения пользовательских скиптов возрастет

Не согласимся. Уверены что при определённой настройке сервера, специфической его нагрузке и специфичных скриптах возможны результаты и в 10 раз лучше.
Самим интересно
На практике нам его присутствия на вирт.хостингах по отношению к пользовательским php скриптам обнаружить не удалось. Но очень возможно это просто потому что не удалось обнаружить, а не потому что его там нет.
Грязный эксперимент будет. На вызов скрипта тоже время будет уходить неопределённое.
Мы по другому сделали, что бы добавить цифр к топику
а) 100 тупых инклудов (к существующим или не существующим файлам) с включённым safe_mode занимают у нас на хостинге максимум 0.05 секунды (кроме редких случаев), в среднем 0.015. Это на выделенном сервере, слабом семферончике, с LA порядка 6 единиц (кому ну очень нужны детали какие-то - скинем дополнительно).
б) Забили в яндекс слово "битрикс" (раз уж он упоминается в статье). Зашли на 2-ой в поиске сайт (первый сам сайт битрикса), посмотрели время выполнения http://pagemaster.ru/?show_page_exec_time=Y
В левом нижнем углу будет очень чётко видно "Время создания страницы".
в) Проделали из любопытства такой же фокус с сайтом битрикса http://www.1c-bitrix.ru/?show_page_exec_time=Y . Время смотреть так же.
Выводы можно сделать, мы сделали, навязывать не будем. Можно просто вычесть из времени общей генерации то время которое можно было бы сэкономить если бы инклуды вообще были бы мгновенными и подсчитать во сколько раз оно станет быстрее.

P.S.: Мы ни разу не отрицаем что уменьшение количества файловых операций (во сколько бы то ни было раз) так или иначе улучшает ситуацию с нагрузкой и быстродействием. Даже реализация кэширования чисто на пхп информации об имеющихся файлах, что бы не делать лишний раз include/file_exists и то улучшает скорость работы. Поэтому в целом к затее ТС мы относимся сугубо положительно, не стоит видеть в наших постах какой-то наезд или еще что-то... как некоторые уже успели.

кеширование оно всегда есть, на уровне OS точно (если не пришло в голову его откючить).
предложеный эксперимент конечно грязный поэтому и было предложено не 100 вызовов скипта.
писать с наладонника скипт - влом, доберусь до стационарного компа - попробую.

Это да, Вы правы. Мы имели ввиду, что достается ли от этого кэширования что-нибудь пользовательским пхп, особенно если этих пользователей там несколько сотен на сервере.

Мы продаем услуги виртуального хостинга. Цена вопроса услуг - на сайте компании. Ноу-Хау специалистов компании пока "no sale"
А раздел называется Продам->Разное->Объявления хостинг-компаний
Продаем, так сказать, хостинг по минимальной цене с лучшими функциональными возможностями.

PS Желающих обсудить, опровергнуть, "поиграться мускулами", подискутировать приглашаем на форум компании Обсуждение производительности PHP




Ждем результатов!!!

Проведенные опыты и эксперименты показали 5-кратное повышение производительности а не 10-кратное. Желающих убедится лично, приходите в гости. Расскажем и покажем.

А вот относительно рекламной статьи. Соглашусь, хорошая. Если Вы, участники форума успели заметить, наша компания в своих действиях и высказываниях показывает, что мы не меряемся у кого больше гигабайт на тарифе за 2 рубля, или предлагаем абузоустойчивые сервера в Мавритании и на Виргинских островах. Мы изо дня в день стараемся обеспечить жизнь проектов клиентов комфортной и легкой, и делаем это. Повышение производительности работы PHP только часть того, что делает компания, что бы клиент оставался доволен предоставляемыми услугами.
Реклама - двигатель прогресса. Прогресс - опыт и ум специалистов компании. Получается реклама не продукта или услуги, а опыта и знаний сотрудников Хостинговых Телесистем. Людей креативных, умных и отвественных к выполнению задач.
Поблагодарю Антону и Стаса за то, что они ежедневно своими идеями и их воплощением в жизнь, предоставляют лучшие условия по размещению сайтов для наших пользователей.

Я бы поспорил насчет 5 кратного роста производительности всего php скрипта

Аргументы такие:
1) можно даже 1 миллион раз к lstat обратиться это не даст сильно нагрузки если будет закешированно, если на нагруженном сервере все не кешируется, проще докупить лишних 8-16 гиг памяти и кешироваться будет всё.
2) Скрипты юзеров и в частности битрикса и подобные CMS системы чаще всего тормозят не из-за обращений к диску, а из-за полуграмотной работы с MySQL, когда для генерации главной страницы в базу делается от 30 SQL запросов - это называется бред!
3) Так же часто скрипты юзеров тормозят из-за просто не грамотного кода.

Поэтому если взять в средний хостинговый сервер, где будут разношерстные скрипты, то ваш патч не даст такого же пятикратного прироста производительности, как добавления N гиг памяти к этому серверу.

P.S. Молодцы за не плохой рекламный трюк для безграмотных клиентов

Предлагаю вам ещё одну рекламную акцию для клиентов:
=====================
"Мы дополнили php и mysql и теперь появилась у него опция называется memcache и теперь php скрипты стали работать в 10 раз быстрее (не в 5 потому как 5 уже было - уже неинтересно)."
=====================
Ну, а то, что мемкеш вещь уже стандартная - можно ж умолчать

Сергей предлагаю спорить не на страницах форума, а в реальном выполнении задачи (той, которую решили специалисты нашей компании) и ее результатах. Если Вы добиваетесь того, что смогли добиться Антон и Стас, вам целая стойка в пользование (без серверов) на год как выигрыш. Надеюсь Вы не сомневаетесь, что наша компания имеет свой ДЦ.
Без прикола и смеха. На полном серьезе.
А если не добиваетесь, денежный эквивалент. Согласны?
Судья - П.П.Паламарчук.

Инструментарий, сервер для экспериментов - предоставим. Время выполнения - аналогична времени, затраченному Антоном. Согласны?

Без обиняков, дополнительных гигабайт и всякого прочего железа. Как программист с программистом. Как хостинг-компания с хостинг-компанией, Сергей. Согласны?

Так не интересно, к выполнении задачи успеют подготовиться зарание ;-)
Да и потом спор вобщем то ни о чем, каждый воспримает сказаное в этой теме со своей колокольни. Просто предлагаю закончить обсуждение, а если кто-то сделает похожее, путь обьявит, я считаю это приведет только к улучшению услуг в общем.


А уж если устраивать соревнования, то лучше взять чего либо, например wordpress текущий + кучку плагинов к нему, взять сайт тормознутый, например вот этот: http://www.dimo.spb.ru/
И сделать, чтобы он летал без потери функционала, и чтобы этот патч был легко накладываемый на wordpress и его плагины.
Задача на определенное время, дальше сверяется производительность.
И нам всем интерес понаблюдать и клиентам полезно.

Пока все это писал, даже мысль возникла, ППП обрати внимание.
Делается раздел в который желающие постят проблемный движок или проблемное решение движка, дальше эту проблему берут в разработку N компаний и начинается битва, назвать проекта какнить "... Игры ..."
Пользы вагон всем, а так только выпендреж друг перед другом и не более.

Если Вы обратите внимание, то Drug ставит под сомнение увеличение производительности php скрипта в 5 раз, так зачем Вы же ему предлагаете на спор её 5-кратно увеличить?
Может лучше опубликуете корректно оформленные проведённые Вами тесты свидетельствующие о 5-кратном увеличении производительности? Все вопросы сразу снимутся.
И пожалуйста без недостоверной рекламы научитесь обходится, а то голословные заявления "мы добились максимальной производительности php" © от солидной компании выглядят дико и смешно.

А смысл устраивать соревнования по этому поводу? Мы выше давали ссылки на битрикс и пример с инклудами. Битрикс страницу генерит в среднем 0.085 секунды (и это еще шикарное время), инклуды занимают где-то 0.015с. Даже если полностью устранить цену инклудов, будет всего лишь 0.075с. А между 0.085 и 0.075 никакой 5-кратной разницы по скорости нету и по нагрузке с чего бы она в 5 раз появилась?
Так что Drug полностью прав - разруха у тормозящих скриптов не в lstat.

Битрикс уже делал.

С ним сайты аж в 20 раз могут работать, куда уж тут ТС с его 5-кратным повышением производительности. А если Битрикс к нему на хостинг поставить, то можно и 5*20=100 кратного увеличения скорости добиться наверное

В целом согласимся. Единственно что выскажем мысль, а зачем за 1 движок? Пусть берутся за разные, пользы будет в Х раз больше. А если нужно оставить соревновательный момент, то ведь конечная нагрузка от движка в примерно равных конфигурациях вполне себе показатель.

Вкаждойбочкезатычка) Убейте в себе привычку отвечать за тех, кому предлагают.
С вас уже давно взятки гладки. И не корректируйте мой текст. Сергея я уже давно называю Сергеем.

Антон, у дураков мысли схожи)) Сам подумал предложить Петру раздел, только не соревновательный, а типа "Очумелые ручки" - публикация идей и их реализации в хостинге. И СМИ тем самым к развитию и проблемам хостинга в России сможем привлечь, новичкам и пользователям помочь. Так как?

Раз тут возникла такая полемика то нужно браться именно за одно и тоже, раз уж сталкнулись с мыслью о недобросовестности заявленого, а так будет все на лицо, и сразу будет видно кто лучше, если уж это надо.
А чтобы не было голословноси, каждый из N участников вносит взнос в выйгрышный фонд, выигравший получает (N-1)*взнос выигрыша, а остальную часть направляем на благотворительность.

А на тему баннера битрикса, это я как раз называю туфтологией, сайт-то в целом может и быстрей работать, но только при возможности быстро работать ;-) Я надеюсь это обьяснять не нужно.

Опять от Вас неприкрытое хамство в ответ на нашу просьбу ответить за свои слова и несложный заданный вопрос.
Полемика возникла не из-за того что "кто-то хуже", а "кто-то лучше", а из-за того, что были сделаны голословные заявления о 5-кратном повышении производительности php и достижении экстримума по этому параметру.
Что бы убрать полемику по этому вопросу, ТС достаточно было выложить результаты и описание тестирования как своего повышения производительности в 5 раз, так и сравнительного тестирования со всеми другими пользователями php что бы показать что у него производительность действительно максимальная. Но он этого не сделал. Значит или их нет (и тогда нет предмета для обсуждения) или ТС нужна эта полемика вокруг себя (а значит со временем он их выложит) или то и другое вместе (что имхо более вероятно, учитывая предыдущие темы ТС). В любом случае соревнования из-за этого устраивать бессмысленно.
Дык у ТС точно то же самое. Если инклуды максимум занимают 20% от времени работы скрипта, то как их не оптимизируй, 5-кратного ускорения для скрипта в целом не добьешься А значит 5-кратное ускорение будет только при возможности оного.
Имхо не стоит усложнять. Голословности не будет уже потому, что результаты будут (если мы правильно поняли идею) открытыми, описанными и доступными для тестирования, а не просто заявлением "мы круче всех".

Дались вам эти инклюды Скажено же, что операции с файлами.
Вобщем тему для ППП я создал.
Дальнейшии диалоги вижу бессмысленными.
2Наиль, заканчивай, поговорить могут и без нас.

Вы сказку предлагаете - потому что спор закончится дракой и поножовщиной так как каждый будет прав потому что говорим о разных вещах.

Вы говорите скрипт php быстрее, а мне думается что вы лишь в 5 раз lstat увеличили, но не тупо написанный скрипт юзером, поэтому если спросить так то вы спор проиграете я напишу скрипт который будет тормозить на всех серверах одинаково как бы вы не с оптимизировали php. Единсвенное что в голову приходит от чего скорость может вырасти это компилять php с параметрами типа -O8 и с последними версиями компиляторов.

Плюс у нас и у вас не найдется сервер для эксперимнетов, так как ни Вы ни Я не дадите реальный сервер с нагруженными клиентами под тест, а на тестовом сервере сгенерить реальную нагрузку никогда не удасться.

Поэтому я готов с вами спорить на вашу стойку и безлимитный трафик в течении года, на то что мой скрипт на PHP будет тормозить на двух одинаковых серверах, только один с оптимизацией вашей другой без оптимизации практически одинаково и погрешность будет не более 5%, а не как вы говорите 500%

Спорим?

У вас даже преимущество есть потому как я на php больше чем <? phpinfo() ?> никогда не программировал так как я perl программист )

Так ведь ответ уже есть в статье
То есть речь именно о скриптах, и даже конкретный софт приводится в пример.

Да речь идет не только об конкретных скриптах, а речь идет о массовом хостинге, я бы не сказал, что битрикс или оскомерце более массовый чем форум phpbb2 с кучей модов причем если их много поставить, то мускль на массовом хостинге начинает стонать и процы сервера, а не файловая система.

Но это я согласен придирка уже от меня к словам "в 5 раз быстрее и массовый хостинг" - просто хорошая реклама - так многие делают, делают что-то узконаправленное, а в рекламе преподносят как чуть ли не таблетка от всех болезней.

Да и опять-такие если бы битрикс во всех своих проявлениях в 5 раз быстрее стал бы работать, они бы вместо того чтобы оптимизировать движок ихнего софта, просто напросто бы сами пропатчили php - я сильно сомневаюсь, что у них не хватает денег нанять программиста написать такой патч, которых с их софтом совершит чудо и которых бы продавался вместе с битриксом для хостеров и их клиентов!