Как проверить MySQL ？

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

Вопрос звучит по типу "как доказать, что уборщица в многоквартирном доме не убирает начисто". А что сделаешь, когда все от жильцов зависит :)

Суть проблемы абсолюнто ясна, возможно я не так пишу что-то...

Как доказать, что уборщица не убирает - задача, которая не стоит. Стоит задача доказать, что в доме не убрано, т.е. что именно mysql тонкое место (а не скрипты к примеру). С уборщицей это просто, зовешь и тыкаешь носом в кучу говна в лифте...

Вопрос в том, гдеб найти стандартных тестов погоняв которые можно сделать вывод, что "говно в лифте есть".

Неужели проблема не стоит ?

ЗЫ. В скриптах я разумно уверен... но хочется быть уверенным на 100%.

ЗЫЫ. Вот есть хосттрекер, можно оценить аптайм... и это в общем некий стандарт,

а вот чтой-нибудь для диагностики mysql-сервера подобное... смысл в том, чтобы

это был готовый разработанный не нами тест, чтобы исключить возможность повтора

ошибок.

в дистрибутиве mysql есть sql-bench. mysqlslap, super smack. да завались их в гугле.

Спасибо, это ближе к теме, остается вопрос удастся ли воспользоваться всем этим на вирт. хостинге... ушел в гугл.

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

Я не просто так привел аналогию виртуала к многоквартирке.

А если жильцы гадят по 5 раз в день, кто виноват, что оно есть ?

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

MySQL используют на виртуале все клиенты хостера. И заоптимизируйся, но все равно все от остальных зависит.

Это разумное утверждение, поэтому хотелось бы найти не столько стресс-тесты, сколько стабилити тесты, нечто, что выполняет типовые запросы раз в 10с в течении суток к примеру,

и строит графики задержек.

Т.е. речь не о том, как много пользователей может обработать сервер, а о том, насколько

сильно он бывает загружен.

Вас же за хосттрекер не мочат, а он в общем-то осуществляет тестирование...

_SP_ добавил 28.01.2009 в 15:22

Да хоть 25.

Для принятия любого решения хорошо было-бы для начала знать сколько раз и гадят ли, согласны ?

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

За хосттрекер нет, а вот, к примеру, у ab(apache benchmark) шансы хорошие быть забаненным.

Вряд ли Вы найдете на такую простую задачу какую нибудь утилиту. Такое просто пишется самостоятельно, тем более, Вы ТЗ уже практически сами себе написали. К тому же, Вам должно быть виднее, какие запросы у Вас типовые - кому select now() типовой, а кому distinct'ы с join'ами.

UPD.

Другое дело - сочтет ли ваш суппорт результаты авторитетными. При адекватности суппорта Вам и без "отраслевых стандартов" могут детально объяснить правы Вы в подозрениях или нет. При неадкватности - хоть окопайтесь тестами и бенчмарками.

uptime + load average покажут более правильную картину , чем пинать базу данных на предмет скорости ответа.

uptime и load average чего ?

Задача отделить проблемы с производительностью в скриптах от проблем в сервере... хостинг еще раз напомню виртуальный.