Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
Они очень серьёзно подходят к оценке быстродействия сайта, и неудивительно, что достигнуты подобные показатели.
560 000 000 / 25 серверов = 22 400 000 в месяц = 8 показов в секунду.
Это что, повод для гордости?
При этом, большинство страниц наверняка кешировано, т.к. не меняется годами.
пс. Ааа, у них серверы на IIS. Тогда всё понятно.
Это что, повод для гордости?
При этом, большинство страниц наверняка кешировано, т.к. не меняется годами.
пс. Ааа, у них серверы на IIS. Тогда всё понятно.
10% нагрузки всех процов при 8 запросах в секунду? однако…
Ээ вы ведь понимаете что все эти просмотры происходят определенными пиками, а не равномерно размазаны? Или нет? Вы знаете какие у них нагрузки на пике?
IIS вполне годный апп сервер.
IIS вполне годный апп сервер.
А почему бы таким показателям не быть поводом для гордости?
StackOverflow занимает на данный момент 46 место в The top 500 sites on the web и работает на 25 серверах.
Для сравнения, Одноклассники занимают 85 строчку в этом же рейтинге, а для работы им нужно 2400 серверов.
StackOverflow занимает на данный момент 46 место в The top 500 sites on the web и работает на 25 серверах.
Для сравнения, Одноклассники занимают 85 строчку в этом же рейтинге, а для работы им нужно 2400 серверов.
У того же ВК количество запросов в секунду измеряется сотнями тысяч в секунду (как и у одноклассников, из статьи) — это в пару десятков тысяч раз больше, чем указано для SO. Я слышал, что «одноклассники» говорили, что у них один сервер обслуживает порядка 1000 запросов в секунду, что немного больше, чем у SO, согласно этой статье.
Если выкинуть все видео и фото, то тоже уместится на 20 серверах.
Почему вы считаете, что страницы там кэшируются и не меняются годами?
Там постоянно добавляется новый контент.
Постоянно идут проверки постов с помощью модераторов, с подключением анализа работы каждого с регулярными проверками на «замыленный глаз».
Регулярно работает пересчёт значков и репутации пользователей.
Мне кажется, вы несколько недооцениваете функционал SO.
Там постоянно добавляется новый контент.
Постоянно идут проверки постов с помощью модераторов, с подключением анализа работы каждого с регулярными проверками на «замыленный глаз».
Регулярно работает пересчёт значков и репутации пользователей.
Мне кажется, вы несколько недооцениваете функционал SO.
Не 25, а 11 веб-серверов. Около 20 запросов в секунду.
Да, не много. Но они реально могут раз в 5 уменьшить число веб-серверов. Т.е. до 2-3.
Не все данные можно закешировать.
Да, не много. Но они реально могут раз в 5 уменьшить число веб-серверов. Т.е. до 2-3.
Не все данные можно закешировать.
Вы представляете, что произойдёт с response time, если уменьшить число серверов в 5 раз?
Пока производительность не упрётся где-то в бутылочное горлышко, можно спокойно уменьшать. Не так велик процесс обработки запроса, как его доставка.
почему Вы думаете, что доставка дольше обработки? В общем случае это совершенно не так, эти цифры никак не связаны.
Но дело даже не в этом, а в том, что если при нагрузке по CPU в 10-20 процентов (пусть даже равномерной) уменьшить количество машин впятеро, то результаты могут быть плачевными.
Но дело даже не в этом, а в том, что если при нагрузке по CPU в 10-20 процентов (пусть даже равномерной) уменьшить количество машин впятеро, то результаты могут быть плачевными.
почему Вы думаете, что доставка дольше обработки?
Потому что не у всех лежит оптоволокно, сюрприз? У меня до недавнего времени вообще было 384Kbit — страницу я жду СЕКУНДАМИ, а создаётся она за доли одной секунды.
при нагрузке по CPU в 10-20 процентов...
Нагрузке ЧЬЕГО CPU? Базы? Веб? Балансировщика?
Ну Вы же не единственный :) Почему же говорите за всех? Еще раз, совершенно непонятно, сколько времени создаётся какая-то произвольная страница. Может, 20 микросекунд, а может 20 секунд.
Чьего? Да любого. Скорее всего, (очень грубо приближая) при уменьшении количества серверов в произвольной подсистеме впятеро, утилизация каждого примерно в пятеро и возрастет. А при высокой утилизации время отклика может оказаться катастрофически большим.
Чьего? Да любого. Скорее всего, (очень грубо приближая) при уменьшении количества серверов в произвольной подсистеме впятеро, утилизация каждого примерно в пятеро и возрастет. А при высокой утилизации время отклика может оказаться катастрофически большим.
Ну Вы же не единственный :) Почему же говорите за всех?
Не надо перевирать слова — процитируйте, где я говорю «у всех медленный интернет»?
Я не единственный, но по вашей узкой логике я должен создать опрос всем 3 миллиардам Интернет юзеров — так что ли? Или вас устроит допущение, что Интернет всё-таки не самая шустрая часть коммуникаций? (что намного ближе к правде)
Вот для примера сайт ixbt.com — я ТРИНАДЦАТЬ СЕКУНД ждал загрузки сайта на 2Мбит ADSL. И что вы умничаете? Хотите сказать, что у большинства людей интернет такой шустрый, что может загрузить его менее, чем за секунду?! Вот и не надо тыкать очевидной чушью — ДОСТАВКА — МЕДЛЕННАЯ, точка. Поэтому подсчёт 50 микросекунд или 60 — бессмысленный, главное — каналы.
при уменьшении количества серверов в произвольной подсистеме впятеро
Можно не в пятеро, но то, что уменьшить можно — факт. Держат их чисто «на всякий» для пиковой нагрузки — тут никто спорить не будет.
Я даже больше скажу: ничего с юзером не случится, если сайт приедет на секунду позже — вон, я 13 секунд ждал, потому что это инфа, которая мне необходима (а ещё потому, что я начинал с 2КБ/с тырнета :)) ).
Судя по информации на их сайте для тестирования скорости подключения, большинство их страниц грузятся менее 100ms, а некоторые — менее 40ms.
Ничего не произойдет. Современный серв средней руки потянет 100-150 запросов в секунду (просмотров страниц),
если конечно вы не будете в каждом запросе считать Пи и писали не криворукие программисты.
если конечно вы не будете в каждом запросе считать Пи и писали не криворукие программисты.
> 560 000 000 / 25 серверов
Чукча не читатель, чукча писатель? © :) Там только 11 из них IIS. Ну и показ != request (если только вся страница не один файл)
Чукча не читатель, чукча писатель? © :) Там только 11 из них IIS. Ну и показ != request (если только вся страница не один файл)
Желаем toster'у соизмеримых цифр и схожего по качеству контента.
Гораздо более интересная и полная статья (с хорошей критикой их архитектуры в комментариях): habrahabr.ru/post/203406/
Приятно, что на продуктах МС делают не только тормознутых монстров вроде msdn (классный сайт, очень часто выручает, но скорость загрузки, особенно первой, при обращении в live id, составляет 5-10 секунд), но и таких, которые спокойно можно смотреть даже с мобильника в полной версии.
Не совсем понимаю, почему «приятность» должна возникать, когда речь идёт о некой фирме, делающей веб-сервер. Приятно — это когда гордость за отечественный автопром, например :) а тут что?
Удивляет SSD в RAID 1.
Вообще SSD удивляет. Может конечно я из другой эпохи, но по мне так пока еще надежнее использовать для бд рейд 10 из SAS дисков. А ssd разве что в качестве кеша для этого же рейда.
Удивляет что решение сделано на MS. А наличие 2х ASA и 2х маршрутизаторов еще больше удивляет. Почему нельзя было использовать инфраструктуру дц? 11 веб серверов на IIS полагаю вообще можно было парой на NginX'e заменить. Хотя IIS позволяет кешировать все нельзя, чем хвастается МС частенько на конференциях, показывая супер производительность. (может информация устаревшая, последний раз на «ремиксах» это видел, потом судьба от МС далеко увела. )
Удивляет что решение сделано на MS. А наличие 2х ASA и 2х маршрутизаторов еще больше удивляет. Почему нельзя было использовать инфраструктуру дц? 11 веб серверов на IIS полагаю вообще можно было парой на NginX'e заменить. Хотя IIS позволяет кешировать все нельзя, чем хвастается МС частенько на конференциях, показывая супер производительность. (может информация устаревшая, последний раз на «ремиксах» это видел, потом судьба от МС далеко увела. )
«цифры, сестра!»
Фраза «по мне так пока еще надежнее» — странная. Вообще там много аргументов в пользу большей надёжности того или иного решения. Из плюсов твердотельных — в SSD нету механики, что может быть существенно при активной работе.
Измерять, измерять и ещё раз измерять! Собирать или искать статистику по выходу из строя, в данном случае.
Фраза «по мне так пока еще надежнее» — странная. Вообще там много аргументов в пользу большей надёжности того или иного решения. Из плюсов твердотельных — в SSD нету механики, что может быть существенно при активной работе.
Измерять, измерять и ещё раз измерять! Собирать или искать статистику по выходу из строя, в данном случае.
Год назад мне пара хостеров дала статистику что под нагрузкой ssd не живут более полугода. Для меня это весомый аргумент, если для сравнения SAS hdd живут по 3-5 лет.
1. Нужно брать правильные SSD. Есть закрытые исследования на эту тему, говорящие, что только 10-15 процентов «промышленных» SSD реально являются таковыми. Остальные дохнут, да.
2. Я не уверен, что надёжность — это проблема. Точнее так: это не всегда проблема.Можно говорить не о надёжности отдельных дисков, а о надежности всего решения/хранилища на их базе. При тысячах серверов, как у тех же Одноклассников, которых тут в топике упоминали, выход SSD, HDD, да хоть целой стойки из строя — вообще штатная ситуация.
2. Я не уверен, что надёжность — это проблема. Точнее так: это не всегда проблема.Можно говорить не о надёжности отдельных дисков, а о надежности всего решения/хранилища на их базе. При тысячах серверов, как у тех же Одноклассников, которых тут в топике упоминали, выход SSD, HDD, да хоть целой стойки из строя — вообще штатная ситуация.
Я не говорю о штатности ситуации. Естественно в любом проекте выше чем домашний должно быть резервирование, и отказоустойчивость. Я говорю лишь о том что это выходит накладно на данный момент.
Есть еще один вопрос который мне кажется важным. Положим у нас небольшой проект и ну положим 1 сервер на бд мастер и один слейв. Помоему штатная ситуация. Заморачиваться с мастер-мастер не всегда просто или доступно.
И так у нас нагруженная бд которая постоянно дергает на запись рейд из 4 дисков. Так же у нас положим парочкав в spare.
Есть такая статистика которая рассказывает что жесткие диски выпущенные в одно время с одного завода зачастую выходят из строя разом. (сам 2 раза встречал такое что 4 диска сдохли за неделю.). И так у нас рейд из 4х SSD и 2х запасных. На них постоянная нагрузка на запись, которая ко всему прочему равномерна распределена на все диски. Вопрос каков шанс что 2 диска да еще и те что являются разными частями страйпа в зеркале например вылетят до того как отсинкается 2 запасных SSD?
Имхо шанс что вылетят из строя обычные харды одновременно пока что сильно меньше чем ssd.
И да это можно пережить, переключить мастера на другой сервер, раскатать из бекапа копию сервера, подключить как слейв, отсинкать и жить спокойно еще года… два-три? год? пол года?
И я не пытаюсь навязать точку зрения что что-то лучше. Просто пытаюсь дать информацию для размышления. Плюс я понимаю что будущее явно не за HDD.
Есть еще один вопрос который мне кажется важным. Положим у нас небольшой проект и ну положим 1 сервер на бд мастер и один слейв. Помоему штатная ситуация. Заморачиваться с мастер-мастер не всегда просто или доступно.
И так у нас нагруженная бд которая постоянно дергает на запись рейд из 4 дисков. Так же у нас положим парочкав в spare.
Есть такая статистика которая рассказывает что жесткие диски выпущенные в одно время с одного завода зачастую выходят из строя разом. (сам 2 раза встречал такое что 4 диска сдохли за неделю.). И так у нас рейд из 4х SSD и 2х запасных. На них постоянная нагрузка на запись, которая ко всему прочему равномерна распределена на все диски. Вопрос каков шанс что 2 диска да еще и те что являются разными частями страйпа в зеркале например вылетят до того как отсинкается 2 запасных SSD?
Имхо шанс что вылетят из строя обычные харды одновременно пока что сильно меньше чем ssd.
И да это можно пережить, переключить мастера на другой сервер, раскатать из бекапа копию сервера, подключить как слейв, отсинкать и жить спокойно еще года… два-три? год? пол года?
И я не пытаюсь навязать точку зрения что что-то лучше. Просто пытаюсь дать информацию для размышления. Плюс я понимаю что будущее явно не за HDD.
Про HDD — Вы правы, но только наполовину :) Да, есть корреляция между принадлежности дисков одной серии и одновременным выходом из строя. Фокус в том, что во-первых, мало кто ставит в RAID разные диски, и поэтому мы мыло знаем об одновременном выходе из строя разных дисков. Во-вторых, часто выход из строя вызван какой-то внешней причиной: скачком напряжения, перегревом, попаданием жидкости и.т.п. Если диски одинаковые — они имеют одинаковые уязвимости.
Если, например, при нагреве до 60 градусов первый диск, имеющий лимит по температуре 55 градусов, выходит из строя, то с высокой вероятность второй такой же диск тоже выйдет из строя — именно потому, что он отреагирует на внешнее воздействие (перегрев) так же как первый. Если же например у второго диска (другой марки, другой серии) температурный порог другой (например, не 55 градусов, а 65), то он продолжит работать.
Если, например, при нагреве до 60 градусов первый диск, имеющий лимит по температуре 55 градусов, выходит из строя, то с высокой вероятность второй такой же диск тоже выйдет из строя — именно потому, что он отреагирует на внешнее воздействие (перегрев) так же как первый. Если же например у второго диска (другой марки, другой серии) температурный порог другой (например, не 55 градусов, а 65), то он продолжит работать.
Многие страницы на СО можно натурально в html кэшировать и отдавать фронтендом сразу без бекенда.
Сегодня он падал кстати минут на 20.
Как бы то ни было (это моё впечатление от вышеприведённых критических комментариев), но когда ищешь решение проблемы в программинге при помощи гугла, то наверно где-то в 95% случаев ответ находится на SO.
И ссылка в топе гугла.
Так что тут можно только порадоваться за тех, кто сделал эту систему.
От себя лично — ни разу не замечал просадок во времени реакции.
Может мне так везёт :)
И ссылка в топе гугла.
Так что тут можно только порадоваться за тех, кто сделал эту систему.
От себя лично — ни разу не замечал просадок во времени реакции.
Может мне так везёт :)
Было бы намного интереснее и полезнее посмотреть на схему архитектуры.
Что-нибудь вроде такого blog.serverfault.com/2011/09/30/the-stack-exchange-architecture-2011-edition-episode-1/ или такого blog.stackoverflow.com/2010/01/stack-overflow-network-configuration/
Есть такая информация?
habrastorage.org/getpro/habr/comment_images/86f/60f/fa2/86f60ffa2f6d4c214641b050fcfc51f0.png
Что-нибудь вроде такого blog.serverfault.com/2011/09/30/the-stack-exchange-architecture-2011-edition-episode-1/ или такого blog.stackoverflow.com/2010/01/stack-overflow-network-configuration/
Есть такая информация?
habrastorage.org/getpro/habr/comment_images/86f/60f/fa2/86f60ffa2f6d4c214641b050fcfc51f0.png
2 ТБ данных SQL на SSD-дисках
Забавно! У меня на рабочей машине только файлопомойка 4ТБ + обычные диски и SSD :)
read-write 40:60
Как уже сказали, «чукча — писатель»? :) Странновато вообще-то… Туда ж ходят за ответами, а не блеснуть умом.
3 сервера приложений с движком для поиска по тегам
А смысл? Теги вообще кэшировать можно, держа в отдельной БД.
для работы StackOverflow хватает всего 25 серверов
Если уж эпатировать публику, там бы и двух хватило! :) 216 просмотров в секунду + контент сильно статический.
Постоянные голосования, редактирование ответов и вопросов, переразметка тэгов, аччивки и прочее — не такой уж и статический контент там.
Когда страница с вопросом создана, большинство её просто читают, ответы пишут единицы (что очевидно), ставят «лайки» — тоже не миллионы (посмотри типичный счётчик самого лучшего ответа). Более того — с ajax'ом вообще надобность в пересоздании страницы резко уменьшается. Скажем, лайк — ты его нажал, на сервер ушёл запрос-обновление (краткий), но вся страница всё равно не обновляется — тупо меняется счётчик у клиента. И только если ещё раз страницу запросили, она пересоздаётся и используется до очередного лайка. Облако тегов — вообще подключается через SSI (я не про SO, а в теории) — оно не вычисляется на каждый чих и спокойно шарится всеми страницами.
Тут в чём тонкость: 1) ответы пишут намного реже, чем читают 2) Контент не критичен к запаздыванию (можно лишний раз и не пересчитывать теги) 3) AJAX 4) куча сторонних серверов, способных прекалькулировать данные без нагрузки основных веб-серваков.
В общем, если с головой подойти, то куча динамических с виду вещей становится вполне статической :)
Тут в чём тонкость: 1) ответы пишут намного реже, чем читают 2) Контент не критичен к запаздыванию (можно лишний раз и не пересчитывать теги) 3) AJAX 4) куча сторонних серверов, способных прекалькулировать данные без нагрузки основных веб-серваков.
В общем, если с головой подойти, то куча динамических с виду вещей становится вполне статической :)
Вы забываете про модераторский раздел, где как раз и редактируют, и флаги ставят, и прочее, прочее.
И там как раз контент критичен к запаздыванию, так как человек ждёт пост, который надо проверить.
И там как раз контент критичен к запаздыванию, так как человек ждёт пост, который надо проверить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
StackOverflow: 560 млн показов в месяц, 25 серверов