Не думаю, что Catalyst будет мешать:) Насколько мне известно, такие "слабопосещаемые" сайты, как www.vox.com и www.mightyv.com работают на Catalyst.
Вопрос такой - что для тебя большие нагрузки?

Как раз наоборот, хороший фреймворк очень полезен для масштабируемости, потому что облегчает оную :) , поскольку главная проблема в том что для классического подхода (не cloud computing) обычно нужно заранее делать приложение масштабируемо, а использование хорошего фреймворка это дает почти автоматически.
А если даже приложение не оказывается достаточно масштабируемым автоматически, хороший фреймворк заставляет писать так, что потом легко изменить.

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

Конкретно если уже отделена динамика от статики, это уже очень хорошо, и вобщем дальше скорей всего бутылочным горлом будет БД, но масштабирование БД это уже отдельная тема.

Спасибо за комменты. А какие существуют бюджетные методы балансировки нагрузки на бд, кроме репликации данных ?

в одной из старых документаций по репликации данных в мускуле говорится:

что это за агенты такие ?

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

Зачастую люди начинают слишком переживать о масштабируемости, когда для этого нет повода. Я понимаю, нагрузка Рамблера - 10 000 запросов в секунду, тут есть над чем подумать. В обычных же проектах, которых большинство, вопрос масштабируемости, как таковой, не стоит. Может возникнуть проблема со скоростью работы базы данных - вот этому следует уделить больше внимания.
Первое и самое главное - писать нормальный код. Поясню. Общаюсь с людьми, они жалуются, что программа медленно работает. Проверил, таки да, медленно. Стал разбираться.
Суть скрипта - собрать статистику из базы данных(порядка 100 000 строк). Читаю код и понимаю, что это прямо Клондайк какой-то ошибок и ляпов. Показываю в коде:)

sub load_prop_data {
#Здесь они работают с забой данных
  my ($agent, $flag) = @_;
  #
  #Выполняет огромный select, как он был написан, это отдельная история:)
  #Набираем все данные в указатель на хеш
  unless(defined($flag)) {
     return $data;
  }else{
     #То-есть, если функция вызывается как load_prop_data('123', 1), она вернет количество записей
     return scalar(keys(%$data));
  }
}

Дальше - больше:)
куски кода из приложения

my $data = load_prop_data('123');
for(my $i = 0;$i < load_prop_data('123', 1);$i++) {
}

и таких вот забавных моментов по телу программы штук 5:) Вопрос - почему все медленно работает:)))?
Путем некоторых оптимизаций я заставил программу бегать раз в 6 быстрее.
Какие можно сделать выводы? Не нужно строить RAID, чтобы получить ускорение в своей программе, лучше изначально правильно писать код. Хотя бы многие просто купили новое железо(интересно, почему Win32 такой "шустрый":)?)

Идем дальше. Правильно используй индексы. Делай их не только для того, чтобы они были по факту, а так, чтобы твои запросы эти самые индексы использовали. Как это делается в MySQL подсказать не смогу, ибо я его не знаю, но совершенно уверен, что посмотреть план запроса можно даже там.
Еще один пример ошибок(уже моих:)). Была база, не самая маленькая, порядка 20 000 000 записей. При старте приложения ему на вход подавались порядка 4000 записей, для каждой их которых делалось

SELECT * FROM my_table WHERE id=ID_записи
--обработка на стороне программы
UPDATE my_table SET=..... WHERE id=ID_записи

процесс старта(прохождения этой операции обновления был драматически долог, порядка 10-15 минут). Я уже придумывал совершенно извращенные варианты с распараллеливанием или нанятием 100 индусов, которые бы обновили 4000 записей при старте.
Хорошо, что я потом додумался проверить план запросов. К собственному стыду обнаружил, что забыл создать индекс:) После этого индусы отменились сами собой, загрузка происходит за 15 секунд максимум. Вот так, собственная забывчивость - и человек начинает ломать голову, как бы масштабировать:) Например, не 4000 записей, а 40 000:) На старом коде ждать пришлось бы ОЧЕНЬ долго.

Очень важно правильно спроектировать базу данных. Например, мой любимый PostgreSQL позволяет организовать data partitioning. Что это такое?
Предположим, у тебя есть большая таблица, где есть поле type. Поле type может принимать всего три значения. 'Дык', 'Опаньки', 'Cancel'. Используя средства СУБД можно организовать хранение данных так, что type 'Дык' будет физически расположен в одной таблице, 'Опаньки' в другой, ну и 'Cancel' в третьей. А твое приложение будет думать, что в одной:) Преимущества - снижается нагрузка на БД, запросы выполняются быстрее.

Еще один пункт - пулы соединений. Очень много времени тратиться на инициализацию самого подключения к БД, зачастую больше, чем исполняется сам запрос. Как решить? Использовать менеджер подключений, который будет выдавать линк к базе по требованию. При старте он сам откроет необходимое количество, а когда программа обращается к нему - выдает уже открытый, что позволяет не тратить драгоценное время. Время действительно экономится, я как-то не поленился и написал тест:) Готовых решений масса, лично я работал с SQLRelay.(http://sqlrelay.sourceforge.net/).

Удачи!

Ну ты наваял=) Спасибо за такой коммент развернутый.
Кодом убил наповал=)
На счет индексов.
Я работаю в области разработки уже давно, однако под веб, практически, не писал. Большая часть - различные автоматизированные приложения. Поэтому какую роль занимают индексы в проектирование схемы бд - знаю не по наслышке, а на горьком опыте=)
Сам несколько раз попадал в такую ситуацию, когда аццки хотелось все переписать к чертям, но, вспоминая про индексы, все становилось на свои места.

Ок. Спасибо всем за комменты. Более-менее разобрался, с чем хотел.