- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Хочу взять dedicated хостинг (или лучше colocation?) на ресурсоемкий проект, в котором возможно потребуется несколько машин.
Насколько я знаю у mysql существует кластеризация в виде разнесения серверов по разным машинам с репликацией даных с мастера на подчиненные машины. Подскажите пожалуйста, решает ли данная архитектура вопросы производительности (т..е. будут ли обсчеты отправляться на разные машины) или же это сделано только с целью повышения надежности?
Так же интересно было бы услышать мнение профессионалов как сделать запросы к скриптам php выполняющимися на разных серверах в целях снижения нагрузки.
Между dedicated и colocation выбор на самом деле прост: если есть возможность изначально вложить приличную сумму в оборудование, то colocation несомненно эффективнее с финансовой точки зрения, так как окупится достаточно быстро по сравнению с ценами на dedicated.
Репликация делается на системах, где операции чтения преобладают над операциями записи, в этом случае асинхронная репликация позволяет распределить нагрузку между несколькими серверами. В определенных ситуациях такой вариант очень даже работоспособен.
Не сочтите за рекламу, но могу посоветовать почитать статьи о том, как устроены "изнутри" успешные крупномасштабные проекты.
Извиняюсь, два раза сообщение отправилось...
Для кластеризации не master-slave надо юзать а ndb cluster
Для кластеризации не master-slave надо юзать а ndb cluster
А чем Master-Slave плох? Особенно если в проекте используются сервера различной мощности а иногда и различных платформ? Знаю один успешно работающий кластер уровня приложения на серверах которого используются: linux ( RH и SuSe ), Solaris и винда. Два года назад в нем еще AS400 стояла, но заменили на 3 линуховых машинки :)
Сервера в кластер добавляются по мере необходимости, и тут же производится перераспределение нагрузок на компоненты. А можно перераспределять и бех изменения конфигурации.
Правда это не на PHP+MySQL :)
Тем, что master-slave - ничуть не кластер
NDB - настоящий кластер
NDB - настоящий кластер
только убогий уж слишком
Хочу взять dedicated хостинг (или лучше colocation?) на ресурсоемкий проект, в котором возможно потребуется несколько машин.
Насколько я знаю у mysql существует кластеризация в виде разнесения серверов по разным машинам с репликацией даных с мастера на подчиненные машины. Подскажите пожалуйста, решает ли данная архитектура вопросы производительности (т..е. будут ли обсчеты отправляться на разные машины) или же это сделано только с целью повышения надежности?
Так же интересно было бы услышать мнение профессионалов как сделать запросы к скриптам php выполняющимися на разных серверах в целях снижения нагрузки.
есть много вариантов, например ЛБС и подобные вещи для серезных нагрузок, проблема в них одна, первоначально высокие затраты, поэтому если вы ищете "бюджетные" решения, смотрите в сторону
http://www.djangoproject.com как раз основываясь на бюджетных серверах можно поднять очень здоровенный кластер и не боятся что данные могут потеряться...за подобным, как мне кажется, ближайшее будущее хостинга.
только убогий уж слишком
mysql сам по себе убогий