Высокие нагрузки

[phillip]

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

Может быть есть еще варианты, как протестировать?
Хотел сделать скрипт на курле, чтобы имитировать 15к юзеров, да подумал что он много запросов не будет успевать отправлять.
:bc::bc:

 

[Abliganto]

так... ну собственно я сделал как запланировал, а как затестить на нагрузки так и не понял. апач бенчмарк показывает примерно одинаковые результаты и для других скриптов, и для этого. и опять же, 15к запросов шлю- ничего не начинает виснуть. а когда в реале приходит 15к человек на сайт- все виснет.
Может быть есть еще варианты, как протестировать?
Хотел сделать скрипт на курле, чтобы имитировать 15к юзеров, да подумал что он много запросов не будет успевать отправлять.
:bc::bc:

Что означает "всё виснет"? Нужно конкретно знать что тормозит. Посмотрите хотя бы top (линукс команда), во время пиковой нагрузки. Тормозит может
а) Веб-сервер
б) База данных
в) Сеть
г) слабый компьютер, ограниченные ресурсы, тогда тормозит всё

15к человек за какой промежуток времени? Тут скорей важна цифра запросов в секунду, т.к. 15к запросов в сутки - это вообще не нагрузка. Нагрузка начинается от 20 запросов в секунду, обычно это порог среднестатистических сайтов. А ваш скрипт должен отдавать как минимум 100 запросов в секунду.

 

[General Fizz]

ТС: попробуй тупо занести все выбираемые строки в массив и инклюдить его в основной файл. А потом уже из этого массива, а не из базы данных, выбираются нужные строки случайным образом. Если скажем размер будет до 500-1000кб, то скорость доступа к конкретным строкам увеличится в разы, правда при этом возрастет расход памяти.


Второй вариант: занести все выбираемые строки в базу типа Berkeley DB (функции с префиксом dba_) и выбирать их оттуда.


Еще добавлю: генерируешь один раз файл со случайными целыми значениями и количеством равным количеству строк в файле. Либо же берешь массив с возрастающими по порядку целыми числами от 1 до <количество строк в файле> и перемешиваешь его. Заносишь всю последовательность в массив. Это делается один раз и добавляется в скрипт на этапе программирования.


Выбираешь из этого массива скажем первые 25 значений, они будут уже случайными индексами для выборки по ним соответствующих строк из базы Беркли. Следующий раз выбираешь следующие 25 строк и так далее.


Для увеличения элемента случайности можно по крону перегенерировать каждые сутки массив со случайными индексами и инклюдить его повторно в скрипт, правда при этом надо правильно установить права доступа.


Идея понятна?

 

[phillip]

Понятна. Но я уже сделал пока на простом MySQL. Дальше буду копать в сторону dba_ если с мускулем ничего не выйдет.

Вообщем на самой странице вывел время выполнения. Получилось то 0,02 то 0,8 то аж 4 секунды! Установил xdebug, включил профайлинг. Насохранял кучу логов. Вручную отсеял нужные (кстати кто-нибудь знает как автоматом оставить логи только с определенного домена?). С четырьмя секундами не нашлось, а вот с секундой попалось. Гляжу какая строка сколько времени заняла. Оказывается, вот эта)))
$result = @mysql_query($query,$link);
секунда ушла на выполнение запроса. Все остальное- практически нуль. То есть нашлось ОНО. слабое место- мускуль.
:bc::bc::bc:

p.s. сам запрос таков $query = "SELECT `k` FROM `".$mod_keys."` WHERE `id`='".mt_rand(0,$k_c['COUNT(*)'])."';"; соответственно $mod_keys- таблица с кеями, $k_c['COUNT(*)'] общее кол-во строк в таблице

 

[Abliganto]

А какой запрос был сделан к БД? Пример любого $query и желательно сделать explain т.е. explain select .... к примеру в phpmyadmin.

У mysql есть 2 узких места: подключение к серверу и сетевое взаимодействие, т.е. передача пакета с результатом (при условии что таблица, индексы и запросы оптимизированы + настройки самого mysql подобающие)

ТС: попробуй тупо занести все выбираемые строки в массив и инклюдить его в основной файл. А потом уже из этого массива, а не из базы данных, выбираются нужные строки случайным образом. Если скажем размер будет до 500-1000кб, то скорость доступа к конкретным строкам увеличится в разы, правда при этом возрастет расход памяти.

Здоровый файл получится, будет долго инклюдиться. dba_ работает довольно шустро, но файл будет считываться с диска, что уже само по себе медленно (само перемещение головки диска на разные части файла seek). можно смонтировать мемори диск и положить на него этот файл, как вариант...

 

[phillip]

запрос см. выше, чуть позже дописал после того как запостил

кстати есть еще один запрос, второй. Он вызывается чаще того что выше. Выглядит примерно также, в итоге получается вот как:

SELECT `k` FROM `table` WHERE `id` IN (6,13,23,54,53);

Ну то есть как вы и советовали
сделал в пхпадмине explain, показывает вот что:

id 1
select_type SIMPLE
table keys-bigt
type range
possible_keys PRIMARY
key PRIMARY
key_len 4
ref NULL
rows 5
Extra Using where

Запустил раз пять, время выполнения всегда разное от 0.0003 сек. до 0,8 сек.

Это учитывая то, что пока что юзеров там нет, кроме меня. А вот когда придут, тогда будет ппц поди-ка. Если даже часто обновлять начинаю- показывает до 4ех секунд

А, еще инфа по самой таблице, вдруг поможет
тип таблицы- MyISAM
Формат динамический
Сравнение latin1_swedish_ci
Строки 439,858
Длина строки ø 35

2 поля
id int(11) auto_increment
k varchar(255)

 

[Abliganto]

Очень странный разброс. Видимо сервер загружен конкретно.

Запрос на весь скрипт должен быть только один. count(*) для MyIsam хоть и быстрый, но лучше его не делать каждый раз.

Если в таблице 440тыс. записей, то это мегабайт 18 текста. Чтобы исключить любые тормоза по диску и сети, надо хранить данные в памяти. К примеру генерите 10 рандомных ID и проверяете их наличие в памяти к примеру apc (только в с лучае APC нужно указать в настройках сколько памяти будет выделено) если не найдено, делаете запрос в БД и сохраняете в память. Далее этот ИД будет браться из памяти. Я использую и APC и Redis в своих проектах.

+dba хранит все строки одинаковой длины. т.е. если 90% строк длиной в 50 символов, а одна строка 200, то будет много места израсходовано зря. Такой файл если класть в память, он будет зря её тратить

Если и эти советы не помогут, может всё же VDS тормозит? Некуда уже оптимизировать. Скрипт должен получиться на ~20 строк.

 

[phillip]

ok! спасибо за помощь, очень ценно.
заказал саппорту установить АРС.
насчет выделяемой памяти- я ведь могу и всю таблицу так держать в кеше? у меня еще 600мб свободной оперативки, и она особо никуда не тратится. почему бы не выделить для АРС мегабайт 100, да? или не надо так делать?

 

[Abliganto]

Да нет, вполне можно выделить 128мб. Память ещё будут хавать скомпилированые скрипты. Если у вас нет тяжёлых CMS на этом веб-сервере (других сайтов). В любом случае всегда можно увеличить объём выделяемой памяти. Можно и всю таблицу. Важно предусмотреть чтобы в случае потери кеша данные подгрузились снова из БД.

В поставке идёт файлик apc.php там есть небольшой GUI, где можно смотреть статистику и графики.

 

[General Fizz]

...
Здоровый файл получится, будет долго инклюдиться. dba_ работает довольно шустро, но файл будет считываться с диска, что уже само по себе медленно (само перемещение головки диска на разные части файла seek). можно смонтировать мемори диск и положить на него этот файл, как вариант...

Тут надо выбирать соотношение потребляемый размер памяти/скорость. Если файл будет размером до скажем 500 кб, то такой вариант также имеет право на жизнь. Можно вставить в скрипт также перемешивание массива, а выбирать последовательно х индексов. Насколько я помню, в пхп при перемешивании массива его значения остаются на месте, а мешаются только индексы.


Еще есть вариант - хранить данные в разделяемой памяти с доступом через семафоры.


ТС: а ты не забыл про кеширование на диск? Едва ли каждый раз нужно перегенерировать одно и то же.