CMS для миллиардов страниц

Робот же всё равно будет читать сайтмап. Там и настроить время.

Все настроено. Боты шарахаются по сайту от 3 минут до 22,5 часов

Много памяти уходит на сам PHP и не все получается хранить в озу.

Нужно хранить часть в кэше озу и часть на диске

Я спрашивал про движок, потому что возможно я не смог найти готовое решение, которое жрет мало ресурсов и имеет все функции для грамотного кэширования

Еще раз:

Начните с профилирования.

Что именно, какая именно часть обработки запроса жрет ресурсы.

И какие именно ресурсы - процессор, память, диск.

Для грамотного кэширования важно не только само кэширование (это-то как раз не сложно),

а правильное устаревание (протухание) кэша.

Это можете сделать только вы. А никакой не движок. Только вы знаете как должны устаревать ваши страницы.

Если страницы не устаревают, что мешает просто очень агрессивно их закэшировать и тем самым снять нагрузку с вашего PHP?

И опять таки - как вы собираетесь кэшировать на диске, если в вашей системе нет SSD?

sgrumi, я всё же хочу обратить Ваше внимание, что записи в файлах сайтмап занимают гораздо меньше места, чем кэш. И нинафиг не нужно держать на диске кэш миллиарда страниц, если 999 миллионов из них просматриваются раз в год.

Я уже ответил.

Например, 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 помогает роботу находить те страницы, которые он бы сам самостоятельно не нашел бы. Только и всего.

Жуйте сами что хотите. Я в Вашей жвачке не нуждаюсь.

Не нуждаетесь?

Зачем глупости, не соответствующие действительности, пишете?

Не надо думать за меня. Думайте за себя.

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

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

И взялись привычными методами. И облажались.

И даже не могут понять где облажались и как исправить (если бы было исправлено, - сюда бы не обратился топикстартер, да? )

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

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

Ровно как и ваша упертость в гадании на кофейной гущи.

У вас нет никаких цифр, - а вы уже упираетесь в определенное решение.

Системнее нужно подходить, системнее.

На какой версии PHP работают сайты? Как говорили товарищи, разнести по серверам, закрыть от индексации файлы.

А миллиарды страниц у вас находятся в БД/файлах или просто тащатся по API/парсятся?