Вызов статических методов классов — прекрасная альтернатива обычным функциям - и класс создавать не нужно и принципы объектно-ориентированного программирования не нарушаются. Однако, в реализации статических методов в PHP  есть несколько проблем - статические методы не всегда корректно наследуются, поэтому, чтобы нивелировать неудобства статических методов в PHP часто используют синглетоны - обертывают денимические методы статическими обертками.

Однако, создание синглетона операция довольно ресурсоёмкая — проверить создан ли экземпляр класса, создать экземпляр класса если он не создан, вызвать на нём нужный метод. Насколько это сказывается на бытродействии я и решил сегодня проверить.

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

Вот исходный код скрипта.

Результат работы скрипта представлен в таблице ниже:

В тестовом скрипте, я сравнил обычные PHP функции, статические методы класса, обычные методы и методы синглетона.

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

При этом выяснилось несколько дополнительных вещей: cтатические вызовы функций объявленных без модификатора "static" примерно в два раза медленнее, чем с ним, cтатические методы немного медленнее, чем динамические.

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

Не знаю, сталкивался ли кто или это мне повезло, но вчера поймал загадочный баг, похоже, что в движке PHP, хотя, пока до конца не уверен.

Предыстория такая - работаю над проектом, над которым потрудились индийские программисты. Сам проект сделан на движке Symphony - добротный такой движок, вполне приятный. В качестве библиотеки работы с базой данных используется Creole - тоже довольно приятная штука. В качестве ORM используется Propel — штука громоздкая, но тем не менее тоже весьма мощная и простая. Вообще Symphony показался мне весьма неплохим движком, весьма простым и удобным. Наверно, потому, что он почти один в один копирует Ruby on Rails - те же хелперы, тот же yml в конфигах, такой же подход к MVC - в общем очень похоже.

Так вот, доблестные индийские программисты, вместо того, чтобы использовать оснастку из Symphony навставляли везде mysql_connect и mysql_query. И все бы ничего, но mysql_connect у них вставляется ВЕЗДЕ перед mysql_query — в одном скрипте может быть создано несколько десятков соединений, а каждый mysql_query дополняется проверкой "or die(mysql_error())", поэтому любая ошибка в sql ведет к скоропостижной кончине всего скрипта.

Чтобы хоть как то исправить это безобразие я сначала удалил все mysql_connect. Затем, все mysql_query поиском и заменой заменил на собственную функцию, использующую оснастку creole, поместил её в глобально видимый класс myTools::query():

static function query($sql){
         $connection = Propel::getConnection();
         $r = $connection->executeQuery($sql);
         return $r->getResource();
}

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

Что это — глюк самого PHP или глюк Simphony я так и не понял, пришлось немного модифицировать класс MySQLConnection и добавить туда метод возвращающий MySQL ресурс непосредственно, минуя всякие PHP обёртки, но осадочек все же остался...

Не спорю, штука прикольная, но уж больно архитектура у него специфическая:

1. нет OOP: несмотря на то, что в системе вроде бы присутствуют классы - основная функциональнасть реализована на функциях;
2. плохие привычки программирования: широко используются глобальные переменные;
3. JavaScript ад: бардак со скриптами - доходит до того что каждый плагин тянет за собой собственный jquery или prototype;
4. тем полно, но все кривые: темы сделаны по-идиотски - нет единого соглашения для создания тем, нет четкого разделения навигации и шаблонов - по сути вся навигация и функционал заложены в теме - а это половина движка;
5. нет MVC: собственно нет шаблонов вообще - логика перемешана с HTML так не кодируют уже давно;
6. SQL: движёк для работы с базой данных неплох - но он негибкий, заточен только под WP и только под MySQL;
7. CMS: виджеты можно настраивать для всех страниц сразу, выборочно никак нельзя;
8. низкое быстродействие: из-за навороченной системы фильтров и хуков в финале система получается тормозная и прожорливая;
9. разработчики не подозревали о существовании других временных зонах кроме UTC: в коде жёстко прописано date_default_timezone_set('UTC');

Изучаю RoR, в принципе нравится. Многие вещи сделаны классно но некоторые вещи вызвали у меня недоуменье:

- обязательный REST: контроллеры генерят код для HTML и для XML хотя их никто об этом не просит. Возможно это круто и обосновано, однако это приводит к избыточности в коде, и созданию функциональности, которая никогда не будет востреботвана.

- обязятельный JavaScript:удаление элементов происходим методом DELETE, хотя браузеры обычно этот метод не используют, поэтому, для вызова DELETE методов используется объект HttpRequest. Как следствие, в браузере обязательно должен быть включен JavaScript. Если JavaScript выключить стандарные методы удаления объектов перестают работать. Это - не гуд.

- избыточность в структуре проекта: методы генерации объектов создают сразу код на все случаи жизни... И что мне после этого удалять вновь созданные файлы если что то не нужно?

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

В качестве примера, создадим две странички:

slow.php

<?php
print 'START....';

sleep(10);

print 'DONE';

fast.php:

<?php

print 'START....';
print 'DONE';
 

как видим обе странички работают вместе просто прекрасно, пока одна страничка генерируется десять секунд вторая загружается почти мгновенно, теперь добавим в обе страницы работу с сессиям:

slow.php

<?php
session_start();
print 'START....';

if (!isset($_SESSION['counter'])){
    $_SESSION['counter'] = 0;
}
else {
    $_SESSION['counter']++;
}
sleep(10);

print 'DONE';

fast.php:

<?php
session_start();
print 'START....';

print isset($_SESSION['counter'])?$_SESSION['counter']:'none';

print 'DONE';
 

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

Одним из вариантов для решения подобной проблемы можно вызвать session_write_close(); перед заведомо медленной процедурой. В этом случае сессия будет закрыта досрочно и блокировка с файла будет снята, правда изменять какие либо значения в сессионных переменных уже не получится.

Финальный вариант slow.php:

<?php
session_start();
print 'START....';

if (!isset($_SESSION['counter'])){
    $_SESSION['counter'] = 0;
}
else {
    $_SESSION['counter']++;
}

session_write_close();
sleep(10);

print 'DONE';

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

Upd: Кроме этого, если после долгой операции нужно еще что нибудь поменять можно перед долгой операцией сначала закрыть сессию при помощи session_write_close() а потом её снова открыть при помощи session_start(). Однако, делать это можно только если вы ничего ещё не начали выводить в поток, иначе будет известный Warning: Headers already sent....

Имеется InnoDB табличка, небольшая - меньше миллиона записей, делаем такой запрос (нужно получить top10 доменов):
> select dlvDestinationDomain, count(*) from email_accounting where jobid="11837" group by dlvDestinationDomain order by count(*) desc limit 10

созданы следующие индексы:

Обнаружилась забавная вещь: некоторые индексы не только не ускоряют но и замедляют агрегатные запросы:

вообще без использования индексов:

mysql> select dlvDestinationDomain, count(*) from email_accounting IGNORE INDEX(dlvDestinationDomain_2, jobId_3, jobId, dlvDestinationDomain) where jobid="11837" group by dlvDestinationDomain order by count(*) desc limit 10;

3.09 секунды

используя индекс по jobId дает небольшой прирост производительности:

mysql> select dlvDestinationDomain, count(*) from email_accounting FORCE INDEX (jobId) where jobid="11837" group by dlvDestinationDomain order by count(*) desc limit 10;

2.13 секунд;

использование составного индекса по jobID и dlvDestinationDomain сделало все гораздо веселее:

mysql> select dlvDestinationDomain, count(*) from email_accounting FORCE INDEX (jobId_3) where jobid="11837" group by dlvDestinationDomain order by count(*) desc limit 10;

0.39 секунд;

ипользование ключа с полям в обратном порядке  (dlvDestinationDomain и jobID) работает гораздо хуже:

mysql> select dlvDestinationDomain, count(*) from email_accounting FORCE INDEX (dlvDestinationDomain_2) where jobid="11837" group by dlvDestinationDomain order by count(*) desc limit 10;

1.36 секунд;

А вот использование ключа только по dlvDestinationDomain заставляет MySQL думать почти две минуты:

mysql> select dlvDestinationDomain, count(*) from email_accounting FORCE INDEX (dlvDestinationDomain) where jobid="11837" group by dlvDestinationDomain order by count(*) desc limit 10;

1 минута 48 секунд;

Кстати, заметил, что использование jobid="11837" (jobid у меня текстовое) заметно прибавляет скорости против jobid=11837. Не зря в strict моде MySQL грязно ругается на такие преобразования, ох не зря...

Upd. Во всем оказались замешаны настройки InnoDB, если увеличить в my.cnf значение переменной innodb_buffer_pool_size то скорость выполнения агрегативного запроса с индексом по группируемому полю заметно возрастает и картина меняется на прямо противоположную.

Потребовалось обработать логи в которых дата хранилась примерно в таком формате 2010-12-03T18:34:33-0500. К сожалению в PHP нет толковой функции для преобразования строкового представления даты в timestamp. Как показала практика strtodate совершенно не учитывает последние четыре знака в строке которые она просто отбрасывет.

Пришлось парсерить строчку ручками и вот что получилось:

function covertdate($date){
	preg_match('/(\d{4})-(\d{2})-(\d{2})T(\d{2}):(\d{2}):(\d{2})([-+])(\d{2})(\d{2})/', $date,$res);
	list($d,$year,$month,$day,$hour,$minute,$second,$digit,$zonehours,$zoneminutes) = $res;
	
	$offset = ((int)($digit."1"))*($zonehours*3600+$zoneminutes*60);
	
	$timestamp = gmmktime($hour,$minute,$second,$month,$day,$year)-$offset;
	return $timestamp;
}

Мне никак дает покоя Google Charts...

Наиболее популярными библиотеками для построения графиков на сегодняшний день являются JPGraph и Google Charts. Решение от Google - замечательное, удобное, простое, графики очень симпатичные. Однако, все графики генерируются на чужом сервере (речь идет о графиках построенных через URL API). Пользователю разрешается создать ограниченное количество графиков а потом его могут забанить. Конечно, это количество большое, но меня немного смущает сама возможность быть забаненным из за превышения количества показов. Кроме того, сервер гугла я не контролирую и никто не может гарантировать, что этот сервис будет работать вечно, или что завтра на моих графиках не появится реклама, или внешний вид этих графиков не будет изменен на тот, который мне не нравится.

Между тем, задача сделать график на экране компьютера под силу школьнику освоившему курс информатики (мы такое, помню делали в старших классах). Так зачем же отдавать такие "сложные" вычисления серверу гугла?

JPGpaph дает возможность создавать графические изображения на своем сервере, но все равно это — графические изображения, со всеми присущими графическим изображениям ограничениями.

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

На сегодняшний день в вебе наиболее популярными являются несколько технологий - Adobe Flash, Microsoft Silverlight и Canvas/SVG/VML. Выбирая между Canvas и SVG я отдаю предпочтение последнему так как эта технология позволяет создавать по настоящему интерактивные эффекты и ближе к VML используемому в браузерах от Microsoft.

Используя ztools создал несколько компонентов для построения различных графиков и диаграмм:

Конечно, эти компоненты еще не совершенны, это даже не бета версия. Но уже лучше чем ничего. Главным отличием от аналогичных являются: открытость исходного кода, простота, и (надеюсь) удобство использования. Замечания, пожелания, багрепорты и фичреквесты приветствуются.

Для одного из проектов сделал вот такие вот часики. Они должны работать во всех популярных браузерах включая IE6+, FireFox, Safary, Opera. Для визуализации в Internet Explorer используется VML для других браузеров SVG.

Иногда бывает необходимо в какой либо функции находить какую либо информацию, сохраненную в MySQL табличке по её ID. При этом количество элементов в табличке может быть небольшим, а вот количество вызовов такой функции, наоборот большим. Каждый раз вызывать "select ... from" будет расточительно, вставить справочную табличку через JOIN не всегда возможно. Было бы логично сохранить где-либо все значения справочной таблички а потом брать по ключу (табличка как я уже сказал небольшая). Самое лучшее решение, которое я придумал на сегодня — это воспользоваться static переменным (их можно применять не в только для синглитонов)

static function getDocumentTypeName($type_id){
    static $cache;
    if (!isset($cache)){
        $cache = Db::selectAssoc("select type_id, type_name from doc_types");
    }
    return $cache[$type_id];
}

При этом переменныя $cache остается в области видимости самой функции, что очень удобно, заполняется она один единственный раз при первом вызове функции.