- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Присущ, слово "кэш" Вам не знакомо?
Присущ, слово "кэш" Вам не знакомо?
Ну если вы всем запросам хотите отдать 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 минут, за это время сайт с фидом лагали, не то что бы заметно клиенту, но лагали...
вообще конечно такие вещи очень долго вместе с заказчиком рисуются на бумажке, планируются и анализируются, а уже потом реализуются. Иначе косяк на косяке будет.