Простите, а что вы из выше преречисленного предлагаете через CGI запускать?
Серверные предложения не выйдет. ffmpеg тот же с нужными кодеками? Стримить чем будете - можно скриптом, но не лучшее решение. Да банальный git или xdebug - виртуалочка такая удобна для для удалённой разработки, сам пописываю всякое, и у меня такая есть на своём сервере.
Надуманные примеры? Отнюдь - всё из практики, всё это было нужно, и отнюдь не по разу даже.
Да, можно взять не VPS конечно, а что-нить на атоме, даже найти такое можно иногда кое-где и за примерно те же деньги, плюс нет оверселла заведомо, кроме канала, правда.
Но найти такое предложение будет также сложно как и vps без оверселла, при этом при этом ту же VPS если что из снапшота поднять можно быстро, и долить актуальные данные если хостер хоть сколько-нибудь адекватен.
В итоге есть и плюсы и минусы. Если сравнивать с самыми дохлыми серверами.
И managed|unmanaged будет иметь равное значение тут.
Я согласен, что ниша куда меньше чем предложений на этом рынке и в большинстве случаев выбирают наслушавшись о "это как выделенный сервер, и дёшево, и в разы круче шаред хостинга" и прочего маркетологического бреда, а не из реальной необходимости, но то что её нет всё же преувеличение.
Сарказм в том, что если вы не занимались хостингом, не пробовали это всё и у вас ещё нет своего мнения собственного мнения на этот счёт, то вам явно рано этим заниматься, либо вам нужен тот, кто будет заниматься достаточно профессионально технической частью, и он пусть и делает этот выбор, чётко поняв все ваши нужды.
А вообще некой идеальной панельки нет. Все в той или иной мере некие компромиссы.
И да, хостинг даже на дешёвом хетзнеровском сервере это отнюдь не золотое дно. Подумайте десять раз, надо-ли оно вам вообще, и сколько вы потратите денег и сил до того, как это всё хоть как-то начнёт окупаться.
Ну это не уникальная фича, можно сделать много чем. А вот сочетание шифрования, инкрементального бекапа и ftp как хранилища найти будет сложно.
Далеко всегда дело в нагрузках. Не все живут на php и mysql, даже без нагрузок, хостингов же под другое окружение катастрофически меньше. А если надо там какой-нить ffmpeg, чтобы выдрать пару раз в день/месяц скриншот из видео, а если надо пару презентационных роликов стримить, и не хочется при этом выкладывать их на *tube? И много вы знаете шаред, где это реально, или видете смысл брать сразу дедик, который будет загружен на несколько процентов? Можно взять и на вырост, но есть немало проектов, которые не растут. VPS используют к тому же не только для хостинга сайтов. Так что не так всё однозначно, как вы тут пишете.
Как ваше утверждение противоречит моему? Прочтите внимательно, я написал ровно то же. Или вы под сервером начального уровня понимаете неттоп в ДЦ? Если нет, то наши утверждения эквивалентны. К тому же зря вы с выпадами, откуда такая агрессия? Без последних двух пунктов, которые наверняка и вас обошли стороной, я сталкивался вполне себе на практике, и описал вполне типичное развитие.
Да, неплохая вещь когда доступ только ftp, А бекапы нужно делать инкрементальные. И второй большой плюс - возможность шифрования. Но надо внимательно следить за её логом, и как можно чаще делать полные бекапы, т.к. были прецеденты, когда восстановиться на снапшотов после последнего полного бекапа было невозможно, хотя при этом процесс копирования в целом и завершался без критической ошибки. Это давно исправлено, но осадок остался.
Обычно в среднем сравнимо - шаред тоже бывает оченно разный.
Переходить надо либо если у вас есть необходимость в нестандартном ПО, например memcached каком-нибудь, тогда можно взять например VPSи настроить нужное окружение для вашего проекта, или когда нагрузка достаточно высока, тогда вам нужен уже сервер, т.к. виртуалки с достаточными ресурсами (не продекларированными а реально выделяемыми) часто дороже.
Если проект не критичен, можно заказать разовую настройку и "курс молодого бойца" по администрированию, и при наличии проблем выходящих за его рамки, обращаться к профи, если критичен, нужен админ, который будет за сервером присматривать постоянно, и по возможности проблемы предотвращать. Если совсем критичен, то надо разворачивать свою отказоусточивую систему, или идти в облака, но при большой нагрузке своё/арендованное железо будет дешевле, а администратор понадобится и там и там.
И да, панелька в этом всём копейки, и если сайтов не много часто и не нужна, а только мешает настроить всё оптимально под проект.
Условно так:
Небольшой проект, стандартное окружение - шаред хостинг, нет проблем администрирования. Главное выбрать удачно хостера, т.к. в большинстве довольно плохо с безопасностью и ресурсами.
Небольшой проект, нестандартное окружение - не верьте рекламе - VPS, это не следующая ступень развития по производительности, это аналог того же шаред хостинга просто более гибкий. Проблемы - администрирование. И администрирование будет везде отсюда и ниже. В каком варианте его можно использовать выше написано.
Небольшой проект, нестандартное окружение 2 - облако, всё то же что и выше, в общем-то, но с модным словом, и потенциально может быть дешевле, если ресурсы потребляются, например, нерегулярно.
Проект растёт, нужна производительность. Сервер начального уровня, проще всего в аренду. Т.к. на свой будут большие разовые затраты, которые на этом этапе обычно себе не позволить. Через какое-то время, возможно используется CDN.
Проект на удивление всё растёт и растёт - сервера множатся.
Бардак, проект задыхается, настало время строить свою грамотную инфраструктуру - несколько своих серверов, чаше всего на колокейшене, построена отказоустойчевая система, возможно даже разнесённая географически. Количество админов ростёт, как и разработчиков и административных работников. =)
Конкурируем с крупными сервисами, нас уже многие знают - Свои стойки с серверами.
Обогнали вконтакте - Свой ДЦ. =)
Установка соединения и персылка данных вносят большой вклад только в очень простые запросы, если на канале не огромные задержки. От размера таблиц естественно время выполнения зависит - больше данных часто больше надо считать с диска, больше отсортировать и.т.п.
А если посмотреть на распространённые причины тормозов, то на мой взгляд будет как-то так:
На первом месте обычно действительно неоптимальные запросы.
На втором неудачный выбор хранилища и всеобщая тяга к блокирующемуся на уровне таблиц myisam, недостатки которого очень часто перевешивают достоинства.
Ну а дальше проц, диск, память, в зависимости от характера нагрузки.
Зачем сверху, можно просто вместо.
У меня есть mysql server с ~9000 БД. Никаких особых проблем это не вызывает.
Производительность не будет отличатся, она зависит не от кол-ва баз, а от размеров таблиц и оптимальности запросов.
В вашем случае вообще нет никакой причины делать общую базу - одни минусы.
Например необходимость настраивать доступ на уровне таблиц, это больше действий, а если этого не делать, то проблемы с безопасностью. Про репликацию и перенос данных, выше уже написали.
