Comments 85
Может, ошибочка? в последней таблице, «запросов/сек с кешом опкода» — у вас 200 против 400 для монолита, то есть проигрыш в 2 раза, хотя коэффициент акселерации больше.
Ну это проблема например мертвого кода в PHP, в Perl немного другая ситуация на примере use подключения файл инклудиться на стадии запуска и «сборки» в память всей лошадки, require на стадии выполнения… Ну FastCGI в Perl «настоящий», что мы и должны видимо скоро увидеть в PHP-FPM когда 5.3 станет повсеместным…
Не буду утверждать, но вроде PHP-FPM тоже не дает «честного» FastCGI. Так что сильного прироста ждать не стоит.
Ммм, а дайте, пожалуйста, ссылки, где почитать про почему в 5.3 будет нормальный fastcgi.
groups.google.com/group/highload-php-ru/browse_thread/thread/7584ec627432c3ed
«Цель всего этого — довести FPM до полностью рабочего состояния и где-то в районе
5.3.3/5.3.4 включить в официальную поставку. „
ну и дальше там, что возможно он войдет в официальную поставку PHP
«Цель всего этого — довести FPM до полностью рабочего состояния и где-то в районе
5.3.3/5.3.4 включить в официальную поставку. „
ну и дальше там, что возможно он войдет в официальную поставку PHP
Простите, а не является ли это охотой не ведем? На синтетических тестах, ваши выводы конечно верны. Но вот положа руку на сердце, как много пхп проектов вы видели, где тормозил бы именно пхп код? Мне кажется в 80% случаев мы упираемя в БД (а скорее даже в IO для БД). Так ли важно, будет занимать пхп, 7% или 9% времени выполнения запроса, если львиную часть все равно будет отжирать БД?
А в остальных 20%, где приложение и правда имеет сложную ПХП логику и тормозит само по себе… Ну может быть просто был не верно выбран инструмент и в этом месте надо было использовать чтото другое, вроде расширение на Си, джавы или (подставить свое любимое)?
Пишу без сарказма, мне правда интересно ваше мнение.
Поймите правильно, я очень благодарен вам за проделанные исследования и если бы у меня был под рукой _готовый_ инструмент который собрал бы мне монолит, для моего приложения, с радостью им бы воспользовался. Но бежать переписывать чтото, что бы избавиться от инклюдов, мне кажется смысла нет.
А в остальных 20%, где приложение и правда имеет сложную ПХП логику и тормозит само по себе… Ну может быть просто был не верно выбран инструмент и в этом месте надо было использовать чтото другое, вроде расширение на Си, джавы или (подставить свое любимое)?
Пишу без сарказма, мне правда интересно ваше мнение.
Поймите правильно, я очень благодарен вам за проделанные исследования и если бы у меня был под рукой _готовый_ инструмент который собрал бы мне монолит, для моего приложения, с радостью им бы воспользовался. Но бежать переписывать чтото, что бы избавиться от инклюдов, мне кажется смысла нет.
БД вот не должно как раз быть тормозом, для этого есть индексы и кэширование как у базы, так и средствами ПХП.
А код тормозящий, ну например рекурсия, на ПХП в этом плане построение например вложенного списка из сотен 3х элементов уже заметно… Но опять же решаемо кэшированием.
А код тормозящий, ну например рекурсия, на ПХП в этом плане построение например вложенного списка из сотен 3х элементов уже заметно… Но опять же решаемо кэшированием.
>БД вот не должно как раз быть тормозом, для этого есть индексы и кэширование как у базы, так и средствами ПХП.
Это смотря какими объёмами оперировать.
Если приходится работать с несколькими сотнями таблиц, некоторые из которых имеют более 1кк записей, то тут уж как ни крути, а в БД периодически утыкаться придётся…
Это смотря какими объёмами оперировать.
Если приходится работать с несколькими сотнями таблиц, некоторые из которых имеют более 1кк записей, то тут уж как ни крути, а в БД периодически утыкаться придётся…
ну для таких задач можно ставить помощнее серваки и оптимизировать код.
Несколько сотен таблиц и всё дергать каждый раз? Мда, тут уже не кэш или инклуды, тут надо давно уже подумать о пересмотре структуры базы, как будем мемкэш подключать и не стоит ли уже всё денормализовать :)
Для древовидных структур есть Nested Sets (ад, лучше и не пытайтесь понять) и хранение пути (самое то для комментариев например), второе работает по индексу и без всяких кеширований.
Ну а если идет речь например о древесном списке категорий (типа каталог товаров там, меню на сайте) — просто стройте один раз и можно на месяц вперед класть в кеш :) Я так делаю.
Ну а если идет речь например о древесном списке категорий (типа каталог товаров там, меню на сайте) — просто стройте один раз и можно на месяц вперед класть в кеш :) Я так делаю.
nested sets мне не надо понимать, я его уже давно понял и использую, пример рекурсии и кода который будет тормозить просто привёл на примере списка, не только же факториал считают рекурсией… про кэш списка я тоже уже сказал…
просто людям не нравится, когда им говорят, что БД не должно быть тормозом их приложения, он не должен решать проблемы БД при разработке, или брать другую БД или перепроектировать! Основная суть, непонятная многим тут троллям :)
просто людям не нравится, когда им говорят, что БД не должно быть тормозом их приложения, он не должен решать проблемы БД при разработке, или брать другую БД или перепроектировать! Основная суть, непонятная многим тут троллям :)
Как ты предлагаешь рисовать дерево комментариев? Входные данные: пользователь может удалить комментарий, автор статьи может удалить комментарий, модераторы должны видеть все комментарии, включая удаленные, анонимные авторы могут оставлять комментарии, но они будут видны только им, пока они не жмакнут на подтверждение в письме. Комментариев в статье может быть до 2000.
Как это делает хабр, комментарии никогда не удаляются, чтобы не нарушать целостность. Для всего остального есть статус комментария, проапрувлен и т.п
Я ж написал, materialized path или как-то так. У него конечно есть ограничения на вложенность и число комментариев, но мне например цифры 10000 комментариев в олдной группе и 20 уровней вложенности кажутся достаточной цифрой.
Выборка уже отсортированного дерева делается одним запросом по индексу, всьавка комментария — требует 1 select (тоже индексируемый вроде), и 1 insert.
Удалять комментарии можно добавлением флага «deleted».
Выборка уже отсортированного дерева делается одним запросом по индексу, всьавка комментария — требует 1 select (тоже индексируемый вроде), и 1 insert.
Удалять комментарии можно добавлением флага «deleted».
Так. Флаг deleted у нас уже есть. Обычное дерево в mp как раз требует сортировки на клиенте, но это мелочи.
Осталось только представить себя базой с табличкой комментариев хотя бы на миллион записей, которую попросили достать последнюю страницу комментариев определенного пользователя. При условии, что в базу еще и пишут.
Это из явного. А про вещи, типа комментарии к постам избранных авторов, за исключением удаленных комментариев, и комментариев заблокированных пользователей вообще можно не говорить.
Осталось только представить себя базой с табличкой комментариев хотя бы на миллион записей, которую попросили достать последнюю страницу комментариев определенного пользователя. При условии, что в базу еще и пишут.
Это из явного. А про вещи, типа комментарии к постам избранных авторов, за исключением удаленных комментариев, и комментариев заблокированных пользователей вообще можно не говорить.
> Обычное дерево в mp как раз требует сортировки на клиенте
Да не требует! Я же сам делал:
> SELECT id,name,ava,path,comment_content,date FROM ?t WHERE post_id =? ORDER BY path ASC
Вот и все.
> Осталось только представить себя базой с табличкой комментариев хотя бы на миллион записей, которую попросили достать последнюю страницу комментариев определенного пользователя
Ну нет, скажите, вы эту выборку без индексов делаете :) А если проблемы с LIMIT 10,990 — ну не знаю, тут видимо надо какие-то альтернативные подходы применять, например выбирать комменты с определенной даты или с определенного id. Или, если речь идет о постраничном просмотре — мне недавно пришла в голову мысль, что можно выбирать сразу 10 страниц коментариев и показывать их частями из кеша :)
В любом случае, на упомянутой вами базе из миллионов комментов делать запросы без индексов глупо, не так ли? Старница, открывающаяся по 10 секунд не только разочаровывает пользователя. но и опасна для работы всего сайта.
Да не требует! Я же сам делал:
> SELECT id,name,ava,path,comment_content,date FROM ?t WHERE post_id =? ORDER BY path ASC
Вот и все.
> Осталось только представить себя базой с табличкой комментариев хотя бы на миллион записей, которую попросили достать последнюю страницу комментариев определенного пользователя
Ну нет, скажите, вы эту выборку без индексов делаете :) А если проблемы с LIMIT 10,990 — ну не знаю, тут видимо надо какие-то альтернативные подходы применять, например выбирать комменты с определенной даты или с определенного id. Или, если речь идет о постраничном просмотре — мне недавно пришла в голову мысль, что можно выбирать сразу 10 страниц коментариев и показывать их частями из кеша :)
В любом случае, на упомянутой вами базе из миллионов комментов делать запросы без индексов глупо, не так ли? Старница, открывающаяся по 10 секунд не только разочаровывает пользователя. но и опасна для работы всего сайта.
Да при чем здесь индексы. Понятно, что они используются. Речь не об этом.
Нет в данном случае альтернативных подходов. Датой и id нельзя пользоваться, если мы хотим гарантированно получить всю страницу комментариев. Можно вычислять последний возможный id по дате регистрации, но это только для последней страницы. Кэшировать бессмысленно, т.к. хитов в такой кэш будет пару процентов, а места он будет занимать как еще одна таблица комментариев.
Нет в данном случае альтернативных подходов. Датой и id нельзя пользоваться, если мы хотим гарантированно получить всю страницу комментариев. Можно вычислять последний возможный id по дате регистрации, но это только для последней страницы. Кэшировать бессмысленно, т.к. хитов в такой кэш будет пару процентов, а места он будет занимать как еще одна таблица комментариев.
Целью топика не ставилась популяризация «монолита» и это ни в коем случае не призыв «а давайте всё писать на монолите». Статья скорее больше имеет теоретическую, чем практическую направленность.
Знаете, как в университет нас заставляли писать собственные push back'и для массивов (на сях), чтобы мы знали, что взять и добавить элемент в конец массива это не так просто, а на самом деле происходит инициализация нового массива новой размерности, копирования туда старого массива и потом добавления туда нового элемента. Так и здесь, целью было рассказать на что и насколько большое время может уходить при парсинге страниц, и как известные методы оптимизации на это влияют. Чтобы знать во что можно упереться, если этим совсем пренебрегать.
Что же касается практики, да согласен с вами, что в большинстве случаев все упирается в бд. Но есть случаи, когда упереться можно и в процессор, и именно потому что приходиться очень много «лопатить» кода.
Конечно согласен, что бежать переписывать для избавления от инклудов не стоит, но иногда стоит провести некоторые оптимизации в этом направлении (например тоже объединение мелких файлов в 1). Так что статья больше по принципу «предупрежден — значит вооружен» :)
Знаете, как в университет нас заставляли писать собственные push back'и для массивов (на сях), чтобы мы знали, что взять и добавить элемент в конец массива это не так просто, а на самом деле происходит инициализация нового массива новой размерности, копирования туда старого массива и потом добавления туда нового элемента. Так и здесь, целью было рассказать на что и насколько большое время может уходить при парсинге страниц, и как известные методы оптимизации на это влияют. Чтобы знать во что можно упереться, если этим совсем пренебрегать.
Что же касается практики, да согласен с вами, что в большинстве случаев все упирается в бд. Но есть случаи, когда упереться можно и в процессор, и именно потому что приходиться очень много «лопатить» кода.
Конечно согласен, что бежать переписывать для избавления от инклудов не стоит, но иногда стоит провести некоторые оптимизации в этом направлении (например тоже объединение мелких файлов в 1). Так что статья больше по принципу «предупрежден — значит вооружен» :)
Совершенно согласен — теоретически статья очень полезна! Жаль только что практических выводов из нее сделать сложно. Ну тут каждый должен, сам посидеть с профайлером и решить для себя, какой процент времени работы отъедает инклуд и думать надо ли оптимизировать или нет.
Вы свою часть работы сделали — спасибо большое! :)
Было бы чудно, если бы вы еще написали как именно в реальных условиях вы бы создавали монолитный файл. Писать парсер с анализатором зависимостей, ой как не хочется если ктото уже сделал часть работы и это можно заюзать. К тому же парсер не спасет от аутолоуда и инклюдов с использованием переменных.
Если напишите статью с реальными аспектами создания монолитного кода, лично я буду вам только благодарен! :)
Вы свою часть работы сделали — спасибо большое! :)
Было бы чудно, если бы вы еще написали как именно в реальных условиях вы бы создавали монолитный файл. Писать парсер с анализатором зависимостей, ой как не хочется если ктото уже сделал часть работы и это можно заюзать. К тому же парсер не спасет от аутолоуда и инклюдов с использованием переменных.
Если напишите статью с реальными аспектами создания монолитного кода, лично я буду вам только благодарен! :)
Основные аспекты того, какой получилась система, дающая на выходе монолит можно почитать в первой части тут (это как раз 'хранение кода в бд или собираем код по кирпичикам"). Но для продакшена это все еще очень сыро. В частности жуткие минусы невозможности использования SVN (точнее не невозможности, а просто пока под такую систему ее нет), проблем отладки и проблем переноса стороннего кода на подобную систему.
Тем не менее на ней живут несколько проектов, в частности упомянутый выше ДелаемВместе. Так что скажем обкатка на практике тоже есть.
Тут более сложный вопрос в том, а нужны ли вообще такие системы? С учетом роста процессорной производительности серверов, экономия этого процессорного времени на парсинге страниц — затея довольно сомнительная. Игра просто может не стоить свеч :)
Тем не менее на ней живут несколько проектов, в частности упомянутый выше ДелаемВместе. Так что скажем обкатка на практике тоже есть.
Тут более сложный вопрос в том, а нужны ли вообще такие системы? С учетом роста процессорной производительности серверов, экономия этого процессорного времени на парсинге страниц — затея довольно сомнительная. Игра просто может не стоить свеч :)
Слушайте. хватит уже распространять свои мифы о тормрозах БД. БД тормозит только на копеечных шаред хостингах, где вечно не хватает памяти и на 100 сайтов одна БД.
На моем ноутбуке например, запрос с индесом отрабатывает очень быстро:
> select benchmark(10000, (select domain_name from dom_domains where id = floor(rand()*400) limit 1 ));
> 2.55 sec
То есть, порядка 255 мкс на выборку записи по id.
Популярный миф «зачем оптимизировать код, основные тормоза в БД» распространяют какие-то странные люди (а также фанаты больших тяжелых фреймворков, питона и Ruby on Rails), которые видимо только с перегруженными шаредами и имели дело.
У меня например, половину времени выполнения скрипта (15 мс из 30) занимал инклюд нескольких (7-9) небольших файлов по 10 Кб каждый. Вторая по затратам операция — множественные вызовы htmlspecialchars() и интерпретация php-шаблона (около 4 мс).
Так что вопрос ухода на другие языки (нет, я не про Яву/дотнет/Руби и прочие скриптовые, паямтеемкие или проприетарные технологии) весьма актуален, имхо, так как я не вижу путей оптимизации скрипта, в котром 1) не подключается лишнего кода 2) количество «лишних» действий минимально.
Точнее, путей только 3: 1) отказаться от всех этих MVC и писать old-school plain php-файлы где HTML перемешивается с кодом 2) уходить на другие технологии 3) забыть про оптимизацию.
В связи с тем. что разработчики php планируют добавлять всякие новомождные фишки вроде замыканий и сборщика мусора (!!!), прироста производительности интерпретатора не ожидается.
На моем ноутбуке например, запрос с индесом отрабатывает очень быстро:
> select benchmark(10000, (select domain_name from dom_domains where id = floor(rand()*400) limit 1 ));
> 2.55 sec
То есть, порядка 255 мкс на выборку записи по id.
Популярный миф «зачем оптимизировать код, основные тормоза в БД» распространяют какие-то странные люди (а также фанаты больших тяжелых фреймворков, питона и Ruby on Rails), которые видимо только с перегруженными шаредами и имели дело.
У меня например, половину времени выполнения скрипта (15 мс из 30) занимал инклюд нескольких (7-9) небольших файлов по 10 Кб каждый. Вторая по затратам операция — множественные вызовы htmlspecialchars() и интерпретация php-шаблона (около 4 мс).
Так что вопрос ухода на другие языки (нет, я не про Яву/дотнет/Руби и прочие скриптовые, паямтеемкие или проприетарные технологии) весьма актуален, имхо, так как я не вижу путей оптимизации скрипта, в котром 1) не подключается лишнего кода 2) количество «лишних» действий минимально.
Точнее, путей только 3: 1) отказаться от всех этих MVC и писать old-school plain php-файлы где HTML перемешивается с кодом 2) уходить на другие технологии 3) забыть про оптимизацию.
В связи с тем. что разработчики php планируют добавлять всякие новомождные фишки вроде замыканий и сборщика мусора (!!!), прироста производительности интерпретатора не ожидается.
Сделайте этот же тест на запросе с несколькими join'ами и из базы в 1кк элементов в каждой таблице.
А потом такой же тест на таблице без индексов, т.к. отнюдь не на все можно и нужно индексы вешать.
А потом такой же тест на таблице без индексов, т.к. отнюдь не на все можно и нужно индексы вешать.
Тестировать скорость РСУБД, выборкой по первичному ключу, классная идея. Ну примерно, как выбирать торт по третьей букве названия.
Выборка статьи по УРЛ. Выборка фотографий по ид альбома. Выборка данных для профиля юзера. Выборка списка писем для юзера. Выборка последних новостей. Выборка комментариев к статье.
Все эти запросы делаются по индексу. Из чего я сделал вывод, что выборка по индексу — самый распространенный случай :) Потому его и тестирую.
Если у вас огромное корпоративное приложение, которые делали 2 поколения индусов, с сотней таблиц и километрами кода — что ж, сочуствую, ешьте свои кактусы дальше :( Не хотел бы я с таким работать.
Все эти запросы делаются по индексу. Из чего я сделал вывод, что выборка по индексу — самый распространенный случай :) Потому его и тестирую.
Если у вас огромное корпоративное приложение, которые делали 2 поколения индусов, с сотней таблиц и километрами кода — что ж, сочуствую, ешьте свои кактусы дальше :( Не хотел бы я с таким работать.
Сорри за офтоп, но про торт очень понравилось =)))))
Ну как уже сказали, делать выборку по первичному ключу это не совсем разумно. Если ваше приложение нуждается только в подобных запросах, то RDBMS это явно оверкил. keyvalue база будет более уместной.
Думаю мы говорим просто о разных типах приложениях. Я бы сказал, что проблемы с базой ощущаются, на базах которые на ноуте уже просто не протестируешь. :) К тому же, ваш тест мало что говорит о конкурентных запросах, и уже совсем ни чего не показывает для OLTP приложений…
Так что, там где есть от миллиона хитов в сутки и сколько нибудь развитая бизнес логика, БД может вполне стать ботелнеком.
Думаю мы говорим просто о разных типах приложениях. Я бы сказал, что проблемы с базой ощущаются, на базах которые на ноуте уже просто не протестируешь. :) К тому же, ваш тест мало что говорит о конкурентных запросах, и уже совсем ни чего не показывает для OLTP приложений…
Так что, там где есть от миллиона хитов в сутки и сколько нибудь развитая бизнес логика, БД может вполне стать ботелнеком.
> Я бы сказал, что проблемы с базой ощущаются, на базах которые на ноуте уже просто не протестируешь. :)
Ну это да, фильтр по сотне миллионов колонок, или запросы из Битрикса на 2 страницы, да без кеширования — невеселое дело, но извините, вас никто не заставлял такие запросы городить :) Ну, если вам такой проект достался в наследство — соувствую, ничего вы не сделаете, тут время работы скрипта может быть невелико по сравнению с запросом.
Кстати, млн хитов/сутки — всего лишь 15 запросов в секунду, не очень-то много, а вот 5-10 млн…
А что касается «БД может стать боттлнеком» — может стоит задуматься в таких ситуациях об использовании нескольких серверов, распараллеливании, смене типа БД, ввееждении хитрых кешей, промежуточных слоев, ну в общем, вариантов много)
Ну это да, фильтр по сотне миллионов колонок, или запросы из Битрикса на 2 страницы, да без кеширования — невеселое дело, но извините, вас никто не заставлял такие запросы городить :) Ну, если вам такой проект достался в наследство — соувствую, ничего вы не сделаете, тут время работы скрипта может быть невелико по сравнению с запросом.
Кстати, млн хитов/сутки — всего лишь 15 запросов в секунду, не очень-то много, а вот 5-10 млн…
А что касается «БД может стать боттлнеком» — может стоит задуматься в таких ситуациях об использовании нескольких серверов, распараллеливании, смене типа БД, ввееждении хитрых кешей, промежуточных слоев, ну в общем, вариантов много)
Я с Вами согласен. На моей практике тоже обычно выходило, что узким местом в связке PHP + MySQL является не инклюды, не шаблонизаторы, а именно иррациональное использование MySQL. Поэтому в первую очередь стоит оптимизировать именно свои запросы и индексы. Всегда помнить про id IN (1,2,3) и insert… on duplicate key update…, остерегаться ORDER и GROUP… Но это уже другая, хоть и не менее интересная тема =)) И как сказал кто-то из великих, ресурсы MySQL гораздо дороже, чем PHP.
А автору, особенно, учитывая его возраст, за статью спасибо =))
А автору, особенно, учитывая его возраст, за статью спасибо =))
Рассмотрим, например, ситуацию с использованием Zend Framework. Подключение монолитного файла (допутим мы имеем сложное приложение где необходим разный набор библиотек) съедает примерно 30мб памяти, хотя при использовании autoload — намного меньше (зависит от количества подключаемых классов). Поэтому, при объединении — получается заметный проигрыш в свободной памяти.
С зендом ситуация хорошо рассмотрена у Котерова тут. Так что пожертовать лишними 10-15мб памяти ради до 22х(!) кратного прироста производительности — согласитесь не самый плохой вариант :)
Было бы интересно взять какой-то проект(ы) и сделать из него (их) монолит и подвергнуть вашему тестированию. Что-то мне подсказывает, что вы бы получили другие результаты =)
еще по поводу инклудов…допустим мы имеем такой код:
file#1.php:
include_once(«file#2.php»);
…
function#2()
function#3()
…
file#2.php:
function#1 ()
…
function#2 ()
…
function#3()
…
как видим, мы используем только function#2,#3 а вот function#1 нет. Так вот было бы круто, если бы файл file#2.php был таким:
function#2 ()
…
function#3()
…
p.s.: инересно, чтобы каким-то образом исключался мертвый код (function#1), а монолит или нет — это мелочи.
p.s.s.: сейчас весь код конвертится в байт-код + кеширование, поэтому ещё раз повторюсь что все это — мелочи.
p.s.s.s.: кстати, вместо function может быть и class ;-)
еще по поводу инклудов…допустим мы имеем такой код:
file#1.php:
include_once(«file#2.php»);
…
function#2()
function#3()
…
file#2.php:
function#1 ()
…
function#2 ()
…
function#3()
…
как видим, мы используем только function#2,#3 а вот function#1 нет. Так вот было бы круто, если бы файл file#2.php был таким:
function#2 ()
…
function#3()
…
p.s.: инересно, чтобы каким-то образом исключался мертвый код (function#1), а монолит или нет — это мелочи.
p.s.s.: сейчас весь код конвертится в байт-код + кеширование, поэтому ещё раз повторюсь что все это — мелочи.
p.s.s.s.: кстати, вместо function может быть и class ;-)
К сожалению я переделывал на монолит всего 1 проект (земля ему пухом :) ). В нем получился выигрыш что то порядка 400%-600% на времени генерации страницы (с 0.25-0.3 до 0.04-0.05). Было бы классно переделать на монолит какую-нибудь общеизвестную CMS/движок и посмотреть что получится. Может как нибудь доберусь до этого…
Насчет инклудов:
Как я понял в первом файле вы имеете в виду вызовы функций, а во втором их описания (просто обозначили вы их одинаково и немного сбивает с логики)? Если так, то в моем случае вообще сейчас нет понятия группировки функций в файлы: каждая функция/class/страница/модуль это отдельная сущность. Между этими сущностями можно задавать репликации, по итогам которых собирается страница в итоге. В вашем примере это выглядело бы как задание двух репликаций (function#2 и function#3 ) для файла file#1. А сами определения функций хранились бы каждая отдельно. В итоге мертвого кода на выходе бы не было (function#1 не подключалась бы)
Насчет функций/классов — разницы особо нет, просто намного удобнее писать для определености что то одно, а не так: «функция/класс/метод класса ..».
Насчет инклудов:
Как я понял в первом файле вы имеете в виду вызовы функций, а во втором их описания (просто обозначили вы их одинаково и немного сбивает с логики)? Если так, то в моем случае вообще сейчас нет понятия группировки функций в файлы: каждая функция/class/страница/модуль это отдельная сущность. Между этими сущностями можно задавать репликации, по итогам которых собирается страница в итоге. В вашем примере это выглядело бы как задание двух репликаций (function#2 и function#3 ) для файла file#1. А сами определения функций хранились бы каждая отдельно. В итоге мертвого кода на выходе бы не было (function#1 не подключалась бы)
Насчет функций/классов — разницы особо нет, просто намного удобнее писать для определености что то одно, а не так: «функция/класс/метод класса ..».
Делается элементарно, превращайте функции в статические методы классов и Autoloading вам в руки.
Я для себя решил подобную проблему так — поставил php-fastcgi по числу ядер в сервере, дал shared mem*2 по весу всех скриптов проекта на диске.
После этого все стало летать
После этого все стало летать
Из моего опыта… както генерил монолитный код закинув в один файл все, что касается Zend_Sezrch_Lucene из Zend Framework. Данный монолит действительно в разы быстрее инклудился(правда потом все равно все на Сфинкс поменял :) ).
Мое мнение — все эти монолиты-немонолиты хорошо, если просто посидеть и поговорить о производительности. Когда же идет речь о реальной работе главное — чтобы было удобно писать и отлаживать код. Это надо ставить во главу угла. Остальное… ну если получается при деплое на сервер делать какието оптимизации — можно. Но не стал бы я на этом сосредотачиваться. На моих проектах никогда скорость инклудинга php не была сильно критичной.
Мое мнение — все эти монолиты-немонолиты хорошо, если просто посидеть и поговорить о производительности. Когда же идет речь о реальной работе главное — чтобы было удобно писать и отлаживать код. Это надо ставить во главу угла. Остальное… ну если получается при деплое на сервер делать какието оптимизации — можно. Но не стал бы я на этом сосредотачиваться. На моих проектах никогда скорость инклудинга php не была сильно критичной.
опять охота на ведьм, котеров пропустил, а все остальные неглядя подхватили. проблема медлительности множественных инклудов при включённом кэшере опкода — время, которое тратится на перепроверку не изменился ли файл. на боевом серваке эту проверку ясное дело нужно убирать.
Вячеслав, здесь с вами не соглашусь. Во-первых о том, что насчет этого писал Котеров, я узнал много позже после того, как начал сам интересоваться этой проблемой (а интересоваться я ей начал более 3х лет назад). А во-вторых я бы не был так уверен, что кешер опкода очень хорошо справится с множеством инклудов мелких файлов и что время уходит только на проверку их изменений. В частности eAccellerator даже с eaccelerator.check_mtime = 0 при имитации «autoload» втрое проигрывал монолиту.
Проверка, изменился ли файл, тут ни причем. В этом легко убедиться, отключив данную проверку (это отключение дает не просто маленький, а даже неизмеримо маленький прирост). Дело именно в количестве мелких файлов.
А что делать-то? Какое рекомендации?
Недавно сам экспериментировал. Цель была проверить, как правильнее — хранить каждый класс в отдельном файле (как советуют всякие стандарты кода) или по-умному — собрать все важные классы в один файл, чтобы ядро системы подключалось сразу.
Использовалась винда XP :), apache, php 5.2.8, опкешер APC и Xdebug для профайлинга. Скрипт использует в среднем штук 7-9 классов.
Так вот. Когда все файлы по отдельности, *половина* (да-да, половина) времени — 15 мс из 30 уходит на инклюды. Когда объединяем системные классы в один 70-килобайтный файл — скрипт работает в 2 раза быстрее.
Единственный недостаток этого подхода — непонятно, как сделать автоматическое склеиывание файлов, чтобы при обновлении любого исходного файла обновлялся склееный? Если делать проверки mtime исходных файлов, будет слишком много тормозов.
Ну а что касается «мертвого кода» — не подключайте те файлы, которые не используются, только и всего.
p.s. Кстати, после инклюда. вторая причина тормозов — вызовы htmlspecialchars(), они тормозят жутко. Скорей бы там уже сделали какой-нибудь новый алгоритм.
p.s.2 Кстати, для меня это еще один аргумент против принесенных с Явы фреймфорков-монстров типа ZF, там вообще сотни мелких файлов, у вас только скрипт будет грузиться вечность.
Использовалась винда XP :), apache, php 5.2.8, опкешер APC и Xdebug для профайлинга. Скрипт использует в среднем штук 7-9 классов.
Так вот. Когда все файлы по отдельности, *половина* (да-да, половина) времени — 15 мс из 30 уходит на инклюды. Когда объединяем системные классы в один 70-килобайтный файл — скрипт работает в 2 раза быстрее.
Единственный недостаток этого подхода — непонятно, как сделать автоматическое склеиывание файлов, чтобы при обновлении любого исходного файла обновлялся склееный? Если делать проверки mtime исходных файлов, будет слишком много тормозов.
Ну а что касается «мертвого кода» — не подключайте те файлы, которые не используются, только и всего.
p.s. Кстати, после инклюда. вторая причина тормозов — вызовы htmlspecialchars(), они тормозят жутко. Скорей бы там уже сделали какой-нибудь новый алгоритм.
p.s.2 Кстати, для меня это еще один аргумент против принесенных с Явы фреймфорков-монстров типа ZF, там вообще сотни мелких файлов, у вас только скрипт будет грузиться вечность.
откуда вы взяли, что ZF перенесен с Java? Кроме Zend_Search_Lucene как одного компонента, порт алгоритмики с сохранением форматов/апи.
Посмотрите например книгу Мартина Фаулера — он по ней сделан, а книга про разработку больших корпоративных приложений (а не веб-фреймворков, к слову), и ориентирована в первую очередь на Яву (таким образом далаем вывод о связи ZF и этих самых явовских корпоративных приложений, более чем уверен, что разработчики ZF раньше писали на Яве).
Только в php в отличие от Явы разбиение программы на множество мелких отдельных кусочков выходит слишком дорого с т.зр. производительности.
Только в php в отличие от Явы разбиение программы на множество мелких отдельных кусочков выходит слишком дорого с т.зр. производительности.
«хранить каждый класс в отдельном файле (как советуют всякие стандарты кода) „
Это ж стандарт кода, как вы сами написали =)
Это ж стандарт кода, как вы сами написали =)
Если вам нужна действительно высокая производительность, то стоит задуматься на тему смены языка.
Минусующим показать сравнения производительности с той же самой Java?
Если для повышения быстродействия необходимо писать в обход идеологии языка (без include'ов, к примеру), то стоит задуматься о смене языка, а не об очередном извращении.
Кстати, автор, о том, что топик о PHP было бы неплохо написать заметнее.
Если для повышения быстродействия необходимо писать в обход идеологии языка (без include'ов, к примеру), то стоит задуматься о смене языка, а не об очередном извращении.
Кстати, автор, о том, что топик о PHP было бы неплохо написать заметнее.
UFO just landed and posted this here
Иногда надо не решить задачу, а понять что лучше ее не решать вообще. Ровно также иногда лучше сменить язык, чем плодить извращения.
Если в вашем приложении узким место действительно(!) является PHP, то оправданность подобных игр с кодом под большим вопросом.
PHP хорош для своих задач. Но действительно высокая производительность — не его профиль. Можно ставить кучу серверов, можно сливать весь код в один файл, а можно сменить инструмент на более подходящий.
Если в вашем приложении узким место действительно(!) является PHP, то оправданность подобных игр с кодом под большим вопросом.
PHP хорош для своих задач. Но действительно высокая производительность — не его профиль. Можно ставить кучу серверов, можно сливать весь код в один файл, а можно сменить инструмент на более подходящий.
Смена языка, это хорошо, но почему для этого надо переходить на жрущую память, тормозную Яву со сборщиком мусора? Я предлагаю язык D :) Он компилируемый и хотя бы поэтому в 100 раз лучше явы. И кстати в нем теперь есть замыкания ;)
Почему fastCGI не ускоряет PHP вы можете прочитать у Котерова здесь.Следует заметить, что Дмитрий обходит стороной FastCGI под Windows/IIS, где проблема времени запуска именно исполняемого файла стоит довольно остро. В изначальной версии статьи даже явным образом упоминались (сейчас этого в статье что-то не видно) нулевые накладные расходы на создание fork-копий процессов под Unix. Таким образом, заявление однобоко.
Самое забавное, оказывается, что даже FastCGI в PHP и то «через опу»…
Какие нибудь исходники тестов имеются?
какие исходники вы имеете в виду? мы же тестируем скорость парсинга, а не время выполнения кода. А в качестве того что парсить брались функции и классы из рабочего проекта (для приближения к реальности)
А какой смысл приближать тест к реальности, при этом тестируя только одну из сторон этой реальности? В смысле, почему только парсинг?
Автолоадер хотя бы можно посмотреть?
Автолоадер хотя бы можно посмотреть?
Смысл всех тестов, выяснить, насколько большое время может уходить на парсинг страницы, что на это влияет и какими средствами оптимизации каких результатов можно добиться. Выше я уже писал, что статья носит больше теоретически ознакомительную интонацию, а не призыв к действию или «советы по оптимизации».
При тестах, имитирующих ситуацию использования автолоад просто использовались множественные инклуды мелких файлов. Все данные о кол-ве инклудов и кода в каждом из них есть в таблицах
При тестах, имитирующих ситуацию использования автолоад просто использовались множественные инклуды мелких файлов. Все данные о кол-ве инклудов и кода в каждом из них есть в таблицах
Почему вы считаете, что проблема нахождения мертвого кода алгоритмически неразрешима?
Например, гугловский оптимизатор джаваскрипта так умеет делать.
Конечно, это не очень безопасно из-за всяких eval и call_user_method, но проблема вполне решаемая хотя бы не на самом сложном уровне.
Например, гугловский оптимизатор джаваскрипта так умеет делать.
Конечно, это не очень безопасно из-за всяких eval и call_user_method, но проблема вполне решаемая хотя бы не на самом сложном уровне.
возможно Дмитрий Котеров в своей статье про fastcgi и прав. Он человек уважаемый, многие к нему прислушиваются. Однако как было уже замечено выше, его заявление однобоко.
На своём опыте переводил один нагруженный проект (200к хостов в день) с apache+mod_php на nginx+fastcgi+php. Замечу, что apache был сильно обрезанный и затюненый, никаких лишних модулей, в том числе реврайтов, отключенный htaccess и прочее. После перехода, может php и не стал быстрее открываться, но нагрузка на ЦП снизилась в среднем на 30-40%. Понятно, что на такой прирост производительности повлиял не только fastcgi, но и сама связка nginx+fastcgi, но всё же.
Пару лет спустя, переводили еще более нагруженный проект с apache+mod_php на nginx+php-fpm, прирост производительности составил порядка 50%.
Надо заметить, что на обоих проектах использовались в большей степени собственные софтверные решения, а не ZF, на основе которого писал статью Котеров. Решения уже были заточены под высокие нагрузки.
Так же с год назад помогал размещением одному популярному но не нагруженному проекту (2000-2500 хостов), написанному на ZF. Не смотря на все кеши и акселераторы проект губил сервак.
А мораль такова. Залив спортивный бензин в ладу калину она не поедет быстрее, а скорее клапаны повыбивает. Если вы делаете решение на ZF, то не стоит искать ощутимого прироста производительности от fastcgi+php. тем более если у вас не большая посещаемость.
На своём опыте переводил один нагруженный проект (200к хостов в день) с apache+mod_php на nginx+fastcgi+php. Замечу, что apache был сильно обрезанный и затюненый, никаких лишних модулей, в том числе реврайтов, отключенный htaccess и прочее. После перехода, может php и не стал быстрее открываться, но нагрузка на ЦП снизилась в среднем на 30-40%. Понятно, что на такой прирост производительности повлиял не только fastcgi, но и сама связка nginx+fastcgi, но всё же.
Пару лет спустя, переводили еще более нагруженный проект с apache+mod_php на nginx+php-fpm, прирост производительности составил порядка 50%.
Надо заметить, что на обоих проектах использовались в большей степени собственные софтверные решения, а не ZF, на основе которого писал статью Котеров. Решения уже были заточены под высокие нагрузки.
Так же с год назад помогал размещением одному популярному но не нагруженному проекту (2000-2500 хостов), написанному на ZF. Не смотря на все кеши и акселераторы проект губил сервак.
А мораль такова. Залив спортивный бензин в ладу калину она не поедет быстрее, а скорее клапаны повыбивает. Если вы делаете решение на ZF, то не стоит искать ощутимого прироста производительности от fastcgi+php. тем более если у вас не большая посещаемость.
Вы просто для себя взгляните как реализована работа в FastCGI например в Perl, вы сразу поймёте, что в PHP что-то не так. Именно в этом мысль Котерова, а не то, что он смотрел на FastCGI + PHP в связки не Windows/IIS системы :)
Дмитрий говорит не то, что реализация FastCGI для PHP не верная. Он говорит, что она не даёт прироста производительности, и доказывает это тем, что реализация FastCGI для PHP не верная. Разные вещи.
это напрямую зависит :) в php реализации «похерена» вся суть, что должен был решить fastcgi каждый раз не дергая библиотеки, код и т.п.
а в целом-то это проблема самой архитектуры PHP, его монолитности с кучей засоренного нэймспейчас, посчитайте сколько функций для работы со строками на str* и плюс еще тоже самое mb_*
а в целом-то это проблема самой архитектуры PHP, его монолитности с кучей засоренного нэймспейчас, посчитайте сколько функций для работы со строками на str* и плюс еще тоже самое mb_*
Института системного проектирования
Программирования, всё-таки.
мнимый выигрыш в 5 десятых секунды…
конечно если у вас парк серверов по 100 штук то есть смысл запариться, а если их 10-20, то, имхо, смысла нет. только портатите миллионы времени на рефакторинг и в дальнейшем миллионы времени на доработку\дебаг
конечно если у вас парк серверов по 100 штук то есть смысл запариться, а если их 10-20, то, имхо, смысла нет. только портатите миллионы времени на рефакторинг и в дальнейшем миллионы времени на доработку\дебаг
Мда. Реализация PHP адова. mod_php нихрена не mod, fcgi нихрена не fcgi.
Как это должно происходить. Стартовый скрипт должен заинклюдить как можно больше модулей. Потом этот жирный процесс форкается много раз, за счет чего экономится память. После этого каждый процесс в бесконечном цикле обрабатывает запросы. Да, приходится немного поплясать с бубном, следить за базаром и после каждого запроса обнулять кучу переменных, но оно того стоит. FGCI по большому счету то же самое. Эти технологии были придуманы, чтобы сэкономить время на подгрузке модулей и на компилировании исходника. mod_perl так и работает кстати.
В случае с PHP на каждый запрос компилируется исходник и выполняется. Отсюда масса времени уходит на подгрузку модулей и на компиляцию. Все эти акселераторы и кешеры кода по большому счету и обеспечивают более менее подобие работы нормального mod или FCGI.
Вывод: все описанные проблемы и бубны следствие не правильной архитектуры самого языка.
Как это должно происходить. Стартовый скрипт должен заинклюдить как можно больше модулей. Потом этот жирный процесс форкается много раз, за счет чего экономится память. После этого каждый процесс в бесконечном цикле обрабатывает запросы. Да, приходится немного поплясать с бубном, следить за базаром и после каждого запроса обнулять кучу переменных, но оно того стоит. FGCI по большому счету то же самое. Эти технологии были придуманы, чтобы сэкономить время на подгрузке модулей и на компилировании исходника. mod_perl так и работает кстати.
В случае с PHP на каждый запрос компилируется исходник и выполняется. Отсюда масса времени уходит на подгрузку модулей и на компиляцию. Все эти акселераторы и кешеры кода по большому счету и обеспечивают более менее подобие работы нормального mod или FCGI.
Вывод: все описанные проблемы и бубны следствие не правильной архитектуры самого языка.
Sign up to leave a comment.
Разбираемся с проблемой мертвого кода и инклудами