Новая тема   Ответить

 zJ
Есть сервер, субъективно я заметил что страницы стали с него отдаваться несколько дольше чем раньше, и меня стали волновать две вещи:
1. Не теряю ли я деньги из-за того что у кого-то страницы элементарно долго грузятся?
2. Не слетит ли все это в след. понедельник т.к. понято что если нагрузка пиковая то риски "слета" сильно возрастают (или нет?).

Как узнать обьективные ответы на эти вопросы? Есть ли спец. мониторинг сервисы или достаточно MRTG графики специалисту показать?

Могу тут запостить всю необходимую инфу.
Также меня и чисто теоретический интересует вопрос - как узнать когда пора бы искать доп. мощности?

 XXL-Cash [Promo]
zJ писал:
1. ДОЛГО - понятие растяжимое....
2. Если это реально пиковая нагрузка, то конечно же рессурс винта или проца уменьшается (зависит от причины нагрузки)
В принципе, достаточно будет данных программы top (Unix) ну или Диспечера Задач если Win :-)
Если быть более точным, то данные о загрузке процессора, свободной памяти, кеша, и список процессов. И данные о канале не мешало бы знать. Может оно долго открываеться из-за того что у тебя канал зажат....
Доп. мощности надо искать когда все настроено хорошо и все равно не хватает. А подкрутить на сервере всегда есть что :-)
Ты главное скажи конфигурацию сервера и кол-во трафика на нем. А мы тебе скажем, должен он это кол-во выдерживать или нет...

 zJ
Цитата:

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

Конфиг такой - P4 2.4 / 1Гб / SCSI винт
Трафика под 3Тб в месяц будет.

Могу тут выложить MRTG графики, если нужно.

 ghood
zJ писал:
Конечно теряешь, может не очень много

zJ писал:
Если ты о железе, то скорее нет, чем да.
Цитата:
Узнать объективные ответы можно проконсультировавшись у специалиста.
Есть спец. мониторинг сервисы, есть много всякого софта. Графики MRTG скажут в зависимости от того, что там изображено
Скорость отдачи страниц можно существенно увеличить при помощи применения более правильного софта или оптимизации существующего.
Всё очень ИМХО.

 zJ
Цитата:

Any pics?

[deleted]

Последний раз редактировалось: zJ (22/10/05 в 08:00), всего редактировалось 1 раз

 Sveta_V
Оффтопик: zJ, я тут сопоставила твой ответ в др. топике про 500 сайнов в месяц, и это еще небось не у одного спонсора (!) и этот топик. Как же ты так зарабатываешь, расскажи У меня такой же сервер и столько же трафа съедается в месяц, но у меня 500-ами сайнами и не пахнет.

 ghood
zJ, стукнись в асю, прокомментирую... тут не буду

 zJ
Sveta_V писал:

1. Не все тут хоститься.
2. Я почти не работаю с контентом соотв. расходы на хостинг многовесящих вещей типа пиксов и мувиков у меня минимальны.

 bog
ghood писал:
вот тут могу поспорить. когда то на своем печальном опыте узнал что можно потерять до 50% денег даже из за легкого притормаживания.

 samlowry
bog: а как узнал? Поспорь, блин, с фактами, чтоль, а то все в шпиенов гамаемся, уже нагрузку на сервер обсуждать в открытую боимся,
ghood писал:
- это ж пипец.

 leetd
сидж на тормознутом хосте это дырявая кастрюля :)

 Phoenix66
Sveta_V писал:



Есть люди, которые имея один сервер за 200 баксов (селерон с одним терабайтом трафа) зарабатывают больше 5К. Правда это конечно не сиджи, и даже в основном вообще не адалт.

Это я как хостер говорю.

 kit
Быстрота сайта - очень важно.
Всегда и везде.

 bog
samlowry писал:
а все просто.
я както из основные домены из одного датацентра в другой переводил.
на более мощное железо, но как выяснилось чуть более хреновый канал.
в итоге при том же количестве и качестве трафа я в тот месяц получил на 50% меньше денег.

 ghood
Phoenix66 писал:
Есть люди которые на таком серваке зарабатывают в 20 раз больше , это не предел конечно. И конечно не адалт.
Цитата:
А что тебе реально интересно услышать мои рассуждения о МРТГ графиках?
Никто тут в шпионов не играется, просто вопрос технический, никому кроме топикстартера я думаю он не интересен. Так что ничего экстраординарного тут я не вижу

 samlowry
ghood: форумы для публичного обсуждения. Интересно услышать, да.

 Avva
Народ, тема реально актуальна. Вот как например проверить насколько сервер шустро работает? Я имею ввиду загрузку конкретного сайта.
К примеру ввожу в http://www.parkline.ru/tracer.html
свой домен, потом домен каког нибудь буржуйского сиджа. По цифрам почти нет разницы. Но в браузере мой сайт грузится как полудохлая черепаха, а другой сидж махом. А у меня DSL.

Как можно реально оценить скорость загрузки сайта у конечного пользователя?

 XXL-Cash [Promo]
Avva писал:
Трейс измеряеться в МИЛИСЕКУНДАХ, так что разница в пару цифр на каждом хопе достаточно принципиальная.

Avva писал:

Если твой сайт ориентирован на буржуев, то и traceroute нужно делать с буржуйских точек (Например у 3fn.net есть веб трейс). Попроси закомых сделать трейсы на твой сервер с разных серверов. Посмотри время отклика и кол-во хопов (кол-во маршрутизаторов). Это покажит скорость доступа к серверу. Но тебе еще надо проверить загрузку канала и сервера. Для этого самый простой способ - это положить на сервер файлик метров на 50-100 и попросить опять же знакомых с буржуйскими серверами перетянуть этот файлик с твоего сервера на их. И посмотреть какая будет скорость. Качать, конечно-же, желательно по http, тем самым проверишь скорость web сервера.

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

 magic
XXL-Cash [Promo] писал:

http://tech.3fn.net/traceroute.html

 magic
bog писал:

существую программы для стресс тестов вебсервера. ab хотя бы.

 bog
magic писал:
да, ab это веселая штука ))

 Avva
Прокоментируйте пожалуйста, это трэйс буржуйского сайта.

1 794.ge-4-1-1.er10b.sjc2.us.above.net (64.124.84.3) 143.798 ms 11.753 ms 11.150 ms
2 so-2-0-0.mpr4.sjc2.us.above.net (64.125.30.101) 2.337 ms 1.393 ms 1.263 ms
3 so-3-0-0.mpr1.sjc7.us.above.net (64.125.30.177) 1.384 ms 4.876 ms 1.554 ms
4 g4-6.pr01.sjc03.atlas.psi.net (64.125.12.90) 1.620 ms 4.716 ms 2.152 ms
5 p3-0.core01.sjc01.atlas.cogentco.com (154.54.1.29) 2.880 ms 3.070 ms 2.986 ms
6 p14-0.core01.iah01.atlas.cogentco.com (66.28.4.237) 67.146 ms 63.698 ms 62.963 ms
7 Alpha.demarc.cogentco.com (38.112.24.242) 63.219 ms 63.120 ms 63.329 ms
8 38.113.141.2 (38.113.141.2) 63.370 ms 63.421 ms 64.533 ms


А это моего.
1 794.ge-4-1-1.er10b.sjc2.us.above.net (64.124.84.3) 1.195 ms 0.942 ms 0.916 ms
2 so-2-0-0.mpr4.sjc2.us.above.net (64.125.30.101) 1.226 ms 0.790 ms 0.830 ms
3 so-4-0-0.mpr4.pao1.us.above.net (64.125.29.162) 1.310 ms 1.802 ms 1.376 ms
4 webusenet.needs.to.reg.ptr.info.with.paix (198.32.176.164) 1.094 ms 1.103 ms 1.674 ms
5 sjc-c00-gbe-1-5-8.lan-pao-a00-ge-2-0.wvfiber.net (63.223.0.189) 1.923 ms 2.276 ms 3.461 ms
6 sjc-c00-pos-1-27-1.OC48-chi-c00-pos-1-15-1.wvfiber.net (63.223.20.54) 54.083 ms 54.076 ms 53.599 ms
7 nyc-c00-pos-1-36-1.OC48-chi-c00-pos-1-5-1.wvfiber.net (63.223.0.213) 79.911 ms 80.225 ms 82.532 ms
8 nyc60-a00-pos-4-0.OC48-nyc-c00-pos-1-35-1.wvfiber.net (63.223.28.10) 80.224 ms 79.129 ms 79.067 ms
9 cust-ezzi.net.wvfiber.net (63.223.28.138) 79.334 ms 79.193 ms 79.070 ms
10 65.125.239.146 (65.125.239.146) 82.525 ms 81.295 ms 81.747 ms
11 server106.masenqa.com (66.199.246.98) 316.213 ms * *

 ghood
ping не показатель, но информацию он даёт, нужно только брать усреднённые значения.
traceroute тоже даёт информацию.
Из MRTG тоже можно получить много информации, если знать основные принципы работы и взаимодействия программного и аппаратного обеспечения.
На основе данных Avva, я могу предположить, что сервер или канал во время пинга был загружен.
ab не совсем адекватно позволяет оценить сервер, нужно имитировать работу браузера, то есть сначала html, а за ним в столько-то потоков Keep-Alive или без него вытягивать кучу картинок, при этом замеряя время. Так чутка адекватнее.
Кстати апач желательно не использовать там, где требуется быстродействие.

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