highload проекты

Здравствуйте. Иногда встречаю такой термин, я так понимаю это те проекты, где очень много посетителей. Типа 100500 авторизаций и действий в секунду и т.п

Так вот в чем собственно вопрос, начиная с какой цифры "одновременного" посещения к примеру главной страницы можно назвать проект highload-овым? Хотя бы приблизительно.

Я в серьез обеспокоен данным вопросом и вообще без понятия в какую сторону нужно смотреть. Некоторые рекомендуют выделять несколько серверов для проекта, даже вычитал в книже(если ничего не напутал), что для хранений sessID выделяют отдельный сервер. Вообщем инфы полно, всякие расширения, какие то непонятные функции работающие на уровне ОС и всё такое. Глаза разбежались, чего учить, для чего читать - не понятно. Более того недостаточно выучить, надо ещё умудриться спроектировать нагрузку очень грамотно. Вообщем хаос. - Что посоветуете делать со всем этим добром? Куда смотреть, чего читать, хотя бы для старта. В добавок ко всему когда нахожу что то на эту тему, все написано на "заумном" языке на столько, что если бы данная речь не была связана с программированием а являлась бы обычной повседневной речью, то её тоже было бы сложно понять Ну вы поняли о чем я... Где то в глубине души я надеюсь, что всё это для хостеров, а не для меня )) Т.е они оптимизируют свои услуги, а я за это плачу... или нет?

+ вопрос, есть ли к примеру сервисы, которые принимают всю ответственность по нагрузке на себя? Т.е что бы залить файл со скриптами и нормально чтоб работало даже при большом кол-ве посещений, не абсолютно, но от части чтоб взяли на себя нагрузку. Хостинги может особые... Понятное дело многое зависит от того как написано приложение, но все же...

В добавок ещё интересует ответ на след. вопрос: Если допустим у меня обычный хостинг, в скриптах ничего особенного нет, страницы которые меняются раз в 100 лет закешированы, не закешированы скрипты работающие с аяксом ну и MySQL насколько я сам кеширует частые запросы, остальные страницы кешируются тоже, но если контент был обновлен, тогда уже инфа берется с сервера, если нет - берется из кеша - такой подход на обычном хостинге какую нагрузку может выдержать? Т.е приблизительно от какого кол-ва одновременных посещений страницы сайт может "лечь" ? Допустим эта цифра 1000 пользователей(прошу назвать приблизительную), насколько изменился эта цифра(приблизительно) если пользователи не просто посетили главную страницу, но ещё что то сделали на сайте либо если это те посетители которые постоянно чем то заняты на сайте.

Надеюсь вы меня поняли

Буду рад выслушать каждого
(Добавление)
Так же если у вас был опыт удачи/неудачи в подобных проектах, хотел бы послушать небольшой рассказ про эти случаи(желательно обучающего характера)

(Отредактировано автором: 16 Августа, 2013 - 01:03:44)

HighLoad - высокая нагрузка.
Шаражкины конторки пишут данное в своих объявлениях лишь по одной причине - хотят найти грамотного спеца. На самом деле всё прозаично: 3-4 сайта, у которых суммарное количество посетителей равняется цифре 100. Заходил я в "недра" такой конторы. У высших* специалистов даже терминология хромает.


Это является глубочайшим заблуждением. Не все приложения строятся лишь для пользователей.


Цифр нет — есть статистика по определённому приложению. Не хватает ресурсов? Нужна разгрузка серверов? Сервер кеша и несколько серверов хранилища, которые построены на Raid массивах? Назовёмся HighLoad Project


Данила бы подтвердил данное утверждение.
Для сайта знакомств села Пупырышкино было выделено 3 сервера. Численность людских голов - 5000, из них пользуются Интернет 43% жителей. Из пользующихся 80% женаты, 20% сидят за кражи. "А зачем нам три сервера?" — спросил старший ассенизатор — "Так сказал программист из Москвы!" — ответила ему Маша-продавщица из салона "Кутюрье не по годам".


Опять таки всё зависит от конфигурации сервера, пропускной способности канала и возможных ошибок программы. Нет конкретных цифр.


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

Думаю, что здесь есть несколько людей, которые в действительности работали (работают) с HighLoad

Кстати я так полагаю все сводится к запросам к серверу и чем объемнее запрашиваемый ресурс тем больше нагрузки... Хотелось бы узнать ньюансы, желательно в цифрах, хотя бы приблизительных...

Вообщем топик представляет кашу и я это понимаю. Но надеюсь опытные разработчики смогут уловить суть и объяснить мне хоть от части что к чему
(Добавление)
avtor.fox
ща выкурю все что вы написали и отпишу ))
(Добавление)

А где можно посмотреть на ресы, какие они изначально, сколько затрачивает ресурсов та или иная операция, тестировать в общем. Как определить что ресурсы подходят к концу и нужен дополнительный сервер

Где можно прочитать про подводные камни, на какую тему гуглить... Я столько всего видел(читал, но мало что понял) - для меня этот пусть кажется очень долгим и с сотнями ньюансов... или я преувеличиваю?

(Отредактировано автором: 16 Августа, 2013 - 02:24:28)

я вот сейчас проверил своего хостера. (джино.ру, не реклама , аккаунт самый обычный, за 150 рэ в месяц)
цикл из 15000 запросов на вставку
цикл из 15000 запросов на выборку
таблица простая - ID автоинкремент и TEST - varchar INNODB
на инсертах хостер заблокировал доступ к БД на несколько минут
селекты прошли.
(Добавление)

В панелях управления хостингами есть монитор ресурсов. А если у вас будет свой собсвенный сервер, то таких вопросов уже не возникнет

-----
Чем больше узнаю, тем больше я не знаю.

Как то я немного разгрузился... я слышал есть ещё всякие VPS(с хостерами пока не дружу, поэтому могу ошибаться) которые по мощнее чем обычные хостинги и стоят дороже на 10-15 долларов - отличие сильное по обработке запросов к серверу?

И кстати по поводу твоих тестов - это разок только я так понял... а если стабильно - могут наверное и навсегда заблокировать акк?

Может вопросы задаю глупые - не судите строго, для меня это новая тема

(Отредактировано автором: 16 Августа, 2013 - 02:36:18)

Прайс лист - при покупке сервера или на арендуемой площадке. Всё это указывается: память, камни, жёсткие диски, материнка.


Только тестирование в более-менее полной мере даст понять возможности сервер+приложение. Но и сам разработчик во время работы хоть немного, но должен знать ресурсозатраты своего творения которое помножено на ускорение.


Если в Вашем приложении ресурсы подходят к концу, то стоит всё бросить и начать писать проект заново. Как Вы собираетесь "впихнуть" дополнительный сервер? Приложение готово для расширения? А если и второй сервер начнёт загибаться при среднем пике?

Для этого есть сервера разгрузки, они должны знать какой из серверов-обработчиков упадёт при дополнительных 100 подключениях и в таком случае они просто перекинут нагрузку следующих 100 подключений на другие сервера (примерно). В крупных проектах используются целые сети из всевозможного рода (задач) серверов. И у них расширение* ресурсов выглядит следующим образом: принёс железо - впихнул - работает.

Я не знаю, что Вам нужно почитать для выявления подводных камней, по моему такой литературы просто не существует. Только реальный опыт, ошибки и неудачи в полной мере дадут знания (некоторое наслаждение от работы).

.
Пока не знаю. Но читая в гугле встречал что "впихивают". Ведь не каждый админ мог знать что когда то его сайт будет хорошо востребован. Думаю все начинали с одного сервера, а потом уже при необходимости расширяли объем своих ресурсов


Да-да, встречал подобное в одной из прочитанных статей... ещё картинка была помню как происходит распределение нагрузки...

Благодарю за ответы, хоть что то стало прояснятся...

От ответов остальных разработчиков не откажусь, хочу почитать всех )) ну тех, кто понимает что то в данной теме и сделать конечный вывод

(Отредактировано автором: 16 Августа, 2013 - 02:42:02)

Верно, есть такое в пользовательском соглашении.
Для увеличенных нагрузок рекомендют купить премиум акк с выделенным сервером.

А еще на графике загрузки CPU в ПУ есть красная полоска, переступать которую ни-ни (это к вопросу о том, где смотреть сколько жрет ресурсов твое приложение)

-----
Чем больше узнаю, тем больше я не знаю.

Тоесть с точки зрения разработчика сайта все ложится на плечи хостера относительно нагрузок? Чем больше платишь - тем больше ресов выделяется. А если хочется собственный сервак - то марш учить все эти внутренности? Я правильно понимаю?

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

Учтите, что мое мнение, - всего лишь мнение. Я не разрабатываю хай-лоад проекты )

-----
Чем больше узнаю, тем больше я не знаю.

Привет. Попробую ответить хотя бы на часть твоих вопросов

Это очень расплывчатое понятие, на равне с "говнокод", примерно. У каждого программсита своя оценка. Сам подумай, .html страничка, лежащая на народе может отдаваться при нагрузке в сотни, если не тысячи запросов в секунду, можно ли считать ее highload-овым проектом? а если к странице оформления заказа интернет-магазина идет такой же поток запросов?

Это нужно делать ровно тогда, когда тебе это нужно (один сервер не справляется, нагрузка на хранилище сессий слишком велика и мешает выполнению остального кода) Странно, правда? А вот сделать так, что бы это было легко реализуемым, надо заранее.

Я не очень понимаю, что значит проектировать нагрузку? Есть четкие правила построения распределенных систем, надо их знать и программировать исходя из этих правил (если вы хотите в итоге иметь распределенную систему)

...

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

такой цифры нет, все это относительно...


все делается по мере необходимости... рекомендую почитать про масштабирование веб-приложение, думаю сразу станет все ясно

http://habrahabr[dot]ru/post/113992/
высконагруженные приложения развертывают на выделенных серверах... опять же возвращаемся к масштабированию приложения.


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

Сейчас хайлоадом неофициально считается нагрузка от 150 rps.
Замечу - нет понятия посетители. Есть понятие запросы в секунду (rps). И стоимость этих запросов.
(ещё есть понятие бабло-в-секунду, которое решает вопросы с наймом специалистов и покупкой дополнительных мощностей)


Модные нынче облака такое декларируют. Но это будет дорого. И лимит всё равно 1 железная машина. Прозрачно от приложения масштабироваться на несколько машин сложно, но главное - неэффективно. Сеть медленная.


Мониторинг. И тренды графиков нагрузки. Всё. Универсальная вещь.


Разница в чём - на шареде хостер как-то сам решает, какая нагрузка ему допустима. И вырубает того, кто мешает работать многим другим.
VPS - вам дан объём ресурсов машины, на которые вы всегда можете рассчитывать. (если это не так - меняйте хостера)
А так же дан рутовый пароль и вы можете творить и тюнинговать параметры под свою задачу как заблагорассудится. Но и все косяки уже только на вас.


Разгадка проста - каждый хайлоад по-своему уникален. Нет серебряной пули, какому-то проекту подходит архитектура, но другому проекту эта архитектура не подойдёт в принципе.

Шаред, одиночная виртуалка, одиночный сервер - это всё вертикальное масштабирование. Дешевле купить машинку мощнее.
Хайлоад ставит вопрос: что дальше? Что вы со своим проектом будете делать, если даже дофигапроцессорный сервер с террабайтом-другим RAM да рейдом на быстрейших SSD не справится с нагрузкой? Даже если у вас есть такие дикие деньги? Куда расти? Закрывать проект с фразой "извините, мы не выдержим такую нагрузку"?
Нет, делается горизонтальное масштабирование. Об этом приложение знать должно.
Вынести сервер СУБД на отдельную машину - легко. Параметры доступа только поменять.
Разделить фронтенд и бекэнд на разные машины? Тоже несложно.
Добавить ещё один сервер бекенда. Необходимо решить вопрос с доступностью тех же сессий. Найти, в чём ещё ваше приложение нарушает изолированность каждого запроса от окружения и так же как-то это урегулировать. Дальше бекенды при необходимости наращиваются до некоторого предела легко. Начали по мониторингу жрать 80% CPU или памяти - добавить ещё машинку.
Не хватает ресурсов чтения СУБД - городить мастер-слейв реплику. Всё ваше приложение придётся научить писать на одну машину, а читать - с других. Иметь в виду, что не все запросы могут реплицироваться, иметь в виду задержку репликации (небольшую, но есть).
Не хватает ресурсов записи СУБД - у вас большая проблема. До некоторой поры кэширование нивелирует заметность проблемы, но без существенной доработки задача не решается. Нужно делить базу на части и размещать на разных машинах (возможно, со своими слейвами)
У меня ещё нет проекта, достойного называться высоконагруженным. Во что можно упереться дальше - не знаю. Наверное, в сеть.

Как безболезненно выдерживать поломку любой машины - вопрос high available. Родственен, но своих тараканов много.

-----
PostgreSQL DBA

Есть неплохая (для задающихся такими вопросами ТС, а не для профессионалов) книга, — Искусство планирования мощностей (загуглите). Вот там комплексные ответы на ваши вопросы, ТС, и конкретные методики и софт для расчета нагрузок, подходы к тестированию интернет-приложений и многое другое.
На ваш вопрос нельзя дать однозначный ответ, даже "примерный", потому что все индивидуально и зависит от конкретного проекта и задач им решаемых. Если разбегаются глаза и не знаете "куда ходить и чего читать", прочтите нечто базовое, указанное выше и будет общее понимание порядка действий а не каша в голове.

Первое о чем нужно забыть при серьёзном подходе оценки производительности приложения, — это слово "приблизительно".

(Отредактировано автором: 16 Августа, 2013 - 10:43:46)

Может я не совсем правильно выразился, но этим я хотел сказать, что то вроде "Мой сайт должен уметь выдерживать большие нагрузки - от чего конкретно это зависит?"


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


Я стараюсь изучать как можно больше про создание сайтов и меня интересует каждый вопрос...

Silver Soft
Спасибо за ссылку, я обязательно прочитаю ее содержимое.

Мелкий
Спасибо, вполне доступное объяснение. Даже в ответ написать нечего

Zuldek
Благодарю, я почитаю скорее всего

Если честно, меня беспокоил этот вопрос потому, что я думал без этих знаний делать хотя бы нормальные сайты где посещений 5-10к в сутки - не светит. Подумал так потому что в прошлом(ещё до того как я занялся созданием сайтов) я админил небольшой сайт знакомого. Так вот там при одновременной авторизации 50-60 человек сайт лёг сразу... цифра мелкая, вот я и вспомнил и озадачился. Видимо хостинг оставлял желать лучшего... или скрипты были кривые а-ля запросы из разряда "цикл в цикле"

(Отредактировано автором: 16 Августа, 2013 - 13:41:05)