Posterous theme by Cory Watilo

Itinerarium


by Dmitry Shaposhnik

Filed under: PHP

MacOS X Leopard php extensions

Столкнулся с необходимостью добавить к PHP в макоси несколько экстеншенов. Апач в MacOS работает в x86_64. Да-да, там бинарник для нескольких архитектур:

file `which httpd`

Проблема в том что по умолчанию экстеншены будут собираться под i386. И потому из php-cli они доступны и работают, в то время как в mod_php их нет, а в логах апача видно примерно такое:

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/extensions/no-debug-non-zts-20060613/mcrypt.so' - (null) in Unknown on line 0

Для сборки под несколько архитектур надо собирать все зависимости также под несколько архитектур. Я решил ограничиться вариантом x86_64 и i386.

Итак, в /opt/local/etc/macports/macports.conf добавим требуемые архитектуры:

sudo echo 'universal_archs x86_64 i386'>> /opt/local/etc/macports/macports.conf

Чудесно. Теперь на примере gettext.

sudo port install gettext +universal
file `which gettext`

В качестве вывода мы должны получить что-то вроде

dm@Loki ~$ file `which gettext`
/opt/local/bin/gettext: Mach-O universal binary with 2 architectures
/opt/local/bin/gettext (for architecture i386): Mach-O executable i386
/opt/local/bin/gettext (for architecture x86_64):   Mach-O 64-bit executable x86_64

Далее нужны сорсы php. В сорсах есть папка ext.

cd php-5.2.8/ext/gettext
phpize

CFLAGS="-arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp" \
CCFLAGS="-arch i386 -arch x86_64 -g -Os -pipe" \
CXXFLAGS="-arch i386 -arch x86_64 -g -Os -pipe" \
LDFLAGS="-arch i386 -arch x86_64 -bind_at_load" \
./configure --with-gettext=/opt/local

make
sudo make install
sudo echo 'extension=gettext.so' >> /etc/php.ini
sudo apachectl restart

Предварительно убедитесь, что у Вас есть файл /etc/php.ini. По умолчанию его нет.

После этого модуль должен завестись в mod_php.

UPD: а чобы (по возможности) все из портов собиралось с флагом universal надо сделать

echo '+universal' >> /opt/local/etc/macports/variants.conf

Webservers benchmark

Решил потестировать PHP в разных связках, а именно - Apache + mod_php, Apache + mod_fcgid + php, Lighttpd + mod_fastcgi + php. Все это еще в двух вариантах - с APC (Advanced PHP Cache) и без него. Тестировал выполнением вот такой команды: [cc lang="bash"] ab -c 5 -n 500 http://dmitry.shaposhnik.name/ [/cc] Выполнял команду на другом сервере чтобы снизить влияние случайных факторов. И вот что получилось в результате:
Вот полный вывод в текстовом виде: testing results UPD: вот на том же сервере решил протестировать приложение-блогодвижек (Записки айтишника) на рельсах той же командой.

Read the rest of this post »

PHP Optimizers revisited

Только-что наткнулся на эту публикацию, в которой основные ссылки - на сорс и на результат. Как и показали результаты, стоит особо присмотреться к APC. Лично я еще после первого тестирования перешел на него. UPD: есть нарекания на конфиг XCache в приведенном тесте, но у меня он страшно "лагал" с правильным конфигом, так что я свой выбор не поменял.

NetBeans 6.0 released

Наконец-то вышел NetBeans 6.0 - замечательная Java IDE. Для меня она ценна изумительной поддержкой Ruby, а также наличием в плагинах средств для работы с UML, PHP, C/C++.
Media_httpblogssuncom_elwci

Server monitoring tool

Стояли у меня разные сервера, и для мониторинга сервисов на них стоял monit. Со своей задачей он справлялся - если что-то упало - поднять указанным скриптом. Но чего нехватало - так центра, в котором я бы мог озирать со своего места все сервера.

Read the rest of this post »

Tidy

[cc lang="php"] $config = array( 'doctype' => "strict", 'indent' => 'auto', 'output-xhtml' => true, 'wrap' => 90, 'show-body-only' => true, 'enclose-block-text' => true ); $encoding="raw"; $tidy = new tidy; $tidy->parseString($text, $config, $encoding); $tidy->cleanRepair(); return "$tidy"; [/cc] При работе с текстом в cp1251 все замечательно, при utf8 имеем знаки вопроса когда встречается два и более пробелов. Лечение: [cc lang="php"] $encoding="utf8"; [/cc]

PHP opcode cachers review

"Папа обещал - папа сходил"

Обещался я сделать сравнение разных средств для ускорения работы скриптов. Если кто будет говорить о неточности или неправильности метода тестирования - говорите как лучше, сделаем лучше. Итак, основным камнем преткновения для проведения тестирования послужило использование Zend Framework. Он использует чрезмерно много загрузок разных файлов, что заметно снижает скорость работы. Тестовый стенд - ноутбук Asus A6Tc, OS: Linux Ubuntu "Gutsy", Lighttpd-1.4.17, PHP 5.2.3 через FastCGI. Тестовое приложение основано на Zend Framework, использует подключение к БД (но не делает выборок), а для View использован Smarty. Тестировал Pure PHP, Zend Optimizer 3.3.0, XCache 1.2.1, APC 3.0.14, eAccelerator 0.9.5.2. Тестировал тривиально и просто - замерял время запуска и время окончания внутри скрипта, в конце вывода смарти эхал полученое время. И копипастил его (все действия для чистоты эксперимента проводились с другой машинки) в OO SpreadSheets. Вот результаты (время в мс):

Pure PHP ZO XCache APC eAccelerator
247.8 272.92 573.43 397.9 156.2
251.04 271.81 106.81 89.75 74.16
245.14 286.8 108.96 88.38 110.42
252.72 267.1 91.01 89.2 534.97
207.39 221.43 65.54 47.49 69.55
209.5 221.34 65.89 53.31 71.01
217.66 232.13 70.04 47.66 70.32
202.88 222.59 66.1 48.04 70.26
203.17 220.79 69.94 54.19 70.76
204.03 235.28 65.76 48.49 70.05
И вот по этому добру график:
С XCache был замечен баг: если дважды быстро обновить страницу то контент вылазил полтора-два-три раза. Но я думаю это из-за перегенерации шаблона в Smarty. Однако неприятный осадок остался. Жду комментариев =)

XCache

Попробовал только-что настроить XCache. Впечатления положительные. Простое приложение на ZF 1.0.1 со Smarty отдавало тестовую страничку за 0.1-0.2 секунды. После установки XCache страничка отдается за 0.018 сек. Что весьма радует ;) Еще оно не будет работать вместе с ZendOptimizer - соответственно, зашифровать скрипты Zend Guard'ом уже не удасться. Но есть альтернатива - IonCube. Вот такой конфиг получился у меня: [cc lang="ini"] extension = xcache.so [xcache.admin] xcache.admin.auth = On xcache.admin.user = "admin" xcache.admin.pass = "4eae35f1b35977a00ebd8086c259d4c9" [xcache] xcache.shm_scheme = "mmap" xcache.size = 64M xcache.count = 2 xcache.slots = 8K xcache.ttl = 0 xcache.gc_interval = 30 xcache.var_size = 64M xcache.var_count = 1 xcache.var_slots = 8K xcache.var_ttl = 0 xcache.var_maxttl = 0 xcache.var_gc_interval = 30 xcache.test = On xcache.readonly_protection = Off xcache.mmap_path = "/dev/zero" xcache.coredump_directory = "/tmp/phpcore/" xcache.cacher = On xcache.stat = On xcache.optimizer = On [xcache.coverager] xcache.coverager = Off xcache.coveragedump_directory = "" [/cc] PS: В новостях недосмотрел - он уже может работать с ZendOptimizer. Надо будет проверить ;)

ZendOptimizer with FreeBSD

Баг - не работает ZendOptimizer. При выполнении скрипта в браузере видим чистую страницу. Наблюдения: Любопытно, но в консоли "php info.php" видим все чудесно. Очевидно, все прекрасно и с php-cgi. Опыт это доказал. Данные: Итак, имеем
  • ось FreeBSD example.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0.
  • скрипты, которые зашифрованы ZendGuard-ом.
  • апач версии apache-2.2.4.
  • PHP версии 5.2.3.
Такие скрипты работают только при установленном ZendOptimizer. На данный момент версия 3.3. Лечение: Первое что я увидел - народ советует удалить Suhosin-патч, якобы мешает он. У меня его удаление не дало результата. Второе - народ сползал на апач 1.3 и все само собой лечилось. Но это же неинтересно ;) Я же дошел до того, что поставил к апачу mod_fcgid-2.1_1 и через него подключил php-cgi. Чудесным образом все заработало. Вот что вышло в конфиге: в /usr/local/etc/apache22/httpd.conf добавляем строку [cc lang="text"]LoadModule fcgid_module libexec/apache22/mod_fcgid.so[/cc] Потом чуть ниже добавляем вот такое: [cc lang="text"] AddHandler fcgid-script .fcgi [/cc] Потом непосредственно в конфиге vhost'а добавляем вот такие строки: [cc lang="text"]AddType application/x-httpd-fastphp .php Action application/x-httpd-fastphp /cgi-bin/php[/cc] phpinfo теперь должен показать что он работает через CGI/FastCGI. И криптованые скрипты в такой конфигурации работают чудесно.
​