nash300, Так у вас банальные проблема шареда, где гарантия что к моменту падения основного сайта резервный будет работать? Там его могли уже 5 раз перенести, сменить версию php и БД, а вы естественно об этом узнаете ровно тогда, когда сломается основной и резервный не поднимется в том числе. При том я не представляю как вы будете настраивать реплику на шареде или как вы планировали синхронизировать БД и файлы?
Моя вам рекомендация - это виртуальные сервер и желательно в облаке. Можно взять если попроще, то какой нибудь Jelastic например mirhosting, там сильно проще, либо облако от selectel или подобное, где падение хост ноды не потушит всех клиентов, а просто где контейнеры запустятся на новой ноде.
А самый наверное стабильный вариант это свой выделенный сервер, просто так если туда не лазить они и не падают почти. А у шареда будет всегда куча проблем подобного плана, потому что их администрируют админы с расчётом на большинство, а не конкретно под вас.
PS. Есть интересная услуга у NetAngel. Я сам еще не пробовал, но сам хостер стабильный. Вам может такая услуга подойдет как раз.
---------- Добавлено 22.05.2019 в 21:40 ---------- А все остальные варианты для вас будут сильно дороже даже дедика, аптайм 100% это очень такая сложная и сильно дорогая идея, она не нужна даже гигантам (или тем более гигантам)
nash300, На обычном нет.
Что для вас вменяемая цена? Ну вот какая у вас цена простоя? Может дешевле полежать?
nash300, я не пользуюсь сейчас такими ресурсами, я делаю через свой Load balanser и failover ip (ну или хотя бы floating ip) по этому менять IP не требуется.
А так старт цены начинается примерно от 3$ за зону с проверкой, если у вас много пользователей, много запросов к домену будет подороже, но в целом попробуйте если очень нужна такая функциональность. Там за 1 млн запросов к домену 0.5$ это основное что влияет на цену, а сколько у вас запросов мы можем только гадать
ну или route53 от aws
А еще можно просто при входе попросить ввести дату рождения =)
Это же логично, разделить кэш по устройствам.
Дело в том, что везде кеширование работает примерно так:
1. Генерируется ключ кэша
2. Проверяется наличие ключа
3. Если ключа нет, отрабатывает без кэша, если есть то берутся данные из кэша.
В вашем случае весь вопрос в генерации ключа. Там например зашит урл, группа пользователя и еще какие то параметры которые разделяют кэш, а значит в вашем случае, туда нужно добавить еще и инфу по типу устройства, раз у вас раздельный контент для них.
PS. Но лучше вашу задачу решить через css и стили @media
Это не другая сторона, а та же самая. Человек как раз и говорит, что если проект живет и развивается, то через некоторое время от CMS на которой он сделан остаётся мало чего, админка разве что. Тут в том и дело, но кастом писать проще не на CMS с кучей архитектурных костылей, а на фреймворке. А базовую потребность на старте на любом фреймворке сделать не сложно из той что дает CMS из коробки.
Даже взять другие сообщества, питон, ява, шарп у всех у них нет такой популяризации повсеместной CMS, у них это не прижилось ввиду квалификации людей в данных сообществах.
А разработчики об этом не знали видимо https://developers.webasyst.ru/
Сами разработчики написали специально для вас:
Я юзал этот фреймворк без приложения сайт и интернет магазин (shop-script) для своих решений.
PS. Блеснуть эрудицией не получилось =(
runseoman, .com же не единственная зона международная, их достаточно много http://www.iana.org/domains/root/db я думаю если вы готовы на зону .ru то и готовы на любую другую
Всё верно говорите, по этому я и уточнял, что если сделать сайт не хуже чем у топов (не у одного а в совокупности) в своей нише, не надо ничего выдумывать, просто сделать так же. Потому что если так не сделать то клиент уйдёт к топам. Но сервер вам выдал не сайт, обслуживать сервер будет тоже не сайт и продлите ли вы свой заказ далее от сайта никак не зависит.
Мы сайты делали всегда так, так их я делать и продолжаю:
1. Брали первую страницу выдачи (вместе с контекстом) по разным жирным ключам клиента.
2. Накидывали прототип из совокупности пересекающего функционала и блоков
3. Присыпали своим богатым опытом в разработке
4. Упрощали всё что можно было упростить (по хорошему правилу: если ты не можешь объяснить зачем это в этом месте, значит это не нужно в этом месте)
5. Согласовывали прототип с клиентом.
6. Рисовали макет
7. Верстали и программировали
N. etc.
Потому что 98% бизнесов не потянуть свою разработку с внедрением чего то нового, вначале нужно повторить удачный опыт, а дальше уже постараться превзойти. Но я не считаю такой сайт "продающим", да он удобный, он быстрый, он привычный покупателям, пусть он даже будет конверсионным, но он точно не продающий, он ничего никому не продает, это лишь один из способов коммуникации компании с клиентом, если это не почтовые голуби то уже значит шансы получить клиента есть. И понятием "продающий сайт" маркетологи сбили с толку наших клиентов, моих в том числе. Они теперь думают, что если сделать продающий сайт то деньги сами на РС потекут рекой. Как кнопка бабло фактически.---------- Добавлено 20.05.2019 в 10:48 ----------И сейчас мой разговор начинается с клиентом с того, что продающих сайтов не бывает. Что если телефон который указан на сайте будет не доступен или на той стороне не будут брать трубку, то не будет продаж. Что если на заявку оставленную клиентом будут отвечать через сутки - не будет продаж. Что если при звонке, клиента будут отфутболивать не обрабатывая возражения - не будет продаж. И всё в таком духе. Продающий сайт - это утопия. Продавать автоматом сайт может будучи интернет магазином с полной автоматизацией разве что и то требуется подтверждение от менеджера.
