Куда уйти с ispserver?

Чтобы была объективность, вот данные хосттрекера:

ISP

Total uptime:99.73% Downtime:5 hour(s) 11 min(s)

Daily uptime:100.00%

Ruweb

Total uptime:99.83% Downtime:4 hour(s) 28 min(s)

Daily uptime:89.45% Downtime:2 hour(s) 31 min(s)

Проверка каждые 10 минут. Это виртуальный хостинг.

А вот дедик и VDS от ISP на площадке в США:

VDS

Total uptime:99.99% Downtime:6 min(s) 1 sec(s)

Daily uptime:100.00%

Дедик:

Total uptime:100.00%

Daily uptime:100.00%

Про рувеб написал, потому что контора хорошая, я почти ничего не знаю про их суппорт, за 3 года как то особо не было повода общаться :) Но и у них бывают проблемы, а они все же не столь массовый хостинг как ISP.

У ISP и начались основные проблемы когда они решили превратиться в массовый хостинг. В последнее время конечно сдавать начали :(

Сегодня опять проблемы. Тоже начало доставать. Как правильно заметили, техподдержка у них отличная, но лучше бы не знать все прелести поддержки, а просто чтобы все работало.

Может проблемы только у тех, кто стал клиентом по акции и платит половину стоимости? А то странно, вроде VIP-тариф. Кстати, не смотрели у них la? Я недавно наблюдал от 40, еще до атаки, сейчас боюсь смотреть.

а у кого какие площадки с проблемами (Москва, Бельгия, США)?

Москва, msk-2.

Не только.

Вовремя я от них свалил:) Как ушел на другую площадку, сразу и статистика посещения подскочила на 20%.

Долго спорил с их суппортами, что у них очень низкий uptime. Мои доводы они парировали данными host-tracer'a. Но какой смысл от этой статистики подключенной на обычную дефолтную HTML страницу. В то время как MySQL сервер в последние 2 месяца лежал по 3-4 часа в сутки. Естественно на странице-заглушке это ни как не отражалось, и можно было показывать эти фиктивные данные всем недовольным клиентам, и говорить у нас всё круто!

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

Igoron, Не понял. ИМХО, чушь говорите.

Как может монитор доступности может учитывать работоспособность mySQL, если при генерации отдельно взятой страницы (заглушки) этот самый mySQL не используется?

Если сервер баз данных висит, то на загрузку заглушки это не произведёт никакого эффекта.

Или я что-то не понял?

Видимо что не понял.

Я не знаю о какой заглушке вы тут ведете речь.

Никакой заглушки у нас нет.

Есть страница которая генерится скриптом использующим mysql

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

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

поскольку хосттеркер описанных выше даунтаймов не фиксировал, следовательно утверждение про 3-4 часа дауна mysql является преукрашиванием событий.

Igoron:

Не хотел писать негатива о Вашей компании, даже после того как вы недели 2 назад мне "уронили" репутацию на форуме, но сейчас решил что надо донести правду до народа.

Итак, что касается страниц заглушел, которые по данным hosttracker имеют uptime близкий к 100%, то вот они: http://bruhost-2.ispvds.com/, http://mskhost-2.ispvds.com/ и т.д.

Теперь про то что MySQL у вас не падает по 3-4 часа. В прошлой теме показать я это не мог, т.к. боялся санкций по отношению к своим сайтам, с вашей стороны. Теперь же когда я ушел на другую площадку, опубликую информацию.

На данных скринах отображена моя переписка с суппортами. На первых 2 картинках можно увидеть, что в поддержку приходилось обращаться каждый день, т.к. mysql постоянно падал.

На след скринах, приведён разговор с суппортами.