- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Присущ, слово "кэш" Вам не знакомо?
Присущ, слово "кэш" Вам не знакомо?
Ну если вы всем запросам хотите отдать 100% кеш, то и проблемы для обсуждения нет. А раз вынесено к обсуждению, значит не катит такое решение.
Примерно можно сделать бы так:
1. Сервера с сайтом. Можно использовать nginx как балансировщик. + сами сервера уже непосредственно с сайтом.
2. MySQL (основной+резервные, также с Heartbeet)
3. Возможно Redis (если он требуется), какие-либо инструменты для кеширования
4. Heartbeet - для смены ip адресов если сервер упал.
+ самодельные скрипты для синхронизации (к примеру, если 1 сервер или диск был на тех.работах и его надо синхронизировать) и т.д.
Всё это связать более менее в связку (и лучше в разных ДЦ, хотя бы 2 дц) - и всё будет окей я думаю. По-крайней мере похожую (но более усложнённую) схему используют многие файлообменики (пруфов не просить :) )
В первую очередь, я бы уточнил цифру до реальной, т.к. указанная сопоставима с нагрузкой на порталы типа facebook и, естественно, не решается "штатными" способами.
Вы странно рассуждаете как и половина отписавшихся в этом топике, я что написал "как путем одного сервера P3 / 512 RAM обслужить 10к соединений в секунду?" Я задал вполне конкретный вопрос, да у меня может быть фейсбук2 или вк2 или google2 как угодно считайте, как то, что пишите вы отвечает на мои вопросы или хоть как-то касается темы: специально для вас уточняю реальные цифры : 10.000 в секунду.
---------- Добавлено 03.08.2014 в 23:38 ----------
Несмотря на поставленные условия, мы то знаем, что у вас нет ресурса с объявленными характеристиками посещаемости и одновременно "дефолтной " архитектурой. При такой заведомо ложной информации, можно было и ожидать существенную долю иронии в сообщениях оппонентов.
Согласен с вами лишь в том, что посещаемость + дефолт несовместимы, в остальным как бы... ресурс вполне себе есть, пусть и теоретически, но что бы он стал практическим, нужны понимания на чем его строить и как бы поступили другие, я в принципе и так понимал что штатным WP дело не обойдется, но теперь имею подтверждение в виде ваших слов и еще отписавшихся по сути...
Так же теперь вижу что у кого-то есть что-то похожее, кто-то до 2k в секунду доходил путем 5-6 серверов в определенной конфигурации....
Одно дело когда человек с 5 постами задает такие вопросы - ирония может быть уместна, в моем же случае - не понимаю зачем иронизировать, ведь я спрашиваю для того что бы реализовывать, вопросы коллег могут быть не совсем корректные, но ирония тут не уместна IMHO.
---------- Добавлено 03.08.2014 в 23:38 ----------
Да и если к Вам пришел стартап, который хочет на вордпрессе держать 10к запросов в секунду, пускай сначала добьются хотя бы 10-20 запросов в секунду, после этого можно думать о масштабировании. Скорее всего они обломаются даже на этапе раскрутки. Видели таких (;
К нам никто не приходил :) НЕ додумывайте, задание описано в посте #1. :)
---------- Добавлено 03.08.2014 в 23:39 ----------
Romka_Kharkov, шо прямо круглосуточно 10k запросов в секунду?
Для полноты эксперимента - да.
По вашему рисунку мне не совсем понятно, что именно он отражает?
---------- Добавлено 03.08.2014 в 23:41 ----------
10к не так много как это может показаться. а если учесть то что там может быть статический контент то все еще проще.
если отдавать контент не авторизованным пользователем из кэша то можно будет обойтись 1 сервером.
Я описал Default Именно для того, что бы дать понять, там есть и статика и динамика и обращения в SQL и картинки и текст и все прочее что обычно располагается на обычном сайте, это не ФО , и не какой-то спец сервис, это обычный сайт домохозяйки которая печет ну очень вкусные пирожки ;)))
---------- Добавлено 03.08.2014 в 23:43 ----------
# netstat -anp| grep nginx | grep -i esta | wc -l
7767
это еще не вечер
А что при этом раздает сервер в эти подключения? Указанное вами количество Established оно ведь формируется не ежесекундно, многие из них висят >1 sec ?:)
---------- Добавлено 03.08.2014 в 23:45 ----------
Поддерживаю, тут надо смотреть в сторону горизонтального масштабирования.
Подробнее можно?
Сообщение от AGHost Посмотреть сообщение
Поддерживаю, тут надо смотреть в сторону горизонтального масштабирования.
Подробнее можно?
Эт, кароч, типа берете и с друганом такие в один свитер влезаете. Ну а с тремя типа свитер порвется, кароч.
Вот такая вот история про абстрактное горизонтальное масштабирование простыми словами и в рамках форума.
А для конкретных сайтов возможны и более конкретные решения. Масса возможных сценариев и инструментов, не все клиенту подойдут.
В чем смысл их обсуждать, если их слишком много и большинство предполагают изменение сайта программистами?
Как провайдер услуг вы ничего особо выгодного предложить не сможете.
Пятница опоздала :(
Вы даже не сказали, 10к запросов всего или только к динамике.
Romka_Kharkov, к сожалению Ваше задание очень и очень неполное, всвязи с этим и приходится додумывать очень много всего.
Серебряной пули в этом случае нет, надо смотреть на траффик, нагрузку, наличие пиков и сами скрипты, только после этого Вам дадут более-менее сбалансированное решение по цене/качеству.
Под Ваше задание есть решение только одно - купить больше пушек.
все уже придумано.
varnish, haproxy, redis , данные в mongo, mysql , NGINX, php-fpm.
вот презентация об этом, как сделан например youporn:
https://dl.dropboxusercontent.com/u/8275035/youporn.pdf
---------- Добавлено 04.08.2014 в 10:50 ----------
только единственный нюанс - возможно код дефолта вашего таки придется в чем то пилить.
---------- Добавлено 04.08.2014 в 10:55 ----------
Мне почему-то кажется что такие дела решаются или жесткой балансировкой между несколькими десятками серверов, либо же кластерной системой.....
я настраивал клиенту крупную ppc-партнерку.
4 фронта-блансировщика и все это на 50 бэкендов, вуаля. все работало.
балансировщики с 10гбит карточками. Бэкенды - обычные простенькие ксеончики с nginx+php-fpm, 16гб памяти.
база данных - четыре сервера percona, севрер mongo, ключи - redis.
один фронт-балансировщик на два бэка для varnish.
всего ровно 63 сервера.
все работает.
система должна быть мощной, надежной - да. но самое главное - МАСШТАБИРУЕМОЙ. Что бы когда тебе нужна будет производительность, ты за 15 минут настроил и поставил очередной дедик-воркер к остальным: трафик упал, мы изъяли 11 серверов, что бы не платить лишнее за аренду, трафик возрос, мы подсунули в систему 6 серверов. на них нужно было только yum install nginx php-fpm ну и необходимые php-модули, ну и конфиги nginx, fpm влить, далее restart и все, на все уходило 15 минут максимум. и новая нода становилась в строй. На черную американскую пятницу помнится - мы сразу 30 бэкендов клонировали на неделю, так как трафик взлетел в пик, америкосы за покупками побежали, потом снимали их с аренды. При таких объемах датацентр шел науступки, как например посуточная аренда, понедельная.
PS пилить код таки прийдется, так как какой-нибудь DLE понятия не имеет о redis, mongo и прочих малейших уходах от стандартов. В общем то, если пациент вырос до таких объемов, а хозяин не занимался продумыванием архитектуры сайта, переписыванием частей кода итд и теперь мы имеем например голый Wordpress с дикой посещалкой, то мне видится только вариант: вынести СУБД отдельно, вынести кеш отдельно, навертеть fpm... а дальше только наращивать железо, как будет утыкаться в производительность. Но этот вариант - очень дорог и не рентабелен, для этого и придуман различный софт для высоких нагрузок, что бы можно было на недорогом распространенном железе обрабатывать кучу данных.
если интересно - пиши.. расскажу детальнее.
pupseg, а что стояло в фронтенде ?
Базы как понимаю от бакендов собирали данные или же еще по ним выборка была ?
Эт, кароч, типа берете и с друганом такие в один свитер влезаете. Ну а с тремя типа свитер порвется, кароч.
Вот такая вот история про абстрактное горизонтальное масштабирование простыми словами и в рамках форума.
А для конкретных сайтов возможны и более конкретные решения. Масса возможных сценариев и инструментов, не все клиенту подойдут.
В чем смысл их обсуждать, если их слишком много и большинство предполагают изменение сайта программистами?
Как провайдер услуг вы ничего особо выгодного предложить не сможете.
Паша, здарова, а наш городской форум на чем ? nginx мордой, php в fastcgi или fpm (а хотя какая разница по большому счету....) ? mysql ? чего переписывал\дописывал?
---------- Добавлено 04.08.2014 в 11:20 ----------
pupseg, а что стояло в фронтенде ?
Базы как понимаю от бакендов собирали данные или же еще по ним выборка была ?
фронт - haproxy -----> nginx... статический контент.
базы - да, собирали данные и обрабатывали их.
а.. ну и забыл еще добавить, то, чего мы не сделали, но надо было:
мы сделали еще RRDNS -но это не совсем то.... в идеале нужно было бы у ДЦ попросить failover ip парочку и на самом-самом фронте сделать heartbeat.
TTL TTL'ем конечно, но все равно в случае RRDNS - падал какой-нибудь хост - все равно днс отдуплялись минимум 20-30 минут, за это время сайт с фидом лагали, не то что бы заметно клиенту, но лагали...
вообще конечно такие вещи очень долго вместе с заказчиком рисуются на бумажке, планируются и анализируются, а уже потом реализуются. Иначе косяк на косяке будет.