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