Вот интересует такой вопрос:

сейчас уже везде почти много-ядерные процессоры.
Пишут ли под веб на перле именно с поддержкой много-ядерности, или уж сама технология веба это подразумевает?
Или же это должно быть реализовано на уровне компилятора?
Например fastcgi - они ж не отточены под многоядерные процессоры.

Веб-скрипты нет смысла писать многопоточными/многопроцессовыми, т.к. у любого нормальном динамическом сайте:
1. Много пользователей. И даже если мы говорим о мод_перл или фаст сиджиай - 
2. Много скриптов. Ну и на последок, если мы говорим о мод_перл + системой с единным сценарием:
3. Перл взаимодействует с несколькими сервисами/демонами - СуБД, мейл демон и т.д.

Скрипт должен отрабатывать быстро.
Поэтому распараллеливание - это бессмыслено, больше времени будет уходить на форки и синхронизацию.
Другое дело, что один и тот же скрипт зачастую обрабатывает несколько запросов одновременно.
Тогда каждый запрос - в своем потоке и процессе.

Например Apache - всегда запущено несколько процессов, 
Apache2 поддерживает многопоточность, поэтому один скрипт может работать параллельно.

потоки и процессы операционка раскидывает по процессорам.

вывод: не парься! =)
P.S. если только сам не задумал веб-сервер писать

Просто тогда чтобы писать быстрые приложения под веб 
например Java те же JSP  будет быстрее за счет многоядерного процессора, ведь даже уже при соединении с мускулем, а оно там всего идет один раз а не кучу висящих коннектов к бд (фастцги).

Неужели придеться смотреть в сторону явы?

Ты не понял:
многопоточность и многопроцессорность УЖЕ поддерживаются!
На уровне apache + OS.
тебе при написании скриптов даже думать об этом не прийдется, твои скрипты и так будут использовать все ядра (если конечно apache + OS нормально настроены)

Другое дело, что java действительно несколько быстрее чем perl. 
Именно платформа - т.е. JVM работает чуток эффективней perl,
Но это не повод переходить на java.
Как показывает опыт тормоза в 90 % случаях - из-за алгоритмов, а не из-за
используемого языка.

По поводу соединений с DB.. 
Да в web серверах написанных на java это сделано немного прозрачнее,
но и в perl не все так плохо - есть Apache::DBI и Apache::DBI::Cache, 
которые делают приблизительно тоже самое.

Мне кажется, они не умеют разделять подключения между потоками, что конечно плохо.. 
число подключений будет равно числу потоков. В j2ee подключений меньше. 

собираюсь обсудить эту тему на форуме сейчас =)

sir_nuf_nuf, 
По поводу соединений с DB.. ... Мне кажется, они не умеют разделять подключения между потоками, что конечно плохо.. 
число подключений будет равно числу потоков

подключение к базе -- это очень затратное удовольствие, поэтому
всё делается гораздо проще -- при первом выполнении скрипта делается подключение и dbh пишется в shared memory, все остальные копии скриптов считывают этот dbh и работаю через него

если есть какой-то запрос, которые выполняется очень часто, то он делается параметризированным, т.е. dbh->prepare("запрос с параметрами;"), благодаря чему база парсит его только 1 раз, а потом только постоянно выпоняет с разными условиями, а в дальнейшем вызывается только execute("$param1, $param2, ...");

ЗЫ для mysql prepare() & Co давно есть, для постгреса написаны недавно, если в Вашем дистрибутиве этого еще нет, советую обновить DBD-Pg, в нем было очень много доработок

я в курсе как это прибризительно работает. меня интересуют детали.

как то - что такое "shared memory"  ?

Это POSIX shared memory ?
или это просто аресное простанство процесса, которое по умолчанию разделено междк потоками ?
или это разделяемая память на уровне perl ? в котором вообще говоря память (perlовая) не разделяется между потоками .
или это особенность mod_perl ?

vadiml, есть еще один вопрос: как потоки используя одно соединение с базой будут использовать транзакции?

sir_nuf_nuf, 
что такое "shared memory"  ? Это POSIX shared memory ?
это я по привычке с С  назвал, вот:
"memcached is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load" http://www.danga.com/memcached/
думаю в http://search.cpan.org/~bradfitz/Cache-Mem...he/Memcached.pm написано достаточно 
и ссылки есть
так же есть есть куча подмодулей, но я их не смотрел -- не понадобились
ЗЫ я вообще редко для web'а пишу, 

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

это фича mod_perl и апача. пул коннектов к бд или чего угодно можно реализовать, на базе apache + mod_perl
вот тут у меня была похожая задача: http://forum.vingrad.ru/topic-166437.html только мне нужен был пул конектов к телнету, но чтобы общий на всех воркеров апача.

советую глянуть доки на модперл и директивы PerlRequire в апаче. Суть в общих чертах том, что у апача всегда есть мастер-процесс, который сам запросы не обрабатывает а только управляет пулом воркеров, так вот свой код можно инициализировать в этом процессе. Но при этом все потомки имеют доступ к этм данным. самый натуральный shared memory получается....

но почему это так работает, мне никто объяснить не смог =)

Это сообщение отредактировал(а) Ramirez - 31.3.2008, 11:52

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

Поскольку больше люблю fastcgi а не mod_perl то приходиться выкручиваться по другому.


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

Добавлено через 57 секунд



это нужно вызывать prepare_cached

Это невозможно, т.к. DBI реализован с помощью XS. См. тут.

и на чем вы остановились в итоге?

на чем мы остановились с чем ?
как использовать соединения с базой?

У нас так - каждый скрипт работает в своем процессе (не в потоке).
Каждый процесс держит постоянно соединение с базой данных.

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