Пользуясь небольшим перерывом в эти новогодние каникулы сделал небольшую программку, рисующую жопу множество Мандельброта. Работает, к сожалению, медленнее чем версия на С++, зато картинка получается отменной.

Понадобилось посчитать дистанцию между двумя точками заданными в GPS координатах. В PHP реализация такой фунции выглядит следующим образом:

function calcMiles ($Lat1, $Lon1, $Lat2, $Lon2){
    return 3958.75 * acos(  sin($Lat1/57.2958) * sin($Lat2/57.2958) + cos($Lat1/57.2958) * cos($Lat2/57.2958) * cos($Lon2/57.2958 - $Lon1/57.2958));
}

Ответ получается в милях, для перевода в метры, полученное значение нужно ещё умножить на 1609.344.

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

Выходные провёл с пользой - сделал ещё один простейший текстовый редактор, на этот раз под Андроид. Конечно, уже существует огромное множество готовых редакторов, но мне захотелось создать свой, ведь лучший способ научиться что-либо делать — делать самому. Собственно, идея сделать текстовый редактор появилась после того как я снёс с телефона Ted - работает весьма странно, иногда ни с того ни с сего портит кодировку файла а при сохранении постоянно спрашивает имя сохраняемого файла - это меня сильно достало, ведь сохраняюсь я постоянно, хотя, в целом ted — не плохой редактор.

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

Большое спасибо Александру Понамарёву за классный диалог выбора файлов, без него у меня бы ушло гораздо больше времени.

Ссылка на apk файл.

Я уже писал, что нужно сделать, чтобы заменить в коде Posix регулярные выражения, которые в PHP 5.3 стали deprecated, на Perl совместимые. Оказывается Rerl совместимые регулярные выражения поддерживают литералы используемые в Posix такие как [[:allnum:]], [[:space:]] и т.д. В одном месте чужёго кода заметил это, и вот дошли руки проверить на практике: конструкция вида preg_match('/[[:space:]]/','df d') работает идентично конструкции вида preg_match('/\s/','df d') т.е. совсем не нужно при замене ereg на preg_match заменять еще и литералы, достаточно добавить слева и справа слеши "/". Кстати кроме слешей можно использовать любой другой символ, например "#" это полезно когда в регулярном выражении уже есть слеши - чтобы их не экранировать и не ухудшать читаемость кода.

Вызов статических методов классов — прекрасная альтернатива обычным функциям - и класс создавать не нужно и принципы объектно-ориентированного программирования не нарушаются. Однако, в реализации статических методов в 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 то скорость выполнения агрегативного запроса с индексом по группируемому полю заметно возрастает и картина меняется на прямо противоположную.