Мало какой хостер оказывает услуги на базе своей уникальной разработки.
Как правило это какой-то общеупотребляемый управляющий софт, к которому имеет и документация и советы на форумах.
Вполне достаточно иметь отсылку на документацию, на описание API/меню.
Возможно, решение простейших вопросов или отсылки на FAQ (скажем, наблюдал как хостер, не обеспечивающий автоматическую установку Windows, давал отсылку на подробную статью как это сделать самому).
Но все это минимальные по затратам времени и по цене работы админов/тех.поддержки.---------- Добавлено 12.10.2018 в 13:53 ----------
КРОК вам может и починит iPhone. За те деньги.
Ну а от обычных хостеров - коих 99,9% - ни стоит ожидать.---------- Добавлено 12.10.2018 в 13:59 ----------
Да ладно.
Если рынок такой, что невозможно на нем зарабатывать - зачем вообще на нем работать? Из принципа?
P.S.:
Хостеры уровня Selectel не жалуются на убытки.
Хотя цены у них...
P.P.S.:
Хостинг просто перестал быть тем простым бизнесом, где можно тупо рубить бабло, оказывая услуги на базе простейшего софта типа ISPManager
Нужно вкладываться. Или автоматизироваться, так чтобы все работало, но тех поддержка хостеру почти ничего не стоила. Или закупать железо огромным оптом. Или и то и другое.
Ну а те, кто могут работать только по старинке, - разумеется будут страдать.---------- Добавлено 12.10.2018 в 14:02 ----------
Не факт что окупится собственная разработка.
Использовать уже готовые наработки по автоматизации хостинга - это да.---------- Добавлено 12.10.2018 в 14:07 ----------
Можно отсылку откуда вы взяли про 10 лет?
Бизнес в СНГ и на Западе - другой.
Да, у нас хотят быстрой окупаемости, так как рынок это пока позволяет. Вопрос, а позволяет ли хостерам. Но во многих других видах бизнеса - это вполне себе норма. И привыкли, что у нас все легче по сравнению с западом.
Индикатором являются ставки по кредитам.
На Западе проценты выхлопа с инвестиций, в среднем, ниже, чтобы заработать нужны или огромные суммы или долго ждать. И ставки по кредитам закономерно смешные по нашим меркам.
У нас ставки по кредитам в разы больше. Но и заработки на инвестициях выше.
Но вот, касается ли это хостинга? Который легко пересекает границы.
Я к тому, что ваша дополнительная работа из-за того, что вы стараетесь старый сервер использовать покуда можно - запросто может стоить дороже, чем просто обновить сервер и оплачивать эту разницу в цене со старым в течение года.---------- Добавлено 11.10.2018 в 17:27 ----------
А как быть с тем, что база данных в приципе имеет тенденцию роста? Как правило.
И что будет с сервером из-за естественного роста БД даже без перехода на другую кодировку?
Там же все равно нужно оставить большой запасец запасного места на сервере.
Шифрование/дешифрование httpS куда больше жрет ресурсов чем win-1251/utf-8
Стесняюсь спросить: ведь обычно стоимость разработки превосходит стоимость сервера в сотни раз...
Можно явно указывать codepage в заголовках ответа http/в секции head страниц.
Но я бы не стал - ибо могут быть еще и заморочки с обработкой форм/AJAX если это у вас есть.
Проще перекодировать внутри бэкенда/клиента СУБД. Получить win1251, отдавать http-клиенту в utf-8. Ну и обратное преобразование перед записью в СУБД.
Очевидные вещи для мелких сайтиков и небольших нагрузок - не работают, когда вы сталкиваетесь с проблемой, несколько нетипичной для разработчика мелкосайтиков.
Изначальная проблема у автора в том, что разработчики, знакомые лишь с простейшими проектами, взялись за проект, чья нагрузка несколько выше привычной им.
И взялись привычными методами. И облажались.
И даже не могут понять где облажались и как исправить (если бы было исправлено, - сюда бы не обратился топикстартер, да? )
А так-то проблема не страшная и не архисложная. Просто методы, которые можно использовать без негативных результатов на небольших нагрузках - здесь не годятся.
Не буду говорить про прям небходимость делать так, как следует делать в highload, ведь автор темы вообще не привел цифр по количеству запросов в секунду. То есть налицо отсутствие сколько-то системного подхода в решении проблем.
Ровно как и ваша упертость в гадании на кофейной гущи.
У вас нет никаких цифр, - а вы уже упираетесь в определенное решение.
Системнее нужно подходить, системнее.
Не нуждаетесь?
Зачем глупости, не соответствующие действительности, пишете?
Я уже ответил.
Например, Tarantool. Диск и процессор он использует эффективно. Ему только оперативку подавай.
Возможно что Tarantool с vynyl если у вам много данных и они целиком не влазят в оперативную память. Есть у него некоторые особенности, которые можно услышать тут https://youtu.be/u2pju_Hb9Wc В частности авторы рекомендуют обходится для максимализации прозводительности только первичным ключем.
Если все данные влазят в оперативку, то Tarantool с memtx https://tarantool.io/ru/doc/1.9/book/box/engines/
С ним и кэширование может и не понадобится.
Максимализация производительности достигаете переносом всей логики внутрь Tarantool и запуском нескольких экземпляров Tarantool, равных числу ядер процессора вашего сервера.
Очень возможно, что понадобится vshard.
То есть общая схема для больших нагрузок:
nginx с модулем nginx_upstream_module + Tarantool с vynyl + vshard.
Но сдается мне, для ваших задач это перебор.
Грамотно написанный движок и на PHP будет адекватно обрабатывать роботов и с миллиардом страниц.---------- Добавлено 11.10.2018 в 15:28 ----------
1) Во первых у автора темы не та проблема, что "999 миллионов просматривается раз в год". А как раз обратная. Читайте внимательнее первое сообщение автора темы, где все это изложено.
2) ОК, пожую специально для вас, хотя это и очевидно всем тем, кто вообще знает что такое кэш. Выделяем сколько-то ресурса под кэш. По мере промахов (не было в кэше) в кэш помещаются все новые и новые данные. По мере того, как заканчиваются ресурсы объема кэша - самая старая информацию выкидывается, освобождая местов в кэше. Если у вас есть ресурс оперативки под вообще все данные - можно и 100% закэшировать. Все равно за ресурсы-то вы платите, независимо от того выделена ли оперативная память под кэш или нет. Если нет ресурса под 100% кэширование - кэшируете на сколько хватит, с вытеснение старого новым.
3) Думаете, робот сначала идет в sitemap и только потом идет четко по адресам sitemap? Что достаточно создать в нем десяток другой страниц и робот больше ничего посещать не будет?
а) Нет, sitemap всего лишь дополняет ссылки, которые робот нашел на других сайтах или на этом же сайте на других страницах.
б) Робот планирует свои работы заблоговременно. То, что вы исправили содержимое sitemap час назад не означает, что робот на это сразу же отреагирует. Он вполне себе может работать по предыдущему sitemap.
в) sitemap помогает роботу находить те страницы, которые он бы сам самостоятельно не нашел бы. Только и всего.
Еще раз:
Начните с профилирования.
Что именно, какая именно часть обработки запроса жрет ресурсы.
И какие именно ресурсы - процессор, память, диск.
Для грамотного кэширования важно не только само кэширование (это-то как раз не сложно),
а правильное устаревание (протухание) кэша.
Это можете сделать только вы. А никакой не движок. Только вы знаете как должны устаревать ваши страницы.
Если страницы не устаревают, что мешает просто очень агрессивно их закэшировать и тем самым снять нагрузку с вашего PHP?
И опять таки - как вы собираетесь кэшировать на диске, если в вашей системе нет SSD?
А может, просто настроить время протухания страниц?
https://habr.com/post/204464/
Зачем роботу проходить все страницы ежедневно.
Они что - все до единой меняются постоянно?
В любом случае - роботам есть чем заняться.
Миллиард страниц или не миллиард - время обработки одного сайта лимитировано владельцем робота.
А то он зависнет на таком как вы.
А у него еще в очереди кроме ваших сайтов - полным полно работы.
