- Сравнение производительности OLTP-приложения в связке с ngin, User294, 13:11 , 18-Сен-09 (1) +2
- Сравнение производительности OLTP-приложения в связке с ngin, Аноним, 13:25 , 18-Сен-09 (3)
- Сравнение производительности OLTP-приложения в связке с ngin, Юниксоид, 13:33 , 18-Сен-09 (4)
- Сравнение производительности OLTP-приложения в связке с ngin, ihanick, 14:06 , 18-Сен-09 (5)
> Какая разница на чём тестировать, интересны ведь не абсолютные результаты, достигнутые на квадахЕсли решение позиционируется как масштабируемое на высокие нагрузки, значит окружение должно быть подходящее для высоких нагрузок. Сейчас даже десктопы имеют много процессоров. А уж система, работающаяя на самой дорогой коммерческой базе данных обязана эфективно использовать много физических процессоров. Ни одна виртуалная машина сейчас не позволяет внутри виртуальной машины эфективно использовать SMP, без cpu cache trashing. как минимум надо было взять физический квад. Приложение после listen на сокете расфоркать на 2-4 процесса для более полной утилизации процессоров. Провести сравнение производительности на tcp и unix сокете: разговоры про tcp overhead при использовании реляционной базы данных это детский лепет. Выбрать более-менее приближенный к реальности workset и запросы долбить не в один урл, а большой список. Запросы подавать с заведомо более мощной машины, для того чтобы исключить фактор медленной работы ab2 или siege. Научиться, наконец-то пользоваться ulimit и dmesg В процессе тестирования собирать нужную информацию: vmstat - полнота утилизации, wait on io, swapping (следить чтобы не наблюдалось) dmesg, чтобы отлавливать сообщения о переполениях системных таблиц (например conntrack) обращать внимание на резкие скачки и плато возникающие по степеням двойки 1024,65536 - обычно связанные с затыканием в sysctl параметр. oprofile для исследования составляющих cpubounded нагрузок (например там легко увидить проблемы связанные с производительностью dns). systemtap исследования характера io. проводить тестирование длительное время для исключения влияния cron и случайных пакетов из локальной сети. Проводить статистическую обработку данных. И самое главное у тестирования должна быть цель. Обычно тестирование используется для тюнинга и оценки производительности больших систем. Данное тестирование было проведено, для того чтобы опробовать новую технологию. Но выводы сделаны неправильные (особенно радуют замечания про потери транзакций, в nginx failback спецально для 502 на нескольких серверах есть, как минимум).
- Сравнение производительности OLTP-приложения в связке с ngin..., Аноним, 13:18 , 18-Сен-09 (2)
|