Конечно если вокруг вас крутятся тысячи серверов, слово “ынтырпрайз” для вас звучит буднично, то для вас уже изобретено много-много 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 ещё и ещё, но пользователя это уже не должно волновать – у вас его письмо сохранилось и вы его доставите, он вам верит!

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

Был приятно удивлён скорой реакцией на запрос – приветливый support попытался мне помочь, а затем мы выяснили, что данный функционал ещё в пути и пока не готов. В связи с чем хочу выразить благодарность читателю за то, что он зайдёт на трекер к разработчикам и проголосует за эти фичи: #WI-4323 и #WI-4466 и отдельные “спасибы” раздать Сергею Баранову и Николаю Матвееву за скорую и адекватную помощь и снисхождение к русскоязычной аудитории пользователей.

P.S.

Если вы понятия не имеете о чём идёт речь, но разрабатываете на PHP, вы просто обязаны попробовать PhpStorm в деле – скачать eap-релиз можно на сайте разработчиков.

Собственно все внутренности состоят из библиотеки XMPPHP и маленького скриптика, который вешается на post-commit.
Сам скриптик настолько маленький и бесхитростный, что комментировать его не вижу смысла – кладу как есть.
Для функционирования нужно иметь xmpphp в include_path, бинарник svn в PATH и добавить post-commit hook в ваш репозитарий.

В сложнейшем, виндовом случае это будет post-commit.cmd, который лежит в директории hooks репозитария и имеет следующее содержание:

/path/to/php.exe /path/to/svnjabber.php %1 %2

В рамках работ по выводу одного “неповоротливого асфальтоукладчика” на земную орбиту были проведены ряд его модернизаций. Испытания на тестовом полигоне показали что машина стала ездить на порядок быстрее и было решено доработки включить в работающий прототип(вроде и не первая космическая, но уже есть чем гордиться!). Но на первом же серьёзном показе зверь-машина с чудо{вищным} грохотом рассыпалась у всех на глазах и я сел в лужу…

А теперь тоже самое, но по-русски, с выражением.
Имеются ряд весьма тяжёлых для веба запросов к БД, результат которых условно не меняется в течении небольшого промежутка времени. Кеширование промежуточных результатов в самой БД нагрузку сняло на СУБД, но скрипты продолжали исправно тягать данные и это порой занимало внушительное время. Было решено результаты эти кешировать на стороне веб-сервера. Как хранилище был использован apc.

Первоначальный вариант выглядел примерно так:

if (!$data = cache_get($key)) {
   $data = data_from_db();
   cache_set($key,$data,$expire_time)
}

Без излишеств, просто и со вкусом. Но позже выснилось что “всё не так просто” и в зависимости от некоторых космических характеристик и результатов выборки из базы будет меняется ещё одна переменная (меняется переменная… ого!).

if (!$data = cache_get($key)) {
   $data = data_from_db();
   cache_set($key,$data,$expire_time);
   $other_data = some_function($data,$env);
   cache_set($other_key,$other_data,$expire_time);
} else {
   $other_data = cache_get($other_key);
}

Аляповато, но, чёрт возьми, работает…
Работало…
Должно было по идее работать…
Но, почему-то оказавшись на боевом, изрядно нагруженном, сервере это не сработало. Вернее это работало…, но не всё время… По истечении $expire_time периодически пропадали данные для $other_key. При отключении и/или очистке кеша работоспособность восстанавливалась… Кто виноват? Что делать? Кто за всё это ответит?!? Пришлось срочно пошевелить опилками.

Как мы все наверное догадываемся – реальный сервер обслуживает нереально много клиентов, причём не по очереди. И нет совершенно никаких гарантий на то, что между записью $key и $other_key не встрянет какой-либо маленький, но шустрый процесс (хотя нам это и не особо страшно), так же нет никаких оснований полагать что между выборкой $key и $other_key кто-то умный и большой не очистит кеш (целиком, или только $other_key – в данном эпизоде это не имеет значения).
Оснований не было, но я был почему-то твёрдо уверен, что “это если и происходит, то с кем-то другим”. С пониманием проблемы конечно же пришло и простое решение, но ошибка, согласитесь, совсем не тривиальная.

Так что мораль сей басни: помни – ты не один!

Собственно делается всё очень просто. Для того чтобы в консоли firebug-а появилось сообщение, необходимо написать js-код:

console.log('сообщение');
console.group('разные типы сообщений');
console.info('к вашему сведению, мы тут логи пишем...');
console.warn('предупреждаем о разном');
console.error('и информируем об ошибках!!!');
console.groupEnd();
console.dir({сложная: {структура: [1,2,3]}});

Подробнее о возможностях консоли firebug-а можно узнать в документации.

Дело за малым – сформировать эти строки на вашей серверной платформе.
Сложность представляет лишь последнее – json-упаковка сложных структур, но и она уже во многих платформах решена. Сам я пользуюсь функцией, описанной в коментариях к json_encode, т.к. родная слишком консервативна в вопросах кодировок(по стандарту в json можно упаковать только уникод, но браузеры более лояльны нежели писатели стандартов).

Собственно теперь чем это лучше всяких принтов и вар_дампов?
Тем, что не меняют визуально документ, что существенно в современных сложных веб-приложениях.
К тому же это в разы удобнее – все сообщения в одном месте, красиво представлены…

В заключение скажу о якобы готовых решениях для PHP:
Log::Firebug из PEAR – драйвер для довольно распространнённого pear::log
FirePHP – более комплексное решение, плагин к firebug-у и обёртка к серверному коду.

Я ни тем, ни другим не пользуюсь, т.к. первое сделано левой ногой, а второе заворачивает оригинальный документ в страшную multipart-кашу…

<?php
  var_dump(round(-0.1));
?>

Update: во какую штуку нашёл, надо бы донести это знание до тех, кому не безразлично…

В распоряжении имеется:

1. svn-репозитарий с проектом.
2. ftp-доступ к рабочему серверу.
3. установленный и готовый к тяжёлой рутине phing

Сценарий работ следующий:

1. Сделать экспорт кода из svn
2. Подготовить его к загрузке (например убрать комментарии, “склеить” мелкие в один большой, удалить лишнее и т.п.)
3. Проверить на наличие ошибок (они могли попасть в репозитарий или образоваться на предыдущем шаге)
4. Закачать полученное на рабочий сервер.

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

1. Получить последнюю версию проекта на сервере – RevFrom
2. Получить последнюю версию проекта в репозитарии – RevTo
3. Экспортировать файлы, которые изменились или добавились c RevFrom до RevTo

Версию рабочего проекта, не мудрствуя лукаво, предлагаю хранить в текстовом файле. Например revision.txt. Версию проекта в репозитарии поможет узнать SvnLastRevisionTask. Неясным остался лишь момент – каким образом выяснить какие файлы изменились. Те, кто пользовались TortoiseSVN наверняка знают о чудесной его возможности – сравнить две ревизии и экспортировать “разницу”. Но svn в чистом виде такой возможности не предоставляет. Так что пришлось немного поработать.

Результатом работы стал класс – SvnExportRevisionDiffTask Принцип его работы таков: получаю список файлов для каждой ревизии в виде xml, потом эти списки сравниваются на предмет изменившихся или добавленных файлов. Список получается путём вызова svn, т.к. более удобного способа не нашлось.

Закачивать файлы будем посредством task-а, который я опубликовал ранее – FtpUploadTask.

Ну вот все вроде бы в сборе и можно приступать с сборке: раскладываем php-классы в соответствующие места, берём файл example.xml

<?xml version='1.0'?>
<project name='Deploy' default='build' basedir='./' description='Demo phing-ftp-deploy'>    
        <target name='propset'>        
        <property name='projectUrl' value='http://example.com/project_root/' />
        <property name='revisionFile' value='revision.txt' />
        <projectlastrev url='${projectUrl}' revisionFile='${revisionFile}' propertyName='fromrev' />      
        <property name='svnroot' value='http://svn.example.com/project/branches/stable/' />
        <property name='svnuser' value='joe' />
        <property name='svnpassword' value='s3cre7' />
        <property name='outputdir' value='project-temp' />
        <svnlastrevision username='${svnuser}' password='${svnpassword}' repositoryurl='${svnroot}' propertyName='torev' />
        <property name='hostname' value='ftp.example.com' />
        <property name='user' value='ftpuser@example.com' />
        <property name='passwd' value='s3cr3tk3y' />
        <property name='dstdir' value='project_root' />
        <property name='overwrite' value='true' />
    </target>
    <target name='build' depends='propset,diff,lint'>   
        <ftpupload host='${hostname}' username='${user}' password='${passwd}' targetDir='${dstdir}' mode='bin' overwriteExisten='${overwrite}'>
            <fileset dir='${outputdir}'>
                <include name='**' />
                <exclude name='config.php.dist' />
                <exclude name='examples/**' />
            </fileset>
        </ftpupload>
    </target>    
    <target name='diff' depends='propset'>
         <delete includeemptydirs='true'>
            <!-- сначала очистить директорию, в которую будут экспортироваться файлы -->
            <fileset dir='.'>
                <include name='${outputdir}/**' />
            </fileset>
         </delete>
         <mkdir dir='${outputdir}' />
         <!-- сохранить номер текущей ревизии в файл -->
         <echo file='${outputdir}/${revisionFile}' message='${torev}' />
         <!-- экспортировать нужные файлы -->
         <svndiff toDir='${outputdir}' svnpath='/usr/local/subversion/bin/svn' fromRevision='${fromrev}' toRevision='${torev}' force='true' username='${svnuser}' password='${svnpassword}' repositoryurl='${svnroot}' />
    </target>
    <target name='lint'>
        <phplint haltOnFailure='true'>
            <fileset dir='${outputdir}'>
                <include name='**/*.php'/>
                <!-- файлы в pear::php_compat проверять в php5 не надо -->
                <exclude name='**/Php/Compat/**/*.php' />
            </fileset>        
        </phplint>
        <jslint haltOnFailure='true'>
            <fileset dir='${outputdir}'>
                <include name='**/*.js'/>
            </fileset>        
        </jslint>
    </target>
</project>

Открываем консоль, набираем phing -f example.xml и смотрим как вашу работу выполняет за вас бездушная машина…

Кстати говоря, эту задачу можно запускать не только вручную, но и например с помощью post-commit hook-а на репозитарии…

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

Ну и краткое руководство:

1. Поместите скрипт куда-нибудь (пусть это будет /usr/bin/sendmail например, а реальный бинарник переименуйте в /usr/bin/sendmail.real)
2. Отредактируете пути в скрипте (если вы выбрали их другими)
3. Укажите путь к скрипту в директиве sendmail_path вашего php.ini (если отличается от указанных мною)
4. Ждите вестей…

P.S.
Вы без труда сможете добавить простейшие “фильтры” и не отправлять например письма содержащие некие сигнатуры…

Предупреждаю – пустые строки вовсе не пустые! Говорят это ошибка в либе, хотя и воспроизводиться и в win и в *nix (т.е. либы разные). Написал разработчику – а вдруг поможет.

А пока имейте ввиду – если в resultset могут быть пустые строки – надо их сделать таковыми самостоятельно (примерно так: $row["field"] = ($row["field"] != " ") ? $row["field"] : "";) – разумеется, если у вас за каким-то лесом в базе храняться одиночные пробелы, вам очень не повезло ;o)