Сардар

Логика изначально не правильная. Загрузить можно что угодно, но нужно запретить исполнение файла вашим сервером. На самом деле исполнение зловреда на сервере достаточно редкое явление, если только вы не любите подключать счетчики от третьих лиц к себе в страницы через include с левого URL и если вы не любите размещать загруженные файлы с файлами вашего движка в одном месте.

Также под статичные файлы желательно завести отдельный домен (желательно 2ого уровня) и не принимать файлы, content-type которых вы не сможете распознать (например по расширению). Это нужно не для вас, а для ваших посетителей. Тогда даже если вы пропустите <script src="/url/to/image.png">, то браузер при взгляде на заголовок Content-type = "image/png" не станет выполнять скрипт (убедитесь, что ваш сервер всегда высылает Content-type). Ну и наконец, если все пошло не так и скрипт все таки выполнился у клиента, то размещение на отдельной домене не позволит украсть куку с сессией. Впрочем позволит, если вы размещаете куки на *.domain.com, а статику на static.domain.com. Безопасность это вообще обширная тема.

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

Может стоит использовать persistent очередь, вроде RabbitMQ? Нет ограничений на размер сообщений и они сохраняются, пока не будут употреблены. При чем сообщение резервируется, пока worker выполняет задачу и либо удаляется из очереди при успешном завершении, либо возвращается в очередь, если worker по тихому умер.

Вас чем-то не устраивает

SELECT ... FROM posts p JOIN users u ON u.userid = p.userid

или, быть может, я не понял вопроса?

Трудно поверить, что в примере скрипт реальный. Если он делает много IO (файлы, выкачивает чего из сети), то вам нужен асинхронный сервер, возможно с memcached кешем. В случае PHP по моему не решаемо, тут только поднять как можно больше дешевых worker'ов. Но на каждый запрос, worker лочиться на IO и фактически бездействует все время.

Node.js уже советовали, но я бы посоветовал pyramid под gUnicorn:gevent, чере nginx. Асинхронный сервер позволяет запускать сколько угодно green threads, работающих кооперативно. Если кто лочиться на IO, то отдает процессор соседу. На каждый запрос новый green thread.

Повторяю, это все только если ваши скрипты блокирутся на IO или каким другим способом. Если задача CPU intensive, как в вашем примере, то вам просто надо настроить сервер, что бы он полностью использовал все ресурсы машины (может там один worker в pool'e). Также узнать, что у вас за сеть (может «сервер» на домашнем ADSL висит).

Сначала читаем этот топик: habrahabr.ru/blogs/sysadm/113928/
Затем ставим и используем: code.google.com/p/wkhtmltopdf/

Плюсы подхода: настоящий рендер. Использовал html2pdf, но он пытается рисовать HTML сам через reportlab'овскую либу (вроде pypdf тоже умеет). В итоге графических глюков очень много, потрепало не мало нервов дизайнеру.

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