valet, проблема какого движка была? Dle?

Да, но не конкретно он виновник. Проблема была в нестандартном модуле, дописанном к этому движку, который вызывал ту функцию.

В общем в конце концов оказалось, что проблема вообще в скриптах движка, а именно один php-файл коннектился к удаленному серверу через @file_get_contents, что давало такую задержку.

Спасибо всем за помощь.
Отдельная благодарность newzenon.
Добился скорости ответа в 0.3-0.4 сек. Все уже работает.

Создал тестовую БД с маленькой табличкой и вставил в нее несколько строк. Написал маленький php-скриптик для коннекта к ней и вывода данных. Прогоняя siege ожидал получить свои 16 сек, но результат меня поразил: я получил это:
siege -v -i -c 100 -t 1m -f url_test

Я конечно был в шоке. Тогда я решил настроить еще один хост (тот же движок, но не лицензионный и с другой бд)  и получил следущее:
siege -v -i -c 100 -t 1m -f url_site

Ну я  подумал, что та бд, страницы с которой генерируются по 16 сек тяжелая слишком (хотя опять таки, этот сайт сейчас прекрасно даже на виртуальном хостинге работает с этой бд) и я решил залить в этот проблемный хост (тут кстати лицензионный DLE) более легкую бд.
Тут я уже ожидал получить мои полсекунды, но я получил опять же 16

там выбрать конфигурацию можно

Да. там есть такое: разные варианты конфигов под разного уровня нагрузки, что-то вроде mysql-huge, mysql-small и т.д.
Но и вариант по умолчанию должен хоть как-то работать. Там похоже какой-то таймаут срабатывает когда php-скрипт пытается подконнектится к мускулю.

Вот последний тест siege -v -i -c 100 -t 60m -f sitemap

Я думаю тут тоже в связке php-mysql проблемы.
Попробуй протестировать чистый php-файл. Самый лучший вариант файл с текстом <?php phpinfo(); ?>

У меня так на siege -v -i -c 200 -t 1m -f phpinfo_file

тут phpinfo_file - урл файла info.php с текстом <?php phpinfo(); ?>
И это при 200 юзерах. Так что не в php проблемы. Проблемы именно при коннекте к mysql.

siege -v -i -c 200 -t 1m -f 1_file

Вебсервер отдавая статику летает.

nginx как зверь работает - не в нем проблема точно, сейчас попробую еще чистый пхп - без связок с mysql

valet, Error log включи, а то я его в /dev/null отправил  smile
И глянь логи.

Сделал

Рестартовал /etc/init.d/nginx restart

siege -v -i -c 50 -t 1m -f sitemap

tail /var/www/error_log - пусто, нет ерроров

Да не в nginx проблема - это 100%.
Сейчас дам нагрузку на статический html-файл например...

Вот последний тест siege -v -i -c 100 -t 60m -f sitemap

Lifting the server siege...      done.
Transactions:               18038 hits
Availability:              100.00 %
Elapsed time:             3599.17 secs
Data transferred:          210.67 MB
Response time:               19.39 secs
Transaction rate:            5.01 trans/sec
Throughput:                0.06 MB/sec
Concurrency:               97.20
Successful transactions:       18038
Failed transactions:               0
Longest transaction:           27.96
Shortest transaction:            7.48

Тестировалось локально siege -v -i -c 50 -t 1m -f sitemap

Эти средние 11 сек за счет того, что сервер долго отдыхал при тестировании вообще все класно начиналось: 1, 2, 3 и т.д. сек аж до 20 сек и дальше. При этом среднее получилось 11. Сейчас еще раз запущу - и выйдут заветные 16 сек