PHP *

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

Когда пришлось реализовывать дерево комментариев, столкнулся с необходимостью рекурсивного вызова представления (view в MVC). Так как представления у меня, да и практически везде, — это обычные файлы с кусками HTML-кода и возможностью вставки PHP, то подключаются они с помощью include. Мне стало не по себе, когда представил как этот include вызывается рекурсивно сотни раз. Первая мысль — засунуть файл представления при первом запросе в память и потом выполнять его через eval. Такой подход позволит кешировать код представлений, и даже хранить его в БД. Так как eval кушает только PHP, а представления у нас чистым PHP-кодом не являются, то обрамляем содержимое в '?>' и '<?php'.

PHP один из самых популярных скриптовых языков программирования. Почти 60% веб серверов используют PHP.Миллионы веб-сайтов и веб-приложений разрабатываются на PHP каждый месяц.

PHP изначально разрабатывался как простая замена языку Perl, и уже спустя пару лет он стал чрезвычайно мощным и популярным. Язык PHP, сам по себе очень похож на ANSI C.
Одна из причин почему PHP стал таким популярным это его короткий период обучения.

Изучение PHP абсолютно не тяжёлое занятие, особенно если вы хорошо знакомы с синтаксисом Java или C.

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

Достался один проектик, написанный румынскими аутсорсерами для немцев.

В следующей процедуре румыны проверяют, дал ли пользователь допустимое имя таблице для MySQL (имя вводится в форму, по нему создается таблица).

 

 

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

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

Первую часть читайте здесь.

Теперь приступим к практике. Наиболее показательным примером использования LSB, по-моему, является случай, когда у вас есть набор классов выполняющих похожие действия. В терминах веб-разработки мы часто встречаемся с такими задачами при обращениях к таблицам базы данных, особенно в ORM системах. Все ваши объекты для работы с таблицами будут похожи по сути, но при этом будут иметь собственный функционал ( и, соответственно, свои подклассы).

Позднее Статическое Связывание (Late Static Binding, LSB) является бурно темой обсуждений последние три года в кругах разработчиков PHP (и наконец мы его получили в PHP 5.3). Но зачем оно нужно? В данной статье, как раз и будет рассматриваться, как позднее статическое связывание может значительно упростить ваш код.

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

Вопрос: «Что быстрее — echo или print?» не перестаёт будоражить умы тех, кто считает себя профессиональным программистом на PHP. Руководство пользователя осторожно упоминает об имеющемся различии, но отсылает к статье стороннего авторства; та, в свою очередь, утверждает, что echo быстрее, но не приводит доказательств; трудно найти объективное сравнение, и всё это придаёт проблеме некий мистический ореол, на что клюют многие и многие.

Так не будем же оставаться в стороне и постараемся раз и навсегда разгадать эту загадку!

1) Какой бы ерундой вы не занимались с PHP, узкое место _всегда_ — БД. PHP — он как Буратино — тупОЙКАк… дрова. Lighttpd и Nginx позволяют разнести его по множеству физических серверов на раз без шума и пыли. Зарплата адекватного спеца по PHP в Москве — 30-45 тыс. рублей в месяц, стоимость аренды нормального сервера — от 3 тыс. рублей в месяц. А вы не знали ;)?

2) Какой бы ерундой вы не занимались — 30-60% производительности (возможно и больше) PHP-кода решит правильно выбранный и настроенный акселератор.

3) Серебряной пули нет. Не важно, какой концепт вы применяете — строгое ООП (в стиле Zend Framework), функции в стиле PHP4 (или ограниченное ООП) или вообще лапшу в стиле «PHP для чайников» — ни одна из этих парадигм не даст ощутимый прирост производительности, если конечно ваши программисты не выше как минимум на голову.

Всем доброго времени суток.

Перевод заметки "40 Tips for optimizing your php code". Автор — Reinhold Weber.

1. Если метод может быть статическим, объявляйте его статическим.
2. echo быстрее, чем print.
3. Передавайте в echo несколько параметров, вместо того, чтобы использовать конкатенацию строк.
4. Устанавливайте максимальное количество проходов ваших циклов for до цикла, а не во время его выполнения.
5. Удаляйте свои переменные для освобождения памяти, тем более, если это большие массивы.
6. Остерегайтесь магических методов, таких как __set, __get, __autoload.
7. require_once дорого обходится.
8. Указывайте полные пути в конструкциях include/require, меньше времени будет тратится на поиск файла.
9. Если вам необходимо определить время, когда скрипт был запущен, используйте $_SERVER[’REQUEST_TIME’] вместо time().
10. Старайтесь использовать strncasecmp, strpbrk и stripos вместо регулярных выражений.

 

Отчего-то всегда хотел сделать свой сервис для загрузки файлов. Всевозможные slil/zalil не устраивали своей скоростью. ifolder — обилием рекламы. Пользовался не очень популярным (от этого он ни чуть хуже не становился) сервисом up.spbland.ru. Но это как-то не правильно. И тут я решил написать свой сервис. Не буду вдаваться в подробности и рутину, только концепция.

 

В общем, начинаю постепенно выкладывать троды плудов на суд общественности. На www.frwk.net появились уже трак проекта и блог, куда я мало-помалу буду постить информацию о фреймворке.
Вкратце: Frontier предоставляет связи между компонентами, легко помогает подключать различные прикладные библиотеки, а сам предлагает только структуру приложения, общую конфигурацию и т.п. Краткое описание оформлено одним из постов там же: www.frontierframework.net/blog/2008/03/29/the-travel-begins

Основная мотивация изобретения этого велосипеда была в том, что очень уж надоели тяжёлые фреймворки, которые навязывали свои решения по многим поводам, хотелось в первую очередь свободы: не перекраивая модель мышления писать разные приложения с использованием разных же библиотек. Сначала думал, что буду делать с его помощью только мелкие вещи, но на серьёзных проектах «Фронтир» тоже проявил себя неплохо.

Буду рад всяческим комментам.

По просьбе: www.frontierframework.net/release/hello.tar.gz — это минимальное приложение с комментариями на русском.

Наверняка большинство программистов, работающих с современными веб-фрейворками, реализующими схему MVC, сталкивалось с таким небольшим затруднением: кэширование фрагмента View.

Хорошие фреймворки предлагают инструменты для полного кэширования страниц, фрагментарного, или кэширования экшенов. Недавно я посмотрел 90 выпуск подкаста Railscasts, посвященный именно фрагментарному кэшированию в Ruby on Rails и уважаемый автор решал проблему, как мне показалось, неоптимально.

Опишу ситуацию.
Мы в шаблоне страницы и хотим закэшировать ее часть, например, список новых товаров. Пока все хорошо, мы пользуемся встроенными во фреймворк удобными средствами и в две-три строчки окружаем блок — ура, он кэшируется. Но — чу!, контроллер-то об этом ничего не знает и продолжает выполнять свою работу по подготовке данных для View. Естественно, ведь проверка наличия кэша осуществляется уже из шаблона, а контроллер к тому моменту отработал.

Два дня назад один из разработчиков PHP Дмитрий Стогов (dmitry+at+zend+dot+com) опубликовал результаты тестов новой версии php 5.3

Он не описывает какие именно тесты он производил, но статистика впечатляет
Drupal 20% быстрее
Qdig 2% быстрее
typo3 30% быстрее
wordpress 15% быстрее
xoops 10% быстрее

PHP 5.3 станет быстрее (http://news.php.net/php.internals/36484)

<p />Итак, мы решили начать программировать «по понятиям» и наконец разобраться с каким-нибудь фреймворком.
<p />Перед нами встаёт мучительный выбор, какой же фреймворк для этого использовать. Для этого можно найти кучу статей, обзоров, сравнительных анализов скорости, производительности, удобства использования и установки, а можно просто набрать в гугле «php framework» и кликнуть

Поискал ссылки поиском по хабру, не нашел.

Итак, прежде чем изобретать велосипед, у разработчика часто возникает необходимость посмотреть, какие же продукты уже были реализованы.
Кто-то начинает гуглить — что же, наверное, это правильно.

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

Итак, вот они:
www.hotscripts.com
www.planet-source-code.com
php.resourceindex.com
cgi.resourceindex.com
www.scripts.com/php-scripts
www.phpclasses.org
mymans.org/category/php