это количество одновременных пользователей на сайте?
то что говорят xdebug+kcachegrind, может вообще ниочем существенном не сказать

меня интересуют вопросы
1. Как ведет себя база? т.е, большой ли слоулог, сколько в среднем запросов к базе на страницу? К примеру, сколько запросов на главной?
2. какое минимальное\максимальное время генерации страницы в дев-режиме с отключенным xdebug?
3. сколько памяти у вашего 8миядерного сервака?
4. сайт занимает весь сервер или еще есть на нем проекты?
5. какой у сайта суточный трафик?

хм... что то написать не получается... а ну тест... бла-бла-бла...

о! работает! лан, пофлудили и хватит. вчера не работало.
В общем, так:
1. слоулог пуст. вчера в нём что-то было но сегодня он пуст. может меньше памяти забито другим фуфлом. например, вчера у меня висели 2 приостановленных процесса mencoder'a - думаю, они отжирали хорошо.
2. если бы дело было в запросах - ложился бы винт, простаивал проц на i/o-wait и php-cgi (или apache-mod-php) фигурировали бы в списке процессов как не особо тяжелые. А здесь проц жрёт именно php, а винт не загружен - значит, и обращений к базе немного. От каждого открытого окна раз в секунду гоняются около 5-10 запросов к серверной части. раньше каждый из этих запросов плодил на серваке 5 обращений к базе. Теперь эти 5 засунули в 1 запрос. Насколько я понял, результата это особого не дало.
3. тестирую на своём компе под линухой, загрузка от 3-5 процессов по 15-45% от ядра каждый до 90% на одно ядро, в зависимости от того, сколько процессов php-cgi плодится. ядра у меня два, памяти 1 гиг. apc.stat пробовал и вкл и выкл - без разницы.
4. на серваке стоит nginx.
5. памяти на серваке 12 гигов.
6. на серваке кроме этого сайта больше ничего нет.
7. сейчас кроме того что слоулог пуст, ещё и apc не ложит тачку. но прироста производительности по процу ноль. прирост по памяти если и есть - он меня не интересует вобще. Зато обращение к винту при генерации страницы - звиздец полный. вроде как меньше загрузка проца но это всё из-за i/o-wait.
8. wireshark'ом смотрел, сколько запросов на аяксе гоняют аналогичные сайты конкурентов - в несколько раз больше. Клиентов у них уже давно дофига и вряд ли мощнее железо.
9. время генерации страницы пока посмотреть не могу, руки не доходят. Временно забил на оптимизацию и занимаюсь изучением самой симфонии.

В общем, вопрос можно конкретно округлить:
"Копать в сторону проекта или в сторону симфонии?"
Много просто сообщений о проблемах с производительностью конкретно версии 1.2. Если бы не этот факт, вопрос бы и не поднимался.

Просто настройки базы для dev-режима другие. а я в симфонии не очень разбираюсь. Но уже сделал. Время генерации - 780ms. Кстати, в дев-режиме нагрузка в 2-3 раза меньше. Это нормально или мы близимся к разгадке? Она всё равно велика - 40-60 процентов одно ядро. Сервак-то помощнее моего ноута, но всё равно получится что он выдержит, скажем, не 100 клиентов, а 200... Мало. В последствии вероятно буду переписывать всё на 1.4. Но пока необходимо стартонуть чтобы было что кушать в время переписывания. Плюс не получилось обновить до 1.3. Каких-то файлов не хватало *.class.php.

Ага, с приростом производительности отбой - это просто xdebug отключен

ой, ой, вы включили xdebug на продакшыне чтоли?
отключайте срочно

на моем сервере 4 проекта с сумарным трафиком в 20000 в сутки и 400-800 одновременных пользователей на сайте

время генерации 120-600 мс

оптимизированы частично

так что вероятность того что лагает не симфа как фреймворк а сам проект достаточно велика

Пробуйте отключить кеш роутов совсем. У нас падала система из-за разрастания кеша.
factories.ym:

all:
  routing:
    class: sfPatternRouting
    param:
      cache: null