Как установить пакет с конкретного репозитория

Вот что откопал.
MySQL Performance Tuning Primer Script
http://www.day32.com/MySQL/

Дал даже ему 200 юзеров якобы - без проблем:

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

[console]Transactions: 22671 hits
Availability: 100.00 %
Elapsed time: 59.21 secs
Data transferred: 305.89 MB
Response time: 0.02 secs
Transaction rate: 382.89 trans/sec
Throughput: 5.17 MB/sec
Concurrency: 7.98
Successful transactions: 22671
Failed transactions: 0
Longest transaction: 0.15
Shortest transaction: 0.00
[/console]

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

newzenon написал:

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

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

У меня так на siege -v -i -c 200 -t 1m -f phpinfo_file
[console]Transactions: 22663 hits
Availability: 100.00 %
Elapsed time: 59.92 secs
Data transferred: 216.65 MB
Response time: 0.03 secs
Transaction rate: 378.22 trans/sec
Throughput: 3.62 MB/sec
Concurrency: 11.18
Successful transactions: 22663
Failed transactions: 0
Longest transaction: 0.34
Shortest transaction: 0.00[/console]

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

newzenon написал:

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

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

Ну тогда надо браться за php5-apc или eaccelerator.

Да, вообще какая-то странная ситуация сложилась, которой я никак не мог ожидать.

Создал тестовую БД с маленькой табличкой и вставил в нее несколько строк. Написал маленький php-скриптик для коннекта к ней и вывода данных. Прогоняя siege ожидал получить свои 16 сек, но результат меня поразил: я получил это:
siege -v -i -c 100 -t 1m -f url_test
[console]Transactions: 1585 hits
Availability: 89.55 %
Elapsed time: 59.31 secs
Data transferred: 0.13 MB
Response time: 0.52 secs
Transaction rate: 26.72 trans/sec
Throughput: 0.00 MB/sec
Concurrency: 13.99
Successful transactions: 1585
Failed transactions: 185
Longest transaction: 15.10
Shortest transaction: 0.06
[/console]
То есть с тестовой бд все нормально.

Я конечно был в шоке. Тогда я решил настроить еще один хост (тот же движок, но не лицензионный и с другой бд) и получил следущее:
siege -v -i -c 100 -t 1m -f url_site
[console]Transactions: 3338 hits
Availability: 97.40 %
Elapsed time: 59.54 secs
Data transferred: 16.04 MB
Response time: 0.47 secs
Transaction rate: 56.06 trans/sec
Throughput: 0.27 MB/sec
Concurrency: 26.38
Successful transactions: 3336
Failed transactions: 89
Longest transaction: 19.15
Shortest transaction: 0.11[/console]
То есть с этой бд все нормально.

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

Удалось локализировать проблему.
Создал тестовую БД, тестовый php-скрипт с буквально несколькими командами (соединиться, выбрать данные, закрыть) и вместо ожидаемых 16 сек увидел 0.01 сек кажется.

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

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

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

"newzenon" написал:

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