Тоже что и все, когда текущая конфигурация перестает справляться с нагрузкой.

Что значит бороться с резкими скачками, объясни? Мы либо снижаем нагрузку на железо, не важно каким способом, либо нет. В случае успеха она снижается в процентах. Причем тут скачки или прыжки. =)

highload - это со-сто-я-ни-е проекта, негативное. Этим не хвастаются, с этим борются, вы мне все время говорите о методах борьбы, они правильные, да.

Да это все-равно, если нагрузка не превышает 60% в пиках и те и другие молодцы и предпринимают адекватные меры. У одних команда подороже, у других железо, с точки зрения бизнеса еще неизвестно что лучше! ) А технически, я уже сказал, они с задачей справились. ) Нюанс. В случае с 5-ю серверами решить задачу с разгрузкой скорее всего будет значительно легче. Просто нанять эксперта на пару дней. Значит в сухом остатке имеем, что команда с более дорогой серверной заведомо в более выгодном положении.

Надо шире смотреть на ситуацию! =)

Оптимальность да, когда нагрузка держится в разумных пределах. Когда она выходит на highload, то уже, извини, не оптимальность, а глупость.

Так я и говорю что всё познаётся в сравнении.

Ни разу не слышал про "проект очень востребован", это вообще не имеет отношения к нагрузкам. Он может быть очень востребован одним пользователем.

twin

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Нет, ты заблуждаешься, собственно как и Ron. Вы путаете высоко нагруженный проект и нагрузку на отдельный сервер. Ты, в частности, имеешь ввиду прпускную способность сервера(ов). А это не так.

Допустим проектируется какой-нибудь аналог твиттера. С сумашедшей инновацией. Маркетологи просчитали и спрогнозировали посещаемость 1 000 000 запрсов в сутки. Тут один подход - как к высоконагруженному проекту. Нужно расчитать возможности железа, спроектировать оптимальные алгоритмы, другими словами загрузить сервера так, чтобы они использовались оптимально. Но тут совсем не нужно думать о "пропускной способности". Ибо резерва в 10-15% от максимума вполне достаточно. Проектировать такую систему, чтобы она в пике потребляла 60% ресурса - крайне неразумно и расточительно.

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

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

От того и заблуждения Ron по поводу highload. Он просто никогда не имел дела с большими нагрузками, и думает, что можно так вот взять с плеча и расчитать "пропускную способность" так, чтобы был резерв в пике 40%. Это очень дорого и совершенно не нужно на проектах, когда посещаемость выходит за границу "средняя".

Так что highload highload'у рознь. Суметь удержать стабильную работу проекта с высокой посещаемостью, имея резерв в 10-15% - одно. Почти на пределе, но оптимально. Называя это "высоконагруженный проект".

А накупить серверов, сделать репликации и ждать, когда вдруг появится дополнительнй миллион посетителей в сутки, причем резко - это другое.

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

Какой подход по вашему профессиональнее?

Везде нужна оптимальность. А сдуру можно и...

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Да ладно)) Перелопатить весь код или просто добавить доплнительный камень - вот так выгода).
Оптимизировать всегда сложнее, нежели сделать репликацию.


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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Именно, вот тут ты абсолютно прав. Случилось что-то плохое и ты как программист эту проблему решаешь. А если тебе удалось решить её, то это галочка в твою копилку, что ты "работал с highload". В итоге если работодатель спросит тебя о HighLoad и работал ли ты с этими проектами, то он подразумевает именно сталкивался ли ты с подобной проблемой и исправлял ли её ранее. А данному словосочетанию употребляют много внимания лишь из-за того, чтобы подчеркнуть важность в нынешних реалиях уметь исправлять данную проблему, которая могла возникнуть даже по своей собственной невнимательности. Сам создал HighLoad, сам же и исправил проблему.
Когда я говорю о том, что я работал с HighLoad, то я подразумеваю, что я боролся с подобной проблемой и её победил.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

Тут важен критерий оценки возможного наступления highload. И вот тут как раз и важна "нагруженность" проекта. О чем ты и умилялся:

Вот у меня на работе действительно "высоконагруженный проект". Но сервера не падают, хотя я и не закладывал 60% в пике. Ну вот не нужно этого. 15% в гору от максимума, этого более чем достаточно.

Что касается оптимизации. Тут тоже подход может быть разным. Я предпочитаю писать максимально оптимальный код, такой, чтобы при угрозе highload, можно было с уверенностью сказать - нужны дополнительные мощности, так как оптимизация тут не поможет. Тут нечего оптимизировать.

Но не раньше того. Это еще и мне выгодно, обслуживать 5 серверов или 50.

Так что твой подход к оценке highload:

в свою очередь выжимает из меня слезу умиления. И белой зависти. Ты же наверняка с таким подходом имеешь неограниченный доступ к ресурсам. Эдакую "золотую кредитку".

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Тоже полно недоделанных проектов. Щас остановился на одном, решил дострочить его. Заглох на вебсокетах. Не могу понять структуру пакета. Как там данные распределяются, кодируются. Нубок я еще

brevis

Никогда в них не верил, ибо никогда то что в них было сказано, не сбывалось. Даже наоборот

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

Интересная история Раньше тоже хотел что то в unity поделать. Тяга была. Но останавливало то, что если что то и делать, то игру например, а чисто для себя не интересно. То есть сам придумал, и сам играешь. Значит что то нужно делать для всех. То есть типо сетевухи или квеста. А это уже другой уровень, и я подумал что его не потяну. Вот такая вот у меня логика, мда

Интересный тут спор развязался

Про это и разговор, нужно предусмотреть базовые возможности для возможного масштабирования проекта.

Посещаемость 1 000 000 запросов в сутки в момент запуска проекта никогда не будет. Возможно количество запросов будет ежедневно увеличиваться, для чего и нужно предпринимать различные действия, чтобы сайт выдерживал увеличивающиеся нагрузки и имел запас прочности.

У каждого своя правда

_____________
Принимаю заказы, писать в ЛС

Почему это? А если делится один с 2 000 000 на два равных?

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Если проект уже запущен и имеет указанную посещаемость, и на этом проекте запускается новый "раздел сайта", вполне возможно и 1 000 000 запросов в сутки. Тогда, можно разрабатывать под средние нагрузки основного проекта.

_____________
Принимаю заказы, писать в ЛС

Очень узко мыслишь. Оптимизация может заключаться совершенно не в коде. =)

Вот и поделись ссылкой, тема вполне подходящая. =)

Имеем сильную команду из 5 человек, каждому платим по 150к в месяц. Или команду послабее, каждому платим по 80к, зато снимем/купим на 2 сервера больше.

Кстати, вы считаете что хабра эффект можно назвать полезной нагрузкой, не понял?

Так это же ты написал:

Если оптимизировать железо, зачем нужен эксперт? Деньги нужны. Эксперт нужен для оптимизации кода.

Мне на эту тему всегда вспоминается чей то стишок.
Не имей сто рублей, не имей сто друзей, имей одного дружищу, которы даст тебе тыщщщщу.
Слабая команда и в других делах будет слабой. Скупой платит дважды.

Тема про поделки, а не про работу.

Иногда да. Допустим новогдняя распродажа. Проект должен быть готов к таким пикам. Но хабраэффект возможен только на сайтах с низкой посещаемостью. Там, где она высокая, резких скачков вверх не бывает.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Нет, эксперт может быть в области администрирования, оптимизирует конфиги. =) Эксперт может быть в области DB, поможет оптимизировать запросы без вмешательств в архитектуру, т.е. сравнительно дешево. Узко мыслишь, еще раз говорю.

Нет, это не хабрэффект: http://www.wikireality.ru/wiki/%D0%A5%D0%B...%B5%D0%BA%D1%82 он ничем не отличается от атаки DDoS ни с какой точки зрения.

Нет, сейчас facebook выпустит новую wow фишку, все попрутся на нее поглазеть и может наступить хабраэффект. Ты забываешь что у большого проекта есть постоянные посетители, а есть кто заходит время от времени.

<:-)