The WebDevil » PHP

MacOS X Leopard php extensions

dm — Fri, 29 May 2009 12:33:47 +0000

Столкнулся с необходимостью добавить к 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

dm — Sun, 03 Feb 2008 05:08:54 +0000

Решил потестировать PHP в разных связках, а именно – Apache + mod_php, Apache + mod_fcgid + php, Lighttpd + mod_fastcgi + php. Все это еще в двух вариантах – с APC (Advanced PHP Cache) и без него.

Тестировал выполнением вот такой команды:

ab -c 5 -n 500 http://dmitry.shaposhnik.name/

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

И вот что получилось в результате:

Вот полный вывод в текстовом виде:
testing results

UPD: вот на том же сервере решил протестировать приложение-блогодвижек (Записки айтишника) на рельсах той же командой.

Document Length: 13176 bytes

Concurrency Level: 5
Time taken for tests: 15.141659 seconds
Complete requests: 500
Failed requests: 0
Write errors: 0
Total transferred: 6743500 bytes
HTML transferred: 6588000 bytes
Requests per second: 33.02 [#/sec] (mean)
Time per request: 151.417 [ms] (mean)
Time per request: 30.283 [ms] (mean, across all concurrent requests)
Transfer rate: 434.89 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 1
Processing: 6 100 1126.2 7 15141
Waiting: 4 98 1126.1 5 15139
Total: 6 100 1126.2 7 15141

Percentage of the requests served within a certain time (ms)
50% 7
66% 8
75% 9
80% 10
90% 11
95% 13
98% 110
99% 211
100% 15141 (longest request)

UPD: по коментариям Вадима сделал более жесткий тест:

ab -c300 -n3000 http://dmitry.shaposhnik.name/test.php

testing results, heavy testing
Без APC mod_fcgid отлетает (2 запроса). Подскажите как подтюнинговать.

PHP Optimizers revisited

dm — Thu, 27 Dec 2007 11:34:15 +0000

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

UPD: есть нарекания на конфиг XCache в приведенном тесте, но у меня он страшно “лагал” с правильным конфигом, так что я свой выбор не поменял.

NetBeans 6.0 released

dm — Mon, 03 Dec 2007 21:26:22 +0000

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

Server monitoring tool

dm — Fri, 30 Nov 2007 18:47:46 +0000

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

Вот так и решил поставить nagios. Поставил, посмотрел, попытался настроить, что-то получилось. Так как я – вэбдевел, то я, понятное дело, привы пользоваться вэб-мордами для таких штук. И у нагиоса она не то чтоб неюзабельна… Там полное отсуствие термина “удобство”. За что он и был снесен на следующие сутки.

Вторым… точнее второй была сестрёнка – BigSister. Но она мне что-то сразу не приглянулась, и прожила минут 10-15. На большее меня нехватило. Интерфейс тоже неахти какой.

Попробовал я и ManageEngine(r) OpManager – я не смог его запустить, так как он требовал старые либы. У него внутри свой апач, что порадовало – ведь системный может и отвалиться, а мониторилка должна продолжить жить. Но именно этот апач и не стартовал из-за возраста.

И вот, наконец, меня подтолкнули в сторону Zabbix. Сначала его навороченость меня отпугнула, юзабилити показалось страшным, но уже много лучше нагиоса. А потом я его настроил – что оказалось весьма легко – и обрел счастье.

В общем, что сие из себя представляет.
Есть сервер, есть агент. Сервер пишет в MySQL/PostgreSQL/Oracle/SQLite. Есть вэб-морда (PHP), которая работает как раз с этой самой sql-базой. Клиент коннектится к серверу (или нескольким серверам). Первому в списке серверу он шлет всю инфу как можно чаще, остальным – более умеренно. По какому протоколу – не знаю, вроде по своему (поверх tcp).
Ну а дальше у морды настраиваются триггеры (события, при которых шлется уведомление), item’ы (события, на которых строятся триггеры), media (чем и как и куда слать – даже через COM через сотовый может =)), графики и т.п.
Агент, кстати, может выполнять указанные сервером команды. Например, при падении апача/мускуля/etc поднять его.

В общем – пока у меня живет Zabbix, и я доволен. Всем советую.
Но планы на разработку сходной мониторилки с человеческим обличьем уже есть

php developers test

dm — Sun, 04 Nov 2007 18:37:06 +0000

Набрал не пользуясь шпаргалками. Оставалось еще 5 минут, так что можно было и подглянуть =)

Tidy

dm — Wed, 19 Sep 2007 07:56:09 +0000

$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";

При работе с текстом в cp1251 все замечательно, при utf8 имеем знаки вопроса когда встречается два и более пробелов.
Лечение:

$encoding="utf8";

PHP opcode cachers review

dm — Sat, 15 Sep 2007 00:07:47 +0000

“Папа обещал – папа сходил”

Обещался я сделать сравнение разных средств для ускорения работы скриптов. Если кто будет говорить о неточности или неправильности метода тестирования – говорите как лучше, сделаем лучше.

Итак, основным камнем преткновения для проведения тестирования послужило использование 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

dm — Fri, 07 Sep 2007 13:05:33 +0000

Попробовал только-что настроить XCache. Впечатления положительные.

Простое приложение на ZF 1.0.1 со Smarty отдавало тестовую страничку за 0.1-0.2 секунды. После установки XCache страничка отдается за 0.018 сек. Что весьма радует

Еще оно не будет работать вместе с ZendOptimizer – соответственно, зашифровать скрипты Zend Guard’ом уже не удасться. Но есть альтернатива – IonCube.

Вот такой конфиг получился у меня:

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 = ""

PS: В новостях недосмотрел – он уже может работать с ZendOptimizer. Надо будет проверить

ZendOptimizer with FreeBSD

dm — Mon, 03 Sep 2007 12:05:43 +0000

Баг – не работает 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 добавляем строку

LoadModule fcgid_module libexec/apache22/mod_fcgid.so

Потом чуть ниже добавляем вот такое:

AddHandler fcgid-script .fcgi

Потом непосредственно в конфиге vhost’а добавляем вот такие строки:

AddType application/x-httpd-fastphp .php
Action application/x-httpd-fastphp /cgi-bin/php

phpinfo теперь должен показать что он работает через CGI/FastCGI. И криптованые скрипты в такой конфигурации работают чудесно.