Защититься от простоев невозможно, каждый хостинг рано или поздно присылает уведомления о технических работах.
Плюс репликация это лишний бекап и возможность поднять сайт (или не ронять его вообще) в случае краша диска на сервере, плюс это снижение нагрузки на 1 сервер и в случае географического разнесения - уменьшение пинга и времени закачки для конечных посетителей. А еще примитивный анти-ддос и еще много чего.
извините, но АП. Не верю что никто не работал с репликацией
ЛУчше так:
.htaccess
index.php
+ robots.txt не забудь
Адресация сохраняется + можно контроллировать заходы на зеркала и когда они кончатся не продлевать старые домены. Я так "оптимизировал расходы" одной фирмы, зарегистрировавшей с десяток доменов в разных зонах под 1 сайт
вариант от siv1987 по идее рабочий, но я бы делал на php через ob_start поиском сигнатуры и подменой, т.к. там же явно не все таблицы всех страниц заменить надо
P.S. а зачем ьаблицу дивами заменять? Проще на таблицу CSS переписать
IGMP? IPTV proxy? подробнее о технологии
Фильмы на ВКонтакте заливать от имени десятка разных аккаунтов с разных IP без пересечений чтоб не банили - вот бесплатное решение.
А если серьезно - правильно сказали, для движка один, для видео-контента пачка серверов, в виде CDN или подобия CDN, популярные видео раскладваются на максимуме серверов, малопопулярные на 1 хватит, движок сайта смотрит в базу на каких серверах лежит запрошенный файл, смотрит их доступность (проверка кроном раз в 5 мин и флаги в таблице) и выдает рандомный адрес, я так хостинг картинок делал - при закачке картинки пользователем она заливалась сразу на 2-3 сервера.
siv1987, спасибо, помогло
проверку даты убрал.
Плюс к тому у меня был косяк - если новостей по теме найдено меньше N, делался 2й запрос выборки M последних по дате новостей, где использовалось WHERE date>(time()-86400) - т.о. запрос каждую секунду менялся и не кешировался, округлил это число до 5000 секунд, теперь кешируется.
tls,
по сути этот перенесенный сайт и есть вся нагрузка. остальное - мелочи, машина почти простаивала.
Пока как результат после десятка просмотренных страниц время порядка 0.05 сек, максимум выброс 1 секунда с мелочью.
Завтра еще посмотрю в конце дня по логу MYSQL запросы в пиковое время, на которые уходит более секунды, если что буду пробовать InnoDB.
Спасибо за ответы. SHOW CREATE TABLE:
Немного EXPLAIN: любой запрос
выдает одинаковую табличку
Приведенный выше
показывает
InnoDB обычно не использую, более того отключаю в конфиге чтобы увеличить производительность VPS и уменьшить расход памяти. Все работало на MyISAM несколько лет на дешевом хостинге, не думаю что там оборудование намного мощнее моего VPS. Исходя из этих EXPLAIN можно сказать что переход на InnoDB может помочь?
Еще из тестов:
1 запуск 3.6 sec
2 запуск 7.3 sec
далее пошла выдача 7.3 страницы phpMyAdmin из кеша о_О
4.38 sec
5.57 sec
аналогично пошел кеш, буду разбираться. Но по сути первый на секунду лучше, а второй запуск хуже...
Я делал иначе - регистрация, авторизация, сброс пароля, профиль - полностью через форум. + В самописном движке на главной форма для входа, ссылки на регистрацию и напоминание пароля + использование кук форума + прав групп пользователей форума.
блин отрезал лишнее :)
там еще пару полей в конце таблицы было, используемых редко но это мегаприват потому их решил выкусить, к проблеме они отношения не имеют, заодно и id зацепил. Есть он там. 1й пост отредактировать не могу.
У меня date это timestamp, и чуть ли не у каждой новости он свой, повторов мало, не думаю что это хорошая идея делать индекс на такой огромной выборке.