Чудо{вищные} заметки » web

Асинхронные задачи в PHP

MiRacLe — Sat, 16 Apr 2011 19:59:54 +0000

Не открою Америки, если скажу что порой требуется выполнить некую времязатратную операцию, результат которой либо не нужен пользователю вовсе (запись в лог, удаление временных файлов и другое обслуживание сервера), либо его можно обмануть и сказать что операция выполнена успешно, а саму операцию выполнить “попозже”. Самым наверное близким всем примером такой операции можно назвать отправку почты – smtp-cессия может длится довольно долго, особенно если письмо огромное, сервер тормозной (ну да вы сами всё знаете, в реальном мире великое множество острых углов), но зачем пользователю ждать результата? Что ему делать если результат неуспешный? “Попробуйте повторить операцию позже” ? Не смешно! Рядовой пользователь на ваш рядовой ресурс не вернётся, дотошный – свяжется с вами другими способами, так что можно с чистой совестью соврать ему – мол всё путём, всё отправлено, всё доставлено, записано и всё так успешно и идеально, а в это время потихоньку начать на самом деле выполнять задачу.

Конечно если вокруг вас крутятся тысячи серверов, слово “ынтырпрайз” для вас звучит буднично, то для вас уже изобретено много-много buzz-word-ных решений с очередями сообщений, очередями задач и другими полезными решениями, но львиная доля разработчиков всё-таки создают сайты-визитки, поддерживают сайты на хостинг-планах “всё по 20 рублей”, да и вообще на мой взгляд глупо для отправки почты окружать простейший php-скрипт кучей софта вроде gearmand + расширения для работы с ним. Я же хочу показать решение “для бедных”, простое, но удобное в разработке, поддержке и отладке решение.

Итак задача – отправить письмо, не заставляя ждать пользователя.
Имеем:

list($recipient,$subject,$body) = get_vars_from_request();
include 'superpupermailer.php';
$mailer = new SuperPuperMailer($recipient,$subject,$body);
if ($mailer->send()) {
echo "Аллилуя! Мы сделали это, храни нас Великий Байт.";
} else {
echo "О нет, это случилось!!! Быть того не может...но всё же случилось - приходи, милый друг, в другой раз, а сейчас ошибка!";
}

Тут всё понятно – либо отправилось, либо не отправилось – всем приходилось видеть это с разных сторон, те кто видел это со стороны браузера нередко наблюдали не только “ошибочка вышла”, но и другие подробности вроде конкретных строк в скриптах, warning-ов и Fatal error-ов. Но мы уже выяснили ранее – во-первых пользователю совершенно по барабану что у вас произошло с сервером, а во-вторых “пробовать ещё раз” он скорее всего не будет. Поэтому код можно изменить следующим образом:

list($recipient,$subject,$body) = get_vars_from_request();
$async_job = 'send();';
if (file_put_contents('/dir/for/jobs/email.php',$async_job)) {
echo "Ура! Мы сделали этот мир лучше!";
} else {
echo "Увы, мир жесток и безжалостен...";
}

Что это и зачем? Где отправка почты? Каким образом письмо отправится? Больше вопросов чем ответов. Опять-таки остался else, шило поменяли на мыло? В целом да – заменили тёплое мягким, но всё-таки нет – как часто у вас заканчивается неудачей запись на диск? Чаще чем таймаут при коннекте к почтовому серверу?

Теперь о главном – зачем файл? Где отправка почты?

Этим займётся другой скрипт:

if (true === include('/dir/for/jobs/email.php')) {
  unlink('/dir/for/jobs/email.php');
}

Осталось вызвать этот скрипт. Например так:

...
echo 'Ура! Мы сделали этот мир лучше!';
...

Или же добавим в cron задание на вызов job.php каждый час/пять минут/каждую минуту.

Всё. Мы не заставили пользователя ждать, мы отправили сообщение, мы молодцы. А если не отправили? Отправим потом – файл-то остался!

Конечно возникает много закономерных возражений – что будет если send.php (или job.php) будет вызван одновременно двумя пользователями?
Эти вопросы надо обстоятельно решать, задачи создавать с уникальными именами, блокировать одновременный запуск скрипта job.php, в общем работы аж на целых десять минут.

Самое интересное в конце:

...
$job_name = uniqid('mail_');
if (file_put_contents('/dir/for/jobs/'.$job_name.'.php',$async_job)) {
   echo "Ура! Мы сделали этот мир лучше!";
              $job_url = '/job.php?job='.$job_name;
              if (false !== ($fh = @fsockopen($_SERVER['SERVER_ADDR'], $_SERVER['SERVER_PORT'],
    $errno, $errstr, 0.01))) {
                  fputs($fh,
                      "GET $job_url HTTP/1.0\r\n"
                          . "Host: {$_SERVER['HTTP_HOST']}\r\n\r\n"
                  );
                  fgets($fh,32);
                  fclose($fh);
              }

} else {
   echo "Увы, мир жесток и безжалостен...";
}

Что здесь происходит? Мы создали php-файл, при выполнении которого отправится письмо, затем подключились к веб-серверу и запросили скрипт job.php, передав ему параметром имя только что созданного файла. И тут же отключились – ведь нам не важен результат, мы уже солгали пользователю о том, что операция завершилась успешно. На всё-про всё потратили доли секунды. Дальше уже дело техники – job.php захватит lock-файл, проверить наличие файла, имя которого ему передали, выполнит его, удалит в случае успеха, а затем отпустит lock-файл. Конечно надо не забывать, что скрипт может по каким-то причинам не выполнится (почтовый сервер недоступен, или ответит ошибкой, да и мало ли какие напасти происходят в реальности), поэтому следует вызывать job.php ещё и ещё, но пользователя это уже не должно волновать – у вас его письмо сохранилось и вы его доставите, он вам верит!

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

Решения и их последствия.

MiRacLe — Sat, 16 Apr 2011 11:28:36 +0000

Разрабатывать продукт в недра которого может влезть “чужой” непросто. Мы придумываем всяческие “неймспейсы”, давая файлам, директориям, переменным и классам псевдо-уникальные префиксы, пытаясь предотвратить коллизии с чужеродной средой.

Однажды, много лет назад, ко мне свалилась задача – размещение некой сложной формы на сторонних ресурсах. Очевидное и годами отработанное решение – iframe было забраковано, т.к. опыт и ~~пятая точка~~шестое чувство подсказывали – как только владелец сайта разместит форму у себя, его светлую голову немедленно посетит мысль – “а как мне приделать перламутровые пуговицы?!”. Это, признаться, пугало – целыми днями верстать и раскрашивать незнакомым дядям и тётям одну и ту же страницу пятью миллионами способов? Нет, пристрелите меня семеро! Второй способ – разработать и задокументировать API, чтобы владелец ресурса сам разрабатывал себе форму, был отвергнут как трудозатратный, но совершенно нежизнеспособный так как рядовой клиент как правило (тут могло бы быть нечто оскорбительное про уровень интеллекта и радиус кривизны передних конечностей, но цензура не пропустит) не готов своими силами что-то создавать, тогда как продукт конкурента был проще в освоении (работал из коробки). Был выбран третий путь – размещение формы в виде html-разметки, которую мы отдаём заказчику, что называется “в руки”, а данные подгружаем через , это позволяло владельцу ресурса до определённой степени контролировать внешний вид полученного документа и избавляло нас от трудозатратной кастомизации сотен инсталляций продукта. Но этот способ потенциально создавал много проблем, т.к. находясь в инородной среде наш документ мог “подхватить” незапланированные свойства, “заразится” чужими переменными и вообще рассыпаться в пыль в руках неуклюжего веб-мастера. Необходимо было тщательно изолировать всё и вся. Одним из способов отделить своё “добро” внутри документа было создание уникального “пространства имён”, например создание атрибутов в виде

– это самое rpz: давало надежду на то, что внешний скрипт(движок сайта или сам вебмастер) “случайно” не создаст аналогичный атрибут с другим value (или вовсе без него), развалив всю эту шаткую конструкцию. Решение оказалось рабочим во всех доступных графических браузерах и популяризировалось мной не только в этом продукте, но и повсеместно в других (печатая эти строки пытаюсь понять – зачем вообще нужны были именно атрибуты и почему их нельзя было заменить на переменные в скрипте, но разумного ответа почему-то не нахожу).

Это неоднозначное решение “выстрелило в ногу” только на днях – появился IE9… ~~Невероятно быстр, ангельски красив, дьявольски умён – блеск, а не браузер~~ ~~На вид такой же унылый как все предыдущие~~ В общем обзор новшеств можно наверное найти на сайте разработчиков, ну а я увидел его первый раз два дня назад, ничего ~~хорошего~~ про него сказать не могу, да и речь совсем не о том. Случись такое совпадение – сайт заказчика оказался настолько весь из себя валиден, что IE9 работал со страницей в своём новом document.documentMode. И чтобы вы думали? Точно! Годами отработанная “технология” дала сбой – “самодельные” атрибуты просто-напросто не видны на такой странице, а моя твёрдая уверенность в том, что они есть запретила здравому смыслу проверять их наличие… так и случаются epic fail-ы, так было и со мной.

Один грязный хак удалось временно залатать другим грязным хаком, но урок получен – недокументированная возможность это лишь “возможность”, строить на ней что-то прочное нельзя.

К слову сказать, не так давно вместо атрибута rpz:property="value", я начал использовать “документированную возможность” – атрибут data-rpz-property="value" и соответствующий вызов в js изменился с jQuery(selector).attr("rpz:property") на jQuery(selector).data("rpz-property") , видимо “шестое чувство” о чём-то подозревало…

jabber web status

MiRacLe — Sat, 20 Nov 2010 17:00:44 +0000

В поисках прикладной задачи для предметного изучения node.js вспомнил про заброшенный проектик – jabber web status.

И за несколько часов переписал на node. По сравнению с предыдущей версией написанной на PHP (XMPPHP) потребление памяти, а главное, нет ГЛАВНОЕ – потребление CPU снизилось до статистической погрешности (по непонятным причинам php-бот иногда забирает до 60% процессорного времени) . Скорость работы – отдельная, приятная на слух песня. Избавился от промежуточного хранилища (а значит и от лага в обновлении информации), в котором хранились статусы пользователей – скрипт не только работает с xmpp, но и сам раздаёт результат по http.

Работать с node ново и свежо. Удручает только то, что свежесть во всём – в библиотеках, в сборке, установке дополнительных модулей. Написание и отладка скриптика отняли от силы час, правка библиотек ещё два, установка node и модулей на сервере с дебильной Centos – целую вечность. Но всё-таки оно того стоит – писать на javascript легко и приятно, очень интересно использовать его вне привычных рамок браузера, асинхронность везде и во всём, интерпретатор, шустрый как электровеник, человеко-понятно ругается ошибками, неплохая документация к основным модулям. В общем хороший массаж не только для коры головного мозга, но и самой его древесины, изрядно дубеющих от PHP ;o)

jabber web-status

MiRacLe — Sat, 05 Dec 2009 18:35:53 +0000

В процессе работы над Секретным Проектом™ образовался побочный продукт, который возможно покажется кому-то полезным. Суть «продукта» – показать статус вашего jabber-аккаунта в вебе, как это делается например для icq.

Для работы требуется добавить себе в ростер контакт webstatus@rpz.name, после этого ваш статус будет доступен по следующим ссылкам:

http://webstatus.rpz.name/your@jabber.account – в виде html

http://webstatus.rpz.name/your@jabber.account/image – картинки 16×16 (взяты из стандартного набора psi)

http://webstatus.rpz.name/your@jabber.account/script – для тех, кто может себе позволить

http://webstatus.rpz.name/your@jabber.account/json

http://webstatus.rpz.name/your@jabber.account/json?callback=yourfunction

http://webstatus.rpz.name/your@jabber.account/xml

Сделано ~~как обычно~~ just for fun. Вы можете пользоваться этим сервисом как заблагорассудится, можете писать пожелания и комментарии, но не можете предъявлять претензии…

IE8 и currentStyle

MiRacLe — Fri, 20 Mar 2009 15:38:58 +0000

Новость одной строкой… Когда-то я рассказал как добавить border-spacing для IE используя свойство currentStyle.

Вчера, как многие знают, вышел IE8.Собственно на этом можно было бы многозначительно пост закончить…

В общем в IE8 более этот трюк не работает. В currentStyle не попадают неизвестные браузеру свойства. Изящного решения пока не нашёл – если уж пользовались им, то просто замените непонятные буквы в css на cellSpacing = <число> вместо вычислений, которые были раньше…

Update а вот переводная статья о других особенностях IE8

AJAX и проблемы с кодировкой

MiRacLe — Fri, 28 Nov 2008 10:50:30 +0000

Вот уже полтора года в draft-ах пылился пост о надуманности проблем с кодировками и т.н. AJAX-ом.
Каждый раз, когда на форумах всплывали вопросы подобного характера, хотелось дать ссылку, на всякий всплеск заходов на блог по запросам “кодировка, ajax, проблема” хотелось его опубликовать, но мне казалось, что пост ещё не закончен, надо ещё чуть-чуть дописать…
Но вот буквально сегодня появился удивительно похожий пост – ajax, cp1251. Похожий по содержанию, но совершенно противоположный по смыслу.
Посему свой черновичок я решил удалить, а поведать свою “истину” в форме критики совета fxposter-а.

Ни для кого ни секрет, что кодировкой получаемых через Ajax данных по-умолчанию принимается UTF-8.

На самом деле это секрет. Для многих секрет. И многие не понимают почему это так.
Внутреннее представление строк (и регулярных выражений) в JavaScript для всех не-ASCII последовательностей как раз UTF-8.
Отсюда и проистекает т.н. “проблема” – если кодировка не указана явно и используется нелатиница, она будет интерпретирована как utf-8 последовательность.

Update 29.11 Свежий воздух и Давид Мзареулян остудили пыл, поэтому спешу уточнить о чём именно будет идти речь ниже.
Итак – у вас есть некий ресурс в однобайтовой кодировке (к гадалке не ходи это будет windows-1251) и вы озаботились освоить новый buzzword по имени AJAX. Немного почитав, вы делаете первые робкие шаги в этом направлении и тут же наступаете на “детские грабли”, а затем, немного отдышавшись, мчитесь на форумы с криком о помощи. И вам эту помощь окажут – переделай мол, свой ресурс на utf-8… Конечно-конечно скажете вы и пойдёте переделывать…
Я же хочу остеречь от таких опрометчивых шагов.

Cтандартное решение, которое наперебой советуют все – “используй utf-8 и нет проблем”.

И советчики правы – проблем действительно не будет.

Просто трафик увеличится “вдвое”. Те же данные, тот же результат, а трафика “в два раза” больше. Ага?

Что вы там говорите насчёт порошка?!?

Если вам этот фактор кажется мало***щим, то на этом чтение надо прекратить и начать переделывать свой проект на использование UTF-X,
остальным же оставлю несколько рецептов, которые помогут избежать проблем при использовании однобайтовых кодировок в т.н. AJAX-приложениях:

Первое, оно же главное – ВСЕГДА указывайте кодировку контента. В любом ответе сервера с текстовым контентом обязан быть заголовок Content-Type: your/type; charset=your-charset.
Дешевле всего это сделать, настроив сервер (например в php через default_charset)
Указывайте charset при включении javascript в тело документа (