Статья отдает не профессионализмом. С нагрузкой у всех движков есть проблемы (в ЕЕ в меньшей степени), тем более если большая посещаемость. Но не у всех есть кеширование, видимо просто автору статьи не удалось должным образом все настроить.
Но самое интересное, что автор продолжает пользоваться ЕЕ... )
На самом деле ошибка в подаче материала. Автор старался, но
1. явно что-то не то было с настройками изначально (то ли с сервером, то ли как-то криво установил)
2. к некоторым результатам шел через окольными путями с хаками ядра, чего вообще делать было не нужно.
3. из комментариев автора можно сделать вывод, что статья написано под впечатлением после исправление какого-то кривого сайта на ЕЕ (кривого - в следствии абсолютно неправильного проектирования). Ну так и надо было описывать в этом ключе - “мне попался абсолютно неправильной спроектированный сайт на ЕЕ и я исправил ошибки”. А получилось “ЕЕ кривой до невозможности, его авторы тоже, а я такой молодец и все исправил!”
После первого просмотра материала сложилось впечатление - собрались администраторы хостинговых сервисов для обсуждения своих проблем Ну а если серьезно, то все обсуждаемые в статье и комм-х вопросы имеют весьма и весьма относительный характер. Почему-то поднимаются вопрсы нарузки БД и ни слова о потреблении других ресурсов, к примеру - памяти, а этот показатель у EE очень низкий. Один из моих проектов был запущен на хостинге клиента: генерация страницы галереи изображений с 16 SQL запросами выполнялась около десяти секунд. Как оказалось - одной из особенностей хостинга (амер. сервер/рос. реселер) было ограничение памяти 8Mb! Хотя в подавляющем большинстве случаев достаточно даже этого. Средний показатель для большинства исследуемых сайтов - 6Mb. Для сравнения - магазин на Magento, недавно пркрученный к одному из ресурсов пожирает 27-35Mb в самом легком нагрузочном режиме. Если выделенная память гарантированно больше 64Mb - есть шанс того, что на сервере не более полусотни сайтов... Если это только декларирование, значит идет динамическое перетягивание ресурсов к наиболее нагруженным сайтам, зачастую в ущерб остальным! Вот поэтому всегда следует выбирать хостинг с достаточно большим запасом ресурсов. Тогда не будут возникать сторонние вопросы по поводу того, а что же там происходит внутри системы! Какое число запросов она отдает в секунду, а о вопросах кеширования вы забудете раз и навсегда, просто вырезав его, как апендикс... Вы купили готовый к использованию коммерческий продукт - высокоуровневую профессиональную систему для разработки вебсайтов, так поместите ее в благоприятное место, которое позволит нормально ее эксплуатировать... И еще: ни один заработчик подобной системы, из коммерческих соображений, никогда не будет настаивать на оптимальной конфигурации сервера, есть только минимальные требования, и вы понимаете почему...
А можно ли в EE, сделать минимальное число обращений к базе? Знаю что на некоторых движках, когда включен кэш, можно число обращений к базе, довести до 0. А как дела обстоят у EE?
2) И ещё вопрос: что мне прописать в коде, чтобы увидеть количество запросов, к базе?
...А можно ли в EE, сделать минимальное число обращений к базе?
Сгенерировать весь контент в виде HTML и выложить на сервер. Далее: вы утверждаете комментарии и записи мемберов? Утвердите, пусть скрипт сгенерирует опять-же все в HTML и опубликуйте! Чушь? Нет! Мы к этому идем быстрыми шагами. Не верите? Клиент взрослеет. Он уже не хочет платить ежемесячно за то, что можно обойти...
По большому счету - это 100% кэш, но штатная система кеширования в EE еще довольно не совершенна.
Некоторые другие популярные системы уже ушли далеко вперед.
К примеру систему электронной коммерции Magento недавно перевели на использование
режима компилирования кода шаблона, и это только начало...
Ну а если серьезно, то все обсуждаемые в статье и комм-х вопросы имеют весьма и весьма относительный характер. Почему-то поднимаются вопрсы нарузки БД и ни слова о потреблении других ресурсов, к примеру - памяти, а этот показатель у EE очень низкий. Один из моих проектов был запущен на хостинге клиента: генерация страницы галереи изображений с 16 SQL запросами выполнялась около десяти секунд. Как оказалось - одной из особенностей хостинга (амер. сервер/рос. реселер) было ограничение памяти 8Mb! Хотя в подавляющем большинстве случаев достаточно даже этого. Средний показатель для большинства исследуемых сайтов - 6Mb. Для сравнения - магазин на Magento, недавно пркрученный к одному из ресурсов пожирает 27-35Mb в самом легком нагрузочном режиме. Если выделенная память гарантированно больше 64Mb - есть шанс того, что на сервере не более полусотни сайтов... Если это только декларирование, значит идет динамическое перетягивание ресурсов к наиболее нагруженным сайтам, зачастую в ущерб остальным! Вот поэтому всегда следует выбирать хостинг с достаточно большим запасом ресурсов. Тогда не будут возникать сторонние вопросы по поводу того, а что же там происходит внутри системы! Какое число запросов она отдает в секунду, а о вопросах кеширования вы забудете раз и навсегда, просто вырезав его, как апендикс... Вы купили готовый к использованию коммерческий продукт - высокоуровневую профессиональную систему для разработки вебсайтов, так поместите ее в благоприятное место, которое позволит нормально ее эксплуатировать... И еще: ни один заработчик подобной системы, из коммерческих соображений, никогда не будет настаивать на оптимальной конфигурации сервера, есть только минимальные требования, и вы понимаете почему...
