Теоретически есть SNI, но на него давно известна атака SSL Rehandshake, и почти все у кого
он был активирован его выкосили пол года назад.
Нет, вероятности у ТС посчитаны правильно.
Второй вариант подсчета (не точный, но при высоком аптайме катит) :
при обращении к сайту вероятность получить ошибку 0,5%
обращений за год 52.
умножаем 0,5% на 52 = 26%
Это Вероятность того, что в течение года поисковый бот _хоть раз_ получит ошибку.
ТС посчитал более точным способом, но он с непривычки не всем понятен.
Разумеется "у кого как". У меня за прошлый год 99,74%. За 10 лет как то не считал :).
Это ваша забота - экспертно посчитать убытки от простоя в $$/час.
А уже из этой цифры вытекает сколько денег есть резон тратить на систему, и сколько девяток после запятой стоит достигать. 99,9 или 99,999
Пичаль.... А где тут убытки?
$$ ?
Могут выйти на связь с клиентом и через 30 минут. 90% клиентов к этому отнесется нормально.
Это вроде как не ваша головная боль, а провайдера?
Во первых при первой недоступности страницы не выпадают, иначе при каждом ребуте сервиса
был бы риск обвалить клиентов.
Бот обязательно придет чуть позже, даже если не получит корректного "revisit after".
Первая мысль - протестировать железо и попытаться понять по какой причине падает фронтенд, и сколько времени нужно на рестарт сервиса.
Вы изначально не идеально точно понимаете суть вашей задачи.
На самом деле суть - минимизировать убытки от простоя сервиса _в сумме с расходами на поддержку сервиса_.
Вот теперь давайте думать:
Добротный опытный хостинг дает достаточно высокий аптайм.
к примеру у меня 99,87% с Нового Года.
Теперь считаем - сколько это, 0,13% в месяц.
А получается это 56 минут. Не все из которых приходятся на рабочее время, большАя часть простоев все таки служебные и происходят после 22:00.
Теперь вопрос - наносит ли 30 минут простоя в рабочее время вам убытка хотя бы в сотню долларов, чтобы воротить распределенные системы, и гоняться за максимальным аптаймом.
И какова будет скорость реакции ваших систем в случае аварии. Если ошибка возникла на 1 минуту, а ваша система перестраивается за... тоже минуту - толку в этом мало.
Да, будем знакомы... очень приятно....
Где "там"? Оказывается я _обязан_ был следить за всеми ветками на этом форуме?
А еще на хабре, лоре и опеннете? Точно обязан? А если чего не прочитаю - хана мне срочно?
5% от (гигабита?) канала на служебку? Спасибо, кэп.
<irony>Пичаль....</irony>
Открою секрет - уже очень древние диски умели читать всеми головками.
И еще один секрет - все головки на всех блинах как и очень древних дисков все еще
и до сих пор находятся в одном подвесе-каретке. И раздельно в венике не двигаются.
Потому чем больше у вас блинов, тем круче получаете линейную скорость и тем более тяжелую
хрень нужно перемещать при рандомной нагрузке, из чего вытекает....
но при блоках в 128К это уже не критично.
Эти 64 мегабайт туда запихнули.... сам не знаю зачем. Размер кеша диска ни в каких задачах не "решает", там бы и 8 хватило.
Суть NCQ..... проще будет почитать на википедии. Там лаконично.
Вы наверное будете смеяться, но
у него
AST(r) = 9
LRS = 156
напомню - я предполагал 9 и 150.
Так что уровень веников я угадал ну очень точно.
Да, и никогда не читайте книги старых раллистов по теории экстремального вождения, просто купите точилу поновее и помощнее. И обязательно с полным приводом.
ИМХО 50 мегабайт это очень даже близко к гигабиту. С точки зрения физика разница менее порядка - это близко.
Не очень понял какой именно сигейт объявлен в каком топике, потому характеристики будут "от сферического коня".
ast = 9
lrs = 150M
50/150 = 0,33
из чего делаем гипотезу - 33% времени диск читает, 66% ищет.
0,6 сек / 0,009 = 67 репоз...
50 * 1024 / 128 = 400 блоков в секунду отдается.
на то чтобы прочитать 400 блоков требуется 67 серьезных репозиционирований.
(ибо track-to-track на порядок быстрее)
т.е. на одного клиента считывается ~6 блоков (почти мегабайт) и обслуживается следующий....
====
иначе говоря в синтетическом тесте, при рандоме в пределах _всего_винта_ (а не гигабайтного файла) при ast 9 вы получите ~14 мегабайт в секунду, а никак не 50.
либо речь шла о 15kRpm SAS и ast 3,8 ?
тогда цифры очень похожи.
либо речь о паралельной раздаче N стримов (15-25) которые вы почему то назвали "на рандоме при размере блока 128к"
Один веник 7200rpm в режиме линейного чтения может выдавать до 200 MBps. Т.е. 1600Mbps.
И этот же один веник при абсолютно рандомной посекторной нагрузке "в полочку" выдаст
с учетом NCQ и прочих танцев с бубном 300 iops, т.е. ..........
150 kbps (!!!)
немножко 10000 раз разницы.
А истина - где то между, и немного правее. :)
Логика присутствует. Но износ этих ячеек наступает очень не скоро на практике.
И бороться проще установкой большего SSD шника, а не raid0 из более мелких.---------- Добавлено 13.06.2012 в 14:10 ----------
Ничего так тема, мне в ней все понятно. Но для человека со стороны достичь там просветления
очень не легко. Больше вероятность получить взрыв мозга. :)
Да, на запись так. Если нет кеша записи на батарейке - то даже чуть хуже, порядка 10-15%.
При работе с видео он и на чтение работает как один диск - на коротких страйпах.
Для _видео_ контента не очень рационально использовать raid, и уж совсем не имеет смысла raid0 из ssd.---------- Добавлено 12.06.2012 в 23:08 ----------
80 х 312 / 1024 = 24 мегабита.
С другой стороны один 7200rpm диск имеет average seek time от 11 (дешевый) до 7 (не дешевый) милисек.
т.е. от 90 до 140 транзакций в секунду. (1000/11 и 1000/7 соответственно.)
80 (пользователей онлайн) и 90 (транзакций дешевого диска в секунду) ну очень похожие цифры.
итого - вам не гигабит нужен, а оптимизация дисковой системы. Вам и 100 мегабит
пока должно хватать с запасом в 4 раза.
Могу вам построить дешевый дисковый массив с учетом именно видео задач.
В аренду или просто на продажу.
Однако про легальность контента вы вопрос "не заметили". Уточните?
