Comments 11
7z
fio
fio
Всего этого можно было бы избежать, если бы разработчики не лезли в админские дела.
Бывают такие ситуации когда на стороне заказчика бородатый админ с древним сервером и софтом из мезозоя. Да, там может быть аптайм несколько лет и «все работает, ничего не трогайте», но в итоге довольно шустро бегающий сайт после заливки на тот сервер начинает жутко лагать.
Админы же традиционно все валят на разрабов и ничего не пытаются менять.
Админы же традиционно все валят на разрабов и ничего не пытаются менять.
Суммарный вывод не увидел :( Фактически ставили четкую цель. По результатам замеров получили разрозненные (по агрегатам) результаты, как это поможет сделать выбор? В сухом итоге: Здесь А2 круче, Здесь А3 такой же, здесь VPS ничего… Наверное не хватает, что — то типа, но для нашего приложения важнее Проц и Память, поэтому Выбираем А2, но делаем себе отметку, что если будет провал там-то, то это нормально и надо искать другое решение… Возможно не понял посыл статьи.
Вероятно, вы правы, некого вывода в виде рецепта я не привел. Причем, когда статья задумывалась и формировалась, такая идея была.
Хотел показать некие практики наподобие «У вас есть сервис генерирующий thumbnail'ы (активное использование диска) — берите такой-то сервер. У вас строго вычислительный сервис — вам подойдет другой сервер».
Позже решил отказаться от такой идеи. Уж слишком однобокие получаются выводы. На практике такого и не встречал. Как правило, мы имеем дело с web-проектом, который активно нагружает все компоненты сервера, а значит все его компоненты должны быть быстрые. И приходим мы к выводу, что если нужен быстрый web-проект, то и сервер должен быть быстрый целиком, как бы банально это не звучало.
Поэтому в статье даётся перечень инструментов, которые позволяет измерить производительность отдельных компонентов сервера. Что делать с результатами — каждый решает сам.
Хотел показать некие практики наподобие «У вас есть сервис генерирующий thumbnail'ы (активное использование диска) — берите такой-то сервер. У вас строго вычислительный сервис — вам подойдет другой сервер».
Позже решил отказаться от такой идеи. Уж слишком однобокие получаются выводы. На практике такого и не встречал. Как правило, мы имеем дело с web-проектом, который активно нагружает все компоненты сервера, а значит все его компоненты должны быть быстрые. И приходим мы к выводу, что если нужен быстрый web-проект, то и сервер должен быть быстрый целиком, как бы банально это не звучало.
Поэтому в статье даётся перечень инструментов, которые позволяет измерить производительность отдельных компонентов сервера. Что делать с результатами — каждый решает сам.
Добрэ, как описание инструментов и способ применения — интересно и полезно.
В принципе познавательно, но применимо ли на практике? Сколько можно вообще перетестировать серверов, выбирая нужный? Один, два, десять? Может быть, проще запускаться на первом попавшемся и по ходу дела определять чего не хватает? Вариантов то море, все не перепробуешь.
Ну не надо мерить так диски, ну что же это такое… То файлики копируют, то dd запускают.
Любой диск на обычном ПК будет значительно быстрее дискового массива с тысячью дисками за 2 млн $, если запускать на него 1 поток.
Никакое нормальное приложение никогда (надеюсь) не будет работать в таком однопоточном режиме с подобным профилем нагрузки. Сделайте один раз оценку, напишите профиль (а лучше несколько) на VDBench и используйте его для оценки производительности. Или найдите их в интернете.
Немного теории можно подчерпнуть в неплохой статье здесь
Любой диск на обычном ПК будет значительно быстрее дискового массива с тысячью дисками за 2 млн $, если запускать на него 1 поток.
Никакое нормальное приложение никогда (надеюсь) не будет работать в таком однопоточном режиме с подобным профилем нагрузки. Сделайте один раз оценку, напишите профиль (а лучше несколько) на VDBench и используйте его для оценки производительности. Или найдите их в интернете.
Немного теории можно подчерпнуть в неплохой статье здесь
Методики интересные. Также бывает важно измерить время отклика сервера и пропускную способность канала. Причем результаты часто по закону подлости получаются из офиса заказчика гораздо хуже, чем с компьютеров разработчиков.
Sign up to leave a comment.
Способ быстрого измерения производительности случайного сервера