Сообщений в теме: 60

[Билли Бонс]

Катя (Aki Astarta), сделайте зеркало основного сайта на другом хостинге, и некоторое время туда отправляйте подписчиков. Если и с ним начнётся  петрушка, тогда -- ддосят. Если зеркало будет работать, а основной падать, то хостера смените.

 

Можно поддомен основного использовать, можно cms без базы поставить. Вообще лучше иметь несколько своих ресурсов.

У меня тоже есть предположения, хотя я не параноичка Но, насколько я понимаю, эти предположения так и останутся предположениями, потому что проверить их - невозможно.

Если вредят из-за основной деятельности, т.е. человек следит за рассылкой, то он постарается преследовать, иначе его действия не дадут результата. А если стали жертвой, потому что под руку подвернулись, то отстанет.

[Катя (Aki Astarta)]

Если и с ним начнётся петрушка, тогда -- ддосят.

Билли Бонс, петрушки уже нет) Но ощущение нестабильности сохраняется...

 

Если вредят из-за основной деятельности, т.е. человек следит за рассылкой, то он постарается преследовать, иначе его действия не дадут результата. А если стали жертвой, потому что под руку подвернулись, то отстанет.

А, может, он отстал, потому что у него деньги на эти глупости закончились. Или он вдруг поумнел и понял, что ерундой занимается в то время, как в мире масса нерешенных проблем)

 

Вообще лучше иметь несколько своих ресурсов.

Катя (Aki Astarta), сделайте зеркало основного сайта на другом хостинге,

Зеркало - это копия, так? Вот если это просто статейный ресурс, то сделать и поддерживать такую копию - не проблема. Просто нужно будет публиковать одинаковые материалы в разных админках вордпресса на разных хостингах)

Но а если это ресурс с зарегистрированными пользователями?

Возможно ли как-то автоматически синхронизировать обновления пользовательской базы на обоих сайтах (разные домены, разные хостинги)? Чтобы человек, допустим, регистрировался на сайте №1, а данные о регистрации дублировались и на сайте№2?

Тогда в случае войны или каких других мероприятий проблем с доступностью сайта №1 есть смысл отправлять пользователей на сайт №2.

Спасибо.

 

P.s.Билли Бонс, вы у меня сегодня прямо герой вечера

[globalmoney]

Возможно ли как-то автоматически синхронизировать обновления пользовательской базы на обоих сайтах (разные домены, разные хостинги)? Чтобы человек, допустим, регистрировался на сайте №1, а данные о регистрации дублировались и на сайте№2?

 

Для этого Вам понадобятся два VDS или выделенных сервера + настройка репликации БД + синхронизация файлов (если это необходимо).

[Билли Бонс]

Но а если это ресурс с зарегистрированными пользователями? Возможно ли как-то автоматически синхронизировать обновления пользовательской базы на обоих сайтах (разные домены, разные хостинги)?

Синхронизация -- это один из вариантов.

 

В вашем случае проще иметь одну общую базу данных для двух сайтов. В вордпрессе следует правильно указать удалённый хост с базой и админам сказать, что хотите организовать внешнее подключение к базе с таких-то адресов.

 

Как правило базы данных на шаред хостинге размещают на других серверах, т.е. при загрузках одного веб-сайта по самое-самое, база будет без проблем откликается на запросы с другого, с зеркала.

 

Другими словами, пользовательские данные, контент, будут доступны с разных доменов.

 

 

P.s.Билли Бонс, вы у меня сегодня прямо герой вечера

Мне делать пока нечего )) Ищу клиента на коучниг )))))

Сообщение отредактировал Билли Бонс: 09 Август 2013 - 08:16

[Катя (Aki Astarta)]

Для этого Вам понадобятся два VDS или выделенных сервера + настройка репликации БД + синхронизация файлов (если это необходимо).

globalmoney, спасибо за крутой ответ)

Прочитав про два выделенных сервера (что это такое. я то уже знаю) поняла, что ваш вариант может подойти кому-то другому, но не мне

 

В вашем случае проще иметь одну общую базу данных для двух сайтов. В вордпрессе следует правильно указать удалённый хост с базой и админам сказать, что хотите организовать внешнее подключение к базе с таких-то адресов. Как правило базы данных на шаред хостинге размещают на других серверах, т.е. при загрузках одного веб-сайта по самое-самое, база будет без проблем откликается на запросы с другого, с зеркала.

 

Билли Бонс, спасибо за ответ, выглядит действительно проще. Я правильно поняла систему:

два хостинга, на одном общая база вордпресс + сайт1, на втором сайт №2 (с подключением к общей базе с хостинга 1)? Или база на третьем хостинге, отдельно?

 

А если "лежит" хостинг с базой, сайт №1 и сайт №2 могут работать?  

[Сергей (ex-Gudvin)]

А если "лежит" хостинг с базой, сайт №1 и сайт №2 могут работать?

 

Нет.

[Билли Бонс]

Я правильно поняла систему: два хостинга, на одном общая база вордпресс + сайт1, на втором сайт №2 (с подключением к общей базе с хостинга 1)?

да.

 

Или база на третьем хостинге, отдельно?

И так можно. Если на хостингах под сайты не могут сделать базу с внешними подключениями.

[Катя (Aki Astarta)]

А если "лежит" хостинг с базой, сайт №1 и сайт №2 могут работать?

Нет

Тогда нет смысла использовать этот вариант

 

Значит, остается:

1) вот- то страшное, которое описал globalmoney ("два VDS или выделенных сервера + настройка репликации БД + синхронизация файлов";

2) "ручная" синхронизация двух сайтов на разных хостингах";

3) очень-очень надежный хостинг;

4) или смена модели продаж, при которой стабильность работы сайта не будет первостепенной...

 

(в раздумьях)

 

Билли Бонс, Сергей (ex-Gudvin), спасибо за ответы.

[mikey]

1. Я тут как раз посмотрел хелпы у своего хостера на тему, что делать если сильно грузишь сервак?

Хостер рекомендует первым делом логи посмотреть.

Посмотрел, и действительно там много чего интересного и полезного можно увидеть
2. Тут еще надо узнать не грузят ли сервак те, кто хочет регистрироваться на сайт.

Тогда выбор между "шашечками или ехать"

(В смысле или множественные регистрации на блоге, или уменьшение нагрузки)

Я как раз на подобную тему наткнулся  на одном из форумов. Там ЮБ (Белотицкий, программер из Харькова) рекомендует оставить регистрации только со своего ip, чтобы сервак сильно не грузить.
 

[Билли Бонс]

Тогда нет смысла использовать этот вариант

Смысл есть, причину указал:

Как правило базы данных на шаред хостинге размещают на других серверах, т.е. при загрузках одного веб-сайта по самое-самое, база будет без проблем откликается на запросы с другого, с зеркала

 

Положить базу и положить сайт -- совершенно разные вещи.

Нагрузка на базу в тариф не входит ))

[globalmoney]

Нагрузка на базу в тариф не входит ))

 

Не всегда.

Но когда обычно нагрузку на БД не считают, то доступ к БД возможен только локальный и подключения из вне закрыты.

[Билли Бонс]

Не всегда.

Интересно: как они её считают?

[globalmoney]

Интересно: как они её считают?

 

http://www.percona.c...ures:userstatv2

[Билли Бонс]

http://www.percona.c...ures:userstatv2

Это обычный сборщик статистики базы. Причём только для одного типа СУБД.

 

Как они эту статистику в тариф превращают?

На обычном шареде ведь бессмысленно.

 

В трёхзвенной архитектуре нагрузка базы зависит от сервера приложения. Пропорционально. Проще говоря, ограничивая для пхп-скрипта память и время выполнения, вы резко уменьшаете вероятность запуска ресурсоёмкого запроса к базе.

 

Конечно, есть хостеры замороченные и со специальными тарифами, но для wp это чересчур.

 

globalmoney, а у вас тарифицируется нагрузка базы?

Сообщение отредактировал Билли Бонс: 12 Август 2013 - 05:21

[Билли Бонс]

Но когда обычно нагрузку на БД не считают, то доступ к БД возможен только локальный и подключения из вне закрыты.

Кстати. Для зеркала можно взять другой акк  хостра, как вариант, если он не открывает внешние коннекты.

[globalmoney]

Это обычный сборщик статистики базы.

 

Если внимательно посмотрите, то там не просто сбор статистики, но и считается использование процессорного времени.

 

Конечно, есть хостеры замороченные и со специальными тарифами, но для wp это чересчур.

 

А что, для данного движка не стоит считать нагрузку?

Бывает когда лишь на главной странице может быть 500 и более запросов к БД и это создаёт определённую нагрузку на MySQL.

 

globalmoney, а у вас тарифицируется нагрузка базы?

 

У нас она не тарифицируется, но и подключиться к серверу БД из вне, не возможно.

[Билли Бонс]

Если внимательно посмотрите, то там не просто сбор статистики, но и считается использование процессорного времени.

Нормальная практика. Что в этом необычного?

 

Одно дело собрать статистику, другое выставить счёт за неё ))

 

У нас она не тарифицируется, но и подключиться к серверу БД из вне, не возможно.

Вот про то и говорю: нагрузка не тарифицируется. И так у многих.

 

По умолчанию внешние коннекты должны быть  заблокированы. Есть хостеры, которые идут на встречу клиентам, открывают коннекты.

У моих -- без проблем. Конечно, надо рассказать зачем такое потребовалось и указать конкретные ip.

 

А что, для данного движка не стоит считать нагрузку? Бывает когда лишь на главной странице может быть 500 и более запросов к БД и это создаёт определённую нагрузку на MySQL

Нет, если речь про шаред.  Вы же не учитываете и не тарифицируете. Хостер нарезает ресурсы для вебсервера и берёт за них деньги, а ресурсы базы на шареде туда уже включены.

 

Если сайт создают большую нагрузку на базу, то значит и на вебсервер идёт большая нагрузка. Скрипт, который генерирует эти 500 запросов, требует бОльших ресурсов. Клиент возьмёт тариф, в котором учтена эта потребность в ресурсах на вебсервер. А нагрузка на базу будет уже сидеть внутри этого тарифа.

 

На шареде это так.

Сообщение отредактировал Билли Бонс: 12 Август 2013 - 08:42

[globalmoney]

Одно дело собрать статистику, другое выставить счёт за неё ))

 

Выставить счёт за нагрузку не составит проблем, главное собрать статистику по пользователям и обработать её.

 

Всё это делается на автомате, в том числе и выставление счетов.

Нет, если речь про шаред. Вы же не учитываете и не тарифицируете. Хостер нарезает ресурсы для вебсервера и берёт за них деньги, а ресурсы базы на шареде туда уже включены. Если сайт создают большую нагрузку на базу, то значит и на вебсервер идёт большая нагрузка. Скрипт, который генерирует эти 500 запросов, требует бОльших ресурсов. Клиент возьмёт тариф, в котором учтена эта потребность в ресурсах на вебсервер. А нагрузка на базу будет уже сидеть внутри этого тарифа. На шареде это так.

 

Открою вам небольшой секрет, как правило нагрузку на сервер БД, хостеры не включают в стоимость тарифных планов и при большой нагрузке на сервер БД, со стороны клиента, бывает два варианта:

 

1. Дают время на оптимизацию запросов и снижение нагрузки.

2. Отключают хостинг аккаунт.

 

Представьте себе работу скрипта с запросом выборки данных из большой БД (мегабайт 300, а то и больше). Пока будет выполняться запрос на сервере БД, скрипт в это время будет простаивать и не потреблять ресурсов, в то же самое время нагрузка на сервер с БД будет приличная.

Поэтому зря Вы думаете, что нагрузка на сервер БД = нагрузке вебсервера.

[Билли Бонс]

Пока будет выполняться запрос на сервере БД, скрипт в это время будет простаивать и не потреблять ресурсов

Всё это время скрипт находится в рабочем состоянии и ресурсы удерживаются. Таймер тикает. Память занята.

 

Обращение к базе синхронное )) База НЕ инициирует запросов. Она их только выполняет.

 

Поэтому зря Вы думаете, что нагрузка на сервер БД = нагрузке вебсервера.

Я так не думаю. Более того дважды написал, что нагрузка на сервер БД <= нагрузке вебсервера. (Если так можно выразиться). Поэтому её не тарифицируют.

 

Открою вам небольшой секрет, как правило нагрузку на сервер БД, хостеры не включают в стоимость тарифных планов и при большой нагрузке на сервер БД, со стороны клиента, бывает два варианта:

Лимиты в базе не согласованы с ограничениями тарифного плана. Чтобы вам проще было понять:

 

1) если таймаут на выполнение скрипта 30 секунд, а в базе на выполнение запроса выставлено 60, то скрипт снимается, а запрос продолжает выполнятся.

 

2) если скрипту выделено 64Мб, а выборка на сервере выходит 1Гб, то скрипт срежут, а база после этого будет продолжать чистить temporary table

 

У админа руки кривые )) И хостер эти косяки перекладывает на клиента. Это не секрет.

 

Выставить счёт за нагрузку не составит проблем, главное собрать статистику по пользователям и обработать её.

В том то и дело, что на шареде это бессмысленно: овчинка выделки не стоит.

 

p.s. Одно и тоже в ступе толкем.

Сообщение отредактировал Билли Бонс: 12 Август 2013 - 11:02

[globalmoney]

Всё это время скрипт находится в рабочем состоянии и ресурсы удерживаются. Таймер тикает. Память занята. Обращение к базе синхронное )) База НЕ инициирует запросов. Она их только выполняет.

 

Скрипт инициирует запрос к БД и ожидает ответа.

При этом во время ожидания ответа от сервера БД, скрипт не потребляет процессорного времени, а висит в режиме ожидания!

Есть три параметра: пользовательское время CPU, системное время CPU и время работы.

В данном случае, пока скрипт ожидает ответа от сервера БД, он будет использовать только время работы, но на нагрузку на сервер это ни как не влияет, кроме потребления ОЗУ и занятого процесса.

 

 

Я так не думаю. Более того дважды написал, что нагрузка на сервер БД <= нагрузке вебсервера. (Если так можно выразиться). Поэтому её не тарифицируют.

 

В этом Вы ошибаетесь и некоторые хостеры всчитывают в нагрузку, так же и потребление процессорного времени сервером БД.

 

 

Лимиты в базе не согласованы с ограничениями тарифного плана.

...

У админа руки кривые ))

 

Их просто не возможно согласовать, т.к. на разных тарифных планах у всех хостеров разные ограничения.

Вы же не предлагаете хостеру для каждого тарифного плана заводить отдельный сервер БД, чтобы согласовать ограничения?

 

 

В том то и дело, что на шареде это бессмысленно: овчинка выделки не стоит.

 

Ну почему же бессмысленно?

Как раз это позволяет вести более подробную статистику по нагрузке на сервер от пользователя и тарифицировать эту нагрузку. Для хостера этот как раз будет выгоднее, чем без такой статистики.

Сообщение отредактировал globalmoney: 12 Август 2013 - 13:28