Как-то не совсем честно. Мелких клиентов там предостаточно.
Нацелены они на проекты, которые вот-вот совсем скоро стрельнут (достаточно чтобы сами проекты в это верили) и вот тогда они щедро на вас нагреются, но взамен вы получите масштабируемость и уж точно выдержите нагрузку.
Это по задумке. А на практике все услуги там переусложнены. Вокруг них сложился целый рынок помощников.
Не пойму в чем логика? shared мог быть просто мощнее.
Кстати, на новых версиях mysql уже давно можно дробное значение прописывать . То есть long_query_time = 0.3 вполне будет работать. Сделайте, если хотите еще больше информации собрать.
А вы захотите.
Так значит никакой проблемы нет, если запросы выполняются быстро ?
Начните сначала : почему вы заподозрили, что запросы выполняются долго ?
Ну поставьте 1.
SeVlad, так если она есть на форумах, то может быть и на любых других, в которых изначально не предполагалось большое количество каких-то сущностей. Почему бы не допустить что в DLE то же самое ? Надо смотреть подробно. В этом и вопрос ТС.
SeVlad, ну вот пойдите и на оффоруме vbulletin расскажите какие они плохие разработчики ) не смогли "более-менее правильно" сделать. Причем, приемы обычно во всех форумных движках повторяются. То есть и phpbb и ipb так же будут себя вести при росте числа категорий.
Проблема имеет место.
Проект к сеонизации относится никак. Ну не 20k, а 3k.
Небольшой стандартный набор категорий для разных городов нескольких стран и общие подфорумы. Иерархия ведь простенькая - они все повторяются в каждом городе. В России есть федеральные округа. Это я еще заметил проблему и продавил решение максимально снизить число категорий.
Что не так ? Конечно, нужна определенная автоматизация чтобы это все создать, но движок переписывать - это было бы слишком.
Копировать форум на разные URL запрещает лицензия. И нужна интеграция для общих подфорумов.
Вот разве кому-то приходит в голову обвинять avito.ru в переусложненной иерархии ? Теперь представьте что вы делаете Avito с помощью коробочной CMS. Взлетит или не взлетит - вопрос отдельный.
А у меня есть. Просто так удобно и этого требуют интересы проекта. Не все подфорумы посещаемые, но они нужны.
Кроме того, я имел ввиду прочие сущности. С группами пользователей та же проблема. Там в кеше что-то типа массива [подфорум][права доступа по группам]. Любой из множителей вырастает - растет объем этого массива.
Который "кешируется" целиком. Я называют это кешированием в кавычках, потому что движок вроде и правильно написан, но эффект от такого кеша негативный.
Не выводятся, но могут использоваться в коде. А устранить это может оказаться слишком сложно.
А по-моему много где. Да хоть в vbulletin. Глобальный кеш разделов, групп, прав доступа выгоден только когда этих сущностей относительно мало. А когда кеш большой, код впустую обрабатывает эту информацию.
Проблема коробочных движков в том, что каждый клиент платит за лицензию одинаковую сумму и развитие направлено на увеличение продаж, удовлетворение разных потребностей, а не на удовлетворение масштаба посещаемости.
Так что вопрос не праздный. В кеше как раз вся беда и заключается.
А вот в соседнем разделе можно наглядно убедиться какие они удовлетворительные бывают : /ru/forum/919621 .
Крупные почтовые сервисы просто все всасывают, никакие списки не используют. Им лучше ошибиться и кинуть в спам, чем постоянно решать возникающие инциденты. Впрочем, у них greylisting есть.
