Мне интересно, кто то согласиться делать сайт под ключ за 300 баксов ?
Я бы и визитку за 800 делать не стал - не под то заточен производственный процесс.
Но если рассуждать здраво, то в общем и целом то сайт за 300 баксов сделать можно, если взять на себя весь менеджмент. Можно даже дешевле если взять готовый шаблончик и его подточить.
А подрядчиков тут отпугивает скорее отношение ТС. Я бы вот сразу определил данного клиента как проблемного и ценник бы умножил на полтора/два :)
В данный момент делаю тематический портал с функциональностью описанных. Если абстрагироваться от разработки (5К$ студентами-фрилансерами и в три раза дороже в нормальном формате) а только контент и пиар то на проект работают 8 человек не считая бухгалтерии и секретаря. 4 человека работают удалённо. Лидер проекта работает бесплатно(за доляшку). Ежемесячный бюджет ФОТ - примерно 8К$ + офис, телепоны, СЕО и всякая хрень.
Ого, сколько людей оказывается бьются над проблемой. Искренне рад что не я один вынужден был изобретать велосипеды.
Поговорим о куках, сессиях и кешере.
Суть кешера проста и незамысловата - отдать динамический контент который не изменился с последнего запроса к странице по данному адресу.
Использование куков и сессий, в большинстве случаев, направлено на идентификацию пользователя для статистических или аунтификационных действий.
Я этих два процесса разделяю. Данные на которые влияет аунтификация не попадают в кешер.
Технологических решений тут несколько, и они общеизвестны. Насколько снижается нагрузка на ситему при использовании кешера зависит от конкретного проекта. В медийных проектах эта снижение может доходить до 70%. В системах знакомств, например, использование кешера практически бессмысленно.
Что же касается отдачи статического контента то один сервер из топовой линейки пролиантов способен отдавать 4+ Гигабит контента(2 гигабита тестировали сами, про 4 можно экстраполировать) и да, этого теоретически хватит, что бы обеспечить работоспособность при названных мной объёмах.
Это если рассуждать о сферических конях в вакуме и рассматривать работоспособность сервера в отрыве от комплекса в целом. И мы именно так же и рассуждали.
На практике это сервер завалился в течении 30 минут после публикации о смерти Турчинского. Был проведён анализ, разбор полётов, наказание виновных и разработано решение, которое совершенно спокойно выдержало пик при последних взрывах в метро.
Не нужно мне рассказывать, что может или не может быть. мне об этом рассказывают пять лет опыта, пиковые нагрузки, три крупных ддос атаки и ошибки программеров. Мне ненужно ничего придумать и представлять и рассчитывать. Для потенциального клиента я могу ткнуть пальцем в работающую систему и показать статистику как яндекс-метрики по показам страничек так и графики загрузки процов и каналов.
netwind: зачем вы увиливаете от действительно интересных вопросов?
да всем пофигу, что там у вас куда масштабируется.
Я совершенно не увиливаю ни от каких вопросов. У кого есть задачи по моей теме - пишут в личку и я отвечаю на все интересующие их вопросы. А толпа "хостеров" отметившиеся в топике мне не клиенты и не конкуренты.. как вобщем-то и я им.
Я решаю достаточно узкий спектр задач описанный в названии темы.
Слава Шевцов: Отдача страниц на PHP великолепно распараллеливается, а именно это основная задача PHP и подавляющей части сайтов. Проблема там лишь в репликации базы и мемкеша. Кроме того, нужно явно указать мастер реплику для редактирования контента. Всё решается не программистскими, а админскими средствами.
Конечно, речь не о подавляющем большинстве сайтов на PHP, а не обо всех. Примеры проблемных типов сайтов вполне можно найти.
Если говорить об архитектуре решений то задачу следует разбить на 4 части:
1. Генерация динамического контента - решается поднятием кластера(для гурманов - грида) web-нод с балансом на железке или софтовом балансере и соответственно кластера мускуля.
2. Отдача динамического контента - умный кешер, работающий в связке с балансером.
3. Отдача статического контента - достаточно простое кешерное решение с ДНС-балансом
4. Обеспечение непрерывной работы, путём мониторинга всех серверов и выкидывания перегруженные или неработоспособных из опроса.
Ну и отдельно конечно нужно сказать, что чем лучше интернет связанность и чем быстрее отдаётся контент - тем менее нагружена система.
Наше решение работоспособно при нагрузке в 6 миллионов страниц информационного портала в день. Ну и маштабируемо примерно троекратно без перестраивания архитектуры.
Мне интересно, кто то согласиться делать сайт под ключ за 300 баксов ?
Я бы и визитку за 800 делать не стал - не под то заточен производственный процесс.
Но если рассуждать здраво, то в общем и целом то сайт за 300 баксов сделать можно, если взять на себя весь менеджмент. Можно даже дешевле если взять готовый шаблончик и его подточить.
А подрядчиков тут отпугивает скорее отношение ТС. Я бы вот сразу определил данного клиента как проблемного и ценник бы умножил на полтора/два :)
В данный момент делаю тематический портал с функциональностью описанных. Если абстрагироваться от разработки (5К$ студентами-фрилансерами и в три раза дороже в нормальном формате) а только контент и пиар то на проект работают 8 человек не считая бухгалтерии и секретаря. 4 человека работают удалённо. Лидер проекта работает бесплатно(за доляшку). Ежемесячный бюджет ФОТ - примерно 8К$ + офис, телепоны, СЕО и всякая хрень.
Проект делается в Москве.
Ого, сколько людей оказывается бьются над проблемой. Искренне рад что не я один вынужден был изобретать велосипеды.
Поговорим о куках, сессиях и кешере.
Суть кешера проста и незамысловата - отдать динамический контент который не изменился с последнего запроса к странице по данному адресу.
Использование куков и сессий, в большинстве случаев, направлено на идентификацию пользователя для статистических или аунтификационных действий.
Я этих два процесса разделяю. Данные на которые влияет аунтификация не попадают в кешер.
Технологических решений тут несколько, и они общеизвестны. Насколько снижается нагрузка на ситему при использовании кешера зависит от конкретного проекта. В медийных проектах эта снижение может доходить до 70%. В системах знакомств, например, использование кешера практически бессмысленно.
Что же касается отдачи статического контента то один сервер из топовой линейки пролиантов способен отдавать 4+ Гигабит контента(2 гигабита тестировали сами, про 4 можно экстраполировать) и да, этого теоретически хватит, что бы обеспечить работоспособность при названных мной объёмах.
Это если рассуждать о сферических конях в вакуме и рассматривать работоспособность сервера в отрыве от комплекса в целом. И мы именно так же и рассуждали.
На практике это сервер завалился в течении 30 минут после публикации о смерти Турчинского. Был проведён анализ, разбор полётов, наказание виновных и разработано решение, которое совершенно спокойно выдержало пик при последних взрывах в метро.
Не нужно мне рассказывать, что может или не может быть. мне об этом рассказывают пять лет опыта, пиковые нагрузки, три крупных ддос атаки и ошибки программеров. Мне ненужно ничего придумать и представлять и рассчитывать. Для потенциального клиента я могу ткнуть пальцем в работающую систему и показать статистику как яндекс-метрики по показам страничек так и графики загрузки процов и каналов.
а на куку он как реагирует? :)
Кешер ? никак конечно..
а как быть с маленьким TTL А/CNAME записей?
для того, что находится за балансером это неважно ..
все остальные сервера (баланса и статики) резервированы N+2 и выкидываются из опроса заменой айпишников (АСка в наших руках!! :) )
ну для раздачи статики в таком объеме и одного сервера достаточно.
Меня всегда умиляют теоретические размышления на эмпирические темы.
Можно пожалуйста переформулировать техническим языком? Как только переформулируете сами поймете какая это ересь.
Я честно сказать не знаю как переформулировать это ещё более техническим языком :)
Или Вы просите меня расписать Вам структуру типичной связки мускуль+пхп+дженикс на которой построены подавляющее количество веб серверов?
зачем вы увиливаете от действительно интересных вопросов?
да всем пофигу, что там у вас куда масштабируется.
Я совершенно не увиливаю ни от каких вопросов. У кого есть задачи по моей теме - пишут в личку и я отвечаю на все интересующие их вопросы. А толпа "хостеров" отметившиеся в топике мне не клиенты и не конкуренты.. как вобщем-то и я им.
Я решаю достаточно узкий спектр задач описанный в названии темы.
Отдача страниц на PHP великолепно распараллеливается, а именно это основная задача PHP и подавляющей части сайтов. Проблема там лишь в репликации базы и мемкеша. Кроме того, нужно явно указать мастер реплику для редактирования контента. Всё решается не программистскими, а админскими средствами.
Конечно, речь не о подавляющем большинстве сайтов на PHP, а не обо всех. Примеры проблемных типов сайтов вполне можно найти.
Если говорить об архитектуре решений то задачу следует разбить на 4 части:
1. Генерация динамического контента - решается поднятием кластера(для гурманов - грида) web-нод с балансом на железке или софтовом балансере и соответственно кластера мускуля.
2. Отдача динамического контента - умный кешер, работающий в связке с балансером.
3. Отдача статического контента - достаточно простое кешерное решение с ДНС-балансом
4. Обеспечение непрерывной работы, путём мониторинга всех серверов и выкидывания перегруженные или неработоспособных из опроса.
Ну и отдельно конечно нужно сказать, что чем лучше интернет связанность и чем быстрее отдаётся контент - тем менее нагружена система.
Наше решение работоспособно при нагрузке в 6 миллионов страниц информационного портала в день. Ну и маштабируемо примерно троекратно без перестраивания архитектуры.
Во как круто. Возьму на заметку и буду так же про компании писать, чьё руководство я знаю:)
Ссылка на копирайтера обязательна !
Действительно. Как мы прочитали приватный топик? Тут филанко шлют к Шарову - больше ничего :)
больше сообщений в тему ! качнём топик !
Видимо "авторитет" какой-то :)
P.S.: Интересный топик, где всё нужно спрашивать у какого-то Шарова...
Ну зачем, я буду рассказывать всё каждому менеджеру компании филанко, если общаюсь с его руководством.