Ага, интересная ситуация, когда в отдельных точках, проверяемых наугад, проблем нет, а в целом проблема есть.
Наверно, самое время для более подробного описания конфигурации используемого ПО и, вероятно, железа. Думается, есть смысл поглядеть за изменением загрузки CPU, использованием памяти и топом процессов во время теста.

gpbetatesting,

Про ПО, его архитектуру и конфигурацию расскажите?

Этот скриншот снят во время проблемного запуска? Тормоза ж при околонулевой нагрузке CPU. Либо сеть совсем дохлая (так понимаю, "урл дергается" по сети), либо дисковая подсистема никуда не торопится (мускулю периодически нужно ж сбрасывать данные на диск). Или, может быть, у вебсервера какое-то дурное ограничение на входящие подключения (тупо ставит http-запросы в очередь) но в таком случае секретная "дергалка" должна бы о неразумных таймаутах просигнализировать в логах, если это вообще логгируется.

gpbetatesting,

Ух... Ужас, сколько неучтенных и слабо контролируемых факторов.

Предлагаю во второй раз сузить область тестирования до PHP + MySQL. Локально. Запуск всех тестов исключительно из консоли сервера.

В качестве примера можете попробовать мои туповатые тесты с постов предыдущей страницы. Модифицируйте по собственному усмотрению. На сонном 4-ядернике 50...100 запросов в секунду в тесте main.php должны нормально так загрузить проц. Загрузка - это работа (хоть и не всегда производительная). Нет загрузки - нет работы.

Если на локальных тестах в связке PHP + MySQL нормально будет, то расширить область тестирования на вебсервер. Опять же, локально, без всяких "барахлящих интернетов" и браузеров. Написать скриптик с curl'ом, циклически "дергающий урл" - дело нескольких минут. Curl умеет и множественные запросы, если что, но по мне так для более ровного распределения по времени и простоты логгирования проще запустить 5...10 отдельных процессов с выводом результатов в отдельные файлы или консоли. Таймаут курлу установите в одну секунду (или менее). В лог для начала - время обработки запроса, код ответа вебсервера, вывод скрипта по желанию.

Если в локальных тестах обнаружатся заметные проблемы - следует искать их причины.

По загрузке дискового ввода/вывода - утилита iotop есть. В принципе, в atop тоже видно, только переключаться надо.

Hettпопробуйте повысить размер innodb-pool-buffer-sizeА смысл его повышать, если там данных с гулькин нос? Тормоза ж при таблице в сотню записей, она даже на мегабайт не тянет.

gpbetatesting,

Простой тест one.php тоже показал низкую производительность или, хотя бы, тысячу запросов прогнал в приемлемое время? Это простейший тест, он не должен тормозить при мало-мальски исправном железе.

gpbetatesting,

А, у Вас же виртуалка... На виртуалку могут всяких ограничений понавешать - и на проц, и на диск...
Там запросто подобное может пойти в десять раз хуже.
Поинтересуйтесь у хостера, не навалял ли он каких-то дурных ограничений. А то мож там ядер то четыре, да по 500 МГц каждое в эквиваленте. Дисковая подсистема хост-машины тоже может быть чем-то перегружена и покажет производительность на уровне дерьмовой флешки, она же не в Вашем личном распоряжении.

Найдите на битриксяческом сайте тестовый скрипт, предназначенный для проверки сервера перед установкой Битрикса. Называется bx_server_test.php или как-то так. Там есть простые тесты и для СУБД и для ФС. На остальные можете не обращать внимания. Для Вашего случая результаты тестов должны быть на "отлично". Если это не так, попробуйте потребовать объяснений у хостера. По крайней мере, оный скрипт является официальным и Вам будет на что сослаться.