Если процессы запускаются на одной машине — то самый простой вариант реализации мьютекса — flock. Проверяем — можем ли получить lock — остальное за нас сделает *nix.
HS во всю используется уже в Badoo. Не буду пересказывать выступление Аверина — обращайтесь к первоисточнику — там и про про подводные камни и кратко мануал — слайды с конференции
И кстати совсем недавно, был обещан код клиента.
Есть вариант с iframe, туда можно вставить форму и отправить POST, единственно что бы прочитать ответ с чужого домена, нужно еще пару телодвижений — я обходился редиректом на favicon с GET, на свой домен. После этого браузер разрешает прочитать URL фрейма, и получить результат. На тот момент решение работало в IE, FF, Chrome, Opera — правда для оперы были небольшие особенности в реализации.
Естественно для ответа есть ограничения по длине, но ели запаковать еще JSON данные, то для обычных задач должно хватить. В крайнем случае спасут два запроса, iframe (шлем сколько хотим, читаем ограниченно по длине URL) и JSONP (шлем ограниченно, читаем сколько хотим).
Только не стоит засыпать (sleep) при генерации капчи, а то только усугубим ситуацию, собственноручно приложив участия в достижения лимита одновременно работающих обработчиков веб-сервера.
Сохраняйте на стороне сервера, в какое время капча может быть получена в момент генерации страницы. А у клиента скрипт с задержкой на загрузку капчи на нужное нам количество секунд. Далее если запрос пришел на капчу раньше времени — просто выкидываем мусор, ибо это точно робот.
Еще пару слов в пользу XSLT. Долгое время работал с системой, использующей для отображения XSLT. Не стоит бояться о скорости ее работы. Все работало с хорошим быстродействием – а это была сотни 2 магазинов на одной обычной машинке (P4, 1Gb, IDE), по посещаемости весьма приблизительно – по 200 хостов на сайт в день.
Все зависит от того как построить систему. Если генерировать каждую страницу на запрос, к тому же каждый раз для этого строить немаленькую XML – то естественно будут проблемы с производительностью.
Но если хорошо построен механизм кэширования. Как на уже сформированный HTML, к примеру, так еще и кэшировать XML для отдельных объектов, с которых потом быстро можно собрать XML для страницы. Нагрузка на подсистему генерации страниц будет небольшая.
При этом получаем удобство XSLT. Например, подумайте как бы вы реализовали вывод названия товаров на странице, отсортированных по алфавиту, из списка товаров на странице. В XSLT – пара строчек, а на том же Smarty без дописывания кода на PHP уже не обойдетесь.
И еще один момент – вы можете позволить менять шаблоны кому угодно, и он не сможет что-либо испортить в системе, получить доступ к коду той же CMS (что удобно, если вы не хотите открывать ее код).
Есть вариант вращения объектов, состоящих из треугольников (делаются они div-ами с бордюром).
Как это делается - http://www.uselesspickles.com/triangles/demo.html
А вот парочку интересных демок:
http://www.tapper-ware.net/canvas3d/
http://www.abrahamjoffe.com.au/ben/canvascape/
После постоянных проблемм с американскими и руссики хостерами, перешел на европейский http://eurovps.com/.
Скорость хорошая, пока в падениях замечен не был. Суппорт нормально реагирует на обращение, исправляет, дает решения, хоть и не моментально, в среднем в течении получаса.
И кстати совсем недавно, был обещан код клиента.
Есть вариант с iframe, туда можно вставить форму и отправить POST, единственно что бы прочитать ответ с чужого домена, нужно еще пару телодвижений — я обходился редиректом на favicon с GET, на свой домен. После этого браузер разрешает прочитать URL фрейма, и получить результат. На тот момент решение работало в IE, FF, Chrome, Opera — правда для оперы были небольшие особенности в реализации.
Естественно для ответа есть ограничения по длине, но ели запаковать еще JSON данные, то для обычных задач должно хватить. В крайнем случае спасут два запроса, iframe (шлем сколько хотим, читаем ограниченно по длине URL) и JSONP (шлем ограниченно, читаем сколько хотим).
Сохраняйте на стороне сервера, в какое время капча может быть получена в момент генерации страницы. А у клиента скрипт с задержкой на загрузку капчи на нужное нам количество секунд. Далее если запрос пришел на капчу раньше времени — просто выкидываем мусор, ибо это точно робот.
Все зависит от того как построить систему. Если генерировать каждую страницу на запрос, к тому же каждый раз для этого строить немаленькую XML – то естественно будут проблемы с производительностью.
Но если хорошо построен механизм кэширования. Как на уже сформированный HTML, к примеру, так еще и кэшировать XML для отдельных объектов, с которых потом быстро можно собрать XML для страницы. Нагрузка на подсистему генерации страниц будет небольшая.
При этом получаем удобство XSLT. Например, подумайте как бы вы реализовали вывод названия товаров на странице, отсортированных по алфавиту, из списка товаров на странице. В XSLT – пара строчек, а на том же Smarty без дописывания кода на PHP уже не обойдетесь.
И еще один момент – вы можете позволить менять шаблоны кому угодно, и он не сможет что-либо испортить в системе, получить доступ к коду той же CMS (что удобно, если вы не хотите открывать ее код).
Как это делается - http://www.uselesspickles.com/triangles/demo.html
А вот парочку интересных демок:
http://www.tapper-ware.net/canvas3d/
http://www.abrahamjoffe.com.au/ben/canvascape/
svn export project build/project -r from:to
Скорость хорошая, пока в падениях замечен не был. Суппорт нормально реагирует на обращение, исправляет, дает решения, хоть и не моментально, в среднем в течении получаса.