PHP для гуру и извращенцев :)

Октябрь 31, 2007

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

К таковым можно отнести, например, unset каждой отработавшей переменной, использование передачи значения по ссылке(даже на циферку 2 или буковку «Б») и так далее.

Сейчас я работаю над собственной cms (уж со счету сбился, какое количество модификаций она прошла, но счетчик показывает версию 0.1.8, что говорит о восьмой версии второй ветки). Так получилось, что я решил использовать ее исключительно на *nix платформах и оптимизировать донельзя.

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

Оговорюсь сразу, что код, на основе которого будут приниматься решения о быстродействии не оптимизирован (дабы в нём было легко ориентироваться и он не заставлял задавать вопросы). Конечно, я проверяю код прежде, чем его опубликовать, поэтому, если у Вас возникли вопросы по поводу работоспосбности скриптов — пишите в комментах, постараюсь разобраться в Вашей проблеме, если это потребуется.

Итак, выдвигаем тезис идеи:

увеличения быстродействия системы можно увеличить путем использования более низкоуровневых стандартных функций и приложений систем Unix/Linux, которые установлены на ваших серверах.

8 комментариев на “PHP для гуру и извращенцев :)”

  1. pimax высказал:

    Бред.

    Увеличить быстродействие системы написанной на PHP/MySQL можно путем оптимизации кода, грамотного построения архитектуры системы, оптимизации запросов к БД, гибкой системой кеширования.

    А то, что Вы написали — это эффектно звучит для новичков программирования.

  2. jeurey высказал:

    Бред? Почитайте статьи далее — там есть примеры, тесты, показатели. В частности — копирование данных средствами cp...

    Или, может, будете утверждать, что copy (php) быстрее wget (posix)? )

    Никто не отрицает того, что код нужно оптимизировать, что запросы левые не нужно пихать... что скрипты поиска должны работать на индексах... Только стоит учитывать, что скрипт построения дерева FTP будет работать в 3,4,5 раз медленнее, чем бинарь. Это — факт.

  3. pimax высказал:

    Безусловно команды ОС выполняются гораздо быстрее чем команды php, т.к. php передает команду интерпретатору а тот уже выполняет еще средствами ос, но как часто Вы используете команды копирования файлов в системе управления контентом? ИМХО не на этих операциях нужно выигрывать время выполнения скрипта, а на тех, которые выполяются гораздо чаше.

    Плюс ко всему — это не безопасно, т.к. в случае взлома системы, хакер сразу сможет получить веб шелл к серваку, лично у меня на сервере забликорованно несколько функций php, включая system ().

    И еще, зачем привязывать пользователя к определенной ОС? А если я захочу на мак поставить, или на винду? Нужно оставлять право выбора... Вот Битрикс например, у него есть выбор, хочешь дешего и со вкусом, бери версию с мускулом, а хочешь бери дорого, но круто с ораклом.

  4. jeurey высказал:

    Это все верно. Есть только пару замечаний:

    1. Я работаю, в основном, в области сервисов — а там копирование файлов происходит часто.

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

    3. Много сайтов знаете, которые крутятся на виндовых и макосовых серверах? :)

  5. pimax высказал:

    1) Безусловно для решения этой задачи функции ос использовать гораздо правильнее, чем функции php, но тогда советую указать в статье о том, в каких случаях следует применять описанные приемы.

    2) Да, возможность создания бэкапов есть, но опять таки не нужно ограничевать пользователя в выборе. Вдруг для виртуального хостинга на серваке отключена возможность использования архиваторов? Что тогда, сидеть и надеятся что сайт никогда не придется восстанавливать? Но это тоже единичный случай. Для админа не так важно сколько минут он потратит для создания бэкапа. Оптимизировать нужно пользовательскую часть.

    3) Нет, не много... Я сам не фанат этих систем, но опять таки зачем ограничивать пользователя.

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

  6. Jeurey высказал:

    Универсальные системы — зло. Многие разделяют мою точку зрения и вот почему:

    1. На лицо использование кросс-платформенных методов. Таким образом, php образует некоторую виртуальную машину, что пораждает снижение быстродействия.

    2. Увеличивают размер и уменьшают быстродействие системы, если разработчик пытается решить проблему кроссплатформенности средствами банальных if/else... Не исключено, что подобных бинарников в конкурирующей ОС просто нет — пишем на php?

    Можно дальше продолжить ряд. Это и так понятно.

    Далее — по самому принципу. Именно от таких комментариев у людей складывается мнение о «хреновости» языка PHP. Они ведь не разбираются в том, что PHP не для того создан — приходится выкручиваться.

    Нашим заказчикам приходится выбирать — что использовать: быстрые и надежные методы (более стабильные, как ни крути) либо переносимость. Переезд — единичный случай, а вот бэкап — позволю себе несогласиться... У нас ресурсы бэкапятся очень часто. Ситуация вынуждает использовать бинари.

    Плюс — не приходится геморроиться с перезаписью и избыточностью информации, если чуток покурить в сторону $> zip...

    Конечно, никто не спорит о том, что стоит увеличивать быстродействие еще и внутри скриптов. Яркий тому пример — while ($i<count ($array)){...}

    :)

  7. pimax высказал:

    Начнем с того, что в статье идет речь о CMS, а cms — это как ни странно, система управления контентом.

    Если речь идет о серверных приложениях для работ, требующих очень большой производительности, тогда конечно использование ресурсов ОС незаменимо, но в этом случае было бы логично писать приложение на языке программирования высокого уровня, например C++. Написав приложение на сях Вы получите такой прирост производительности, о котором даже не мечтали, используя PHP как прослойку между серверный по действиями юзера.

    В случае CMS — универсализация ИМХО на первом месте. И это действительно так, в другом случае система управления писалась бы для каждого сайта индивидуально, что очень затратно и не выгодно ни заказчику ни исполнителю.

  8. jeurey высказал:

    Начнем с того, что я написал:

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

    Про использование самописных c++ приложений: а зачем? есть сервис по аплоаду файлов на ftp: зачем я буду писать свой бинарь, если есть стандартный, если можно использовать php в его ПРЯМОМ качестве — прослойки между GUI и сервером?

    А с CMS — не соглашусь. Универсализации не может быть в принципе: никто не говорит ведь, что CMS- кросплатформенный продукт. CMS- это управление контентом, в первую очередь — никто не говорит что она должна быть универсальной и идти на всех хостах.

    Под cms не обязательно понимать систему all-in-one: есть базовое ядро, есть набор модулей. Одному заказчику нужно первое, другому — второе, третьему — третье... Так почему в качестве зависимости модуля не может быть альтернативы из библиотеки на PHP и бинарника?

    А писать подобные системы очень даже выгодно.

    Во первых — это стабильное приложение. Потому, что бинарники оттестированы и проходят буферную зону перед добавлением в репозиторий/список портов.

    Во вторых — это снижает, весьма значительно, объем работы программиста GUI. Мне остается всего-лишь накидать интерфейс и вызвать бинарь. А количество кода играет не последнюю роль в стоимости заказа (я пока промолчу про качество. Я про себя сужу и тех программистов, которых знаю.)

    В третьих — нет надобности постоянно следить за состоянием своих библиотек кода — если посмотреть, хотя бы, на один wget — у него столько возможностей, что им можно и спамить, и прокси проверять, и файлы заливать :)

    Теперь представьте, сколько кода на php нужно написать, чтобы реализовать хотя-бы это. Потом дебажить его. Документацию составлять... А ведь на скрипт в 100 строк может быть документации на 200 :)