Сегодня мыслил про капчу...
Абстрактный конь в вакууме...

Предположим у нас есть некоторый код, генерирующий картинку.
Рассмотрим варианты сохранения валидного результата:

1) После генерации валидного результата, пишем его в сессию и генерируем картинку на его же основе.
2) После генерации валидного результата, пишем его в БД и генерируем картинку на его же основе.

Если я забыл еще какие-то классические варианты - дополните.

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

Напомню как происходит весь этот процесс:
1) Вываливается хтмл-страница.
2) Браузер найдя ссылку на картинку капчи ломится за ней, капча генерируется всегда, валидная сессия или запись в БД обновляется/добавляется всегда.
3) На следующей необходимой странице вся эта кухня валидируется, либо тащим из БД, либо из сессии.

Попытаемся заапгрейдить:
1) На известной странице генерируется валидный результат и пишется в сессию.
2) Вываливается хтмл-страница.
3) Браузер найдя ссылку на картинку капчи ломится за ней, предоставляя сессию с валидным результатом.
4) Картинка капчи генерируется только в том случае, если сессия имеется в наличии и не устарела, (на усмотрение разработчика).
5) На следующей необходимой странице вся эта кухня валидируется из сессии.

Так, что у нас тут получается?
Мы выносим всякие там рандомизаторы и сессии из скрипта капчи.
Все генерации и проверки идут только в контексте бизнес-логики.
Капча не рисуется лишний/каждый раз и не жрет ресурсы машинки.
Ну и естественно капча занимается только тем, чем ей положено - только лишь отрисовывает картинку.

Х.з., может я и прописные истины тут щас напечатал, пусть даже и так - главное прозрел, главное сам...

Да, без бутылки не разобратся

Не, ну если тебе наличие бутылки реально помогает в разбирании - я только за

1) неужели генерация картинки 150px/100px(+-), настолько тяжела для сервера?
2) я не понял что пишется в базу?
3) по поводу третьего варианта (из 5 пунктов) как то не логично где то генерить код, а потом его передавать на генерирование по нем капчи, код капчи и сама капча это одно целое, и логичнее вернуть куда либо (например в сессию) код который должны надо ввести с капчи сразу же при генерации капчи, код окромя того что генерит саму каритнку так же генерит набор который надо вывести на картинке. так впроде логичнее
4) все равно капчи придется генерить часто, хотя бы тот факт что некоторые капчи будут не читабельны а потому попросят обновить

Все рандомы на фоне его величества GD - детский лепет.
Вот и получится, что мы пытаемся оптимизировать цикл простоя ОС - вещь, конечно, полезная, но незаметная.

Интереснее было бы вообще отрисовывать капчу только при наличии необходимости в ней. Пример активного, но бесполезного поглощения ресурсов:
есть блог, для анонимных гостей комментарии с капчей. При посещении анонимами (ссылку на пост опубликовали где-то), каждому из них генерируется капча при прогрузке страницы. А вот сколько из посетителей в принципе пытались прокомментировать запись?

Пища для размышлений, ответа у меня нет.

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

А нельзя кеш задействовать? Хотя бы кешировать раз в минуту.
При первом запросе показывать каптчу из кеша, если неправильно набрал второй раз (ну или более, там настраиваемо под сложность каптчи, количество ботов желающих спамить на страницу) то пусть уже генерирует каптчу заново. Всеравно большая часть юзверов будет каптчу правильно набирать с 1 раза, если она адекватная.

upd. поправьте если несу ахинею, ночью не выспался потому сегодня это у меня наблюдается местами

Zuldek, такую капчу проще пройти, если высекут что она отдается многократно, то запросив ее N раз можно в конечном итоге суметь ее подобрать
просто запрашивая каждый раз под новым юзверем, и только потоп начиная ее вводить

Каким образом? Кеш 1 на всех. Запрашивает не только ваш бот или юзер но и другие юзеры постоянно. Следовательно вы никак не можете знать какая в данный момент каптча в кеше, потому что что другой юзер или псевдо-юзер мог ввести её неправильно и она обновится в кеше.
Если будем максимально быстро запрашивать её, да ещё с разных юзверей чтобы сделать подбор: вам 1 раз отдаст кеш, 2 (если был неправильный ввод) и более раз, например, отдаст другую каптчу сгенерированную и записаную в кэш. Кто сказал что это как-то привязано к тому, какой юзер её запрашивает?

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

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

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

продумывать надо... .

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

а на обычный сайтах капча только при регистрации.

Повесит событие на textarea, и если юзверь начал писать туда - подгрузить капчу.