Разовая работа, предлагайте сроки и стоимость.
С Уважением Дмитрий!
В избежании нагрузки на mySQL базу, необходимо выполнить оптимизацию запросов к базе.
Разовая работа, предлагайте сроки и стоимость.
С Уважением Дмитрий!
Почитали бы пару топиков ранее добавленных
instantcms.ru/forum/thread10135-3.html#80561
или вы туда писать будете больше чем читать?
кеширование тоже необходимо но прежде важна оптимизация.
Проблема больше не в плохих запросах, а в их огромном количестве.
то посылаются ненужные запросы? Если да, то приведите хотябы пару, чтобы я понимал.
Насчет индексов не вариант — не стоит думать, что разработчики криво их настроили.
Я бы сказал по-другому: если пользователь-гость, то нет нужды мучить базу данных сотней запросов, хватит и 5.вы хотите сказать, что в InstantCMS — если пользователь — гость, то посылаются ненужные запросы
То, что вы хотите — это хак. Переписывание большого количества запросов только затруднит переход на следующую версию Инстанта, да и на самом деле там очень мало запросов, которые можно как-то ускорить. И это не решит проблему с нагрузкой на базу.
Пересмотр и переписывание запросов — это тонкая оптимизация. Считайте равно тому, что переписывать по новой компоненты, модули… Возможно где-то придется менять весь алгоритм работы расширения. В последующем как будете обновляться?
Кеширование. Встроенное в смарти кеширование снижает нагрузку, но не в БД. Можно попробовать проверку в контроллере. Подключать шаблонизатор заранее, проверять есть ли кэш и если есть, то не выполнять алгоритм в контроллере. Вариант интересный. Если продумать, то может дать результат.
Кеширование в мускул. Тут надо всё тщательно протестить. И на шаред хостингах не прокатит, насколько я знаю.
Так мысли вслух… Навскидку. Ничего этого пока не делал. Но в будущем стоит подумать. Может кто-то уже попробует
ну хоть разбейся я не знаю, что на такое можно ответить… без конкретики, для меня это вырезание движка, cms это умная структура, где само по себе слово структура говорит о многом, запросы к базе формируются не от балды, а от надобности, запускается контроллер категорий меню, появляется запрос к базе с послед. выборкой и выводом, если посчитать там на главной странице 8 важнейших запроса к базе + скрытые запросы на проверку авторизированности пользователя, запрос на продление сессии… Каким образом вы до 5 хотите уменьшить? И что, у меня меню выводиться не будет?Я бы сказал по-другому: если пользователь-гость, то нет нужды мучить базу данных сотней запросов, хватит и 5.
blandind, какой конкретики вы от меня хотели в два часа ночи?) Да и вы же сами написали. что разбираетесь в запросах — а даже беглый взгляд на лог запросов расскажет вам достаточно обо всех недостатках и минусах системы, а так же подскажет направление для оптимизации...ну хоть разбейся я не знаю, что на такое можно ответить… без конкретики
Попробую объяснить, но конкретные запросы не пишу. Представьте, что 30 человек(гостей) заходят на главную страницу в интервале 10 минут, что они должны увидеть? — логично, что одно и то же. Страница скорей всего не изменилась. Даже если появился новый комментарий или какое-то действие в Ленте активности, нет ничего страшного если гости увидят это с некоторым опозданием.
Так вот, все эти 30 человек нещадно дергают mysql, получается грубо порядка 3 тысяч запросов(100 на человека). Моя мысль заключается в том, что можно первому сформировать и открыть страницу, совершив 100 запросов, а остальным 9 посетителям показать то же самое, загрузив этот контент из файла. Поберечь тем самым наш сервер от необязательной нагрузки.
Если для гостей выдавать страницы с некоторой задержкой, то мы получим значительное ускорение. Весь вопрос в грамотной реализации.
У себя я еще сделал оптимизацию для юзеров — при каждом открытии страницы идут запросы на количество компонентов, модулей, плагинов, фильтров… Запросы, которые получают позиции модулей и проверяют права юзера для просмотра модуля. Учитывая, что такая информация (количество модулей, компонентов, плагинов) не так часто меняются на сайте — можно не мучить базу данных при каждом открытии страницы. А включить кэширование конкретно для результатов этих запросов.
Я сам готовлю движок для высоконагруженного проекта, очень-очень высоконагруженного
ЗЫ и отвечу на это
Если вы не меняете пункты меню ежеминутно, то есть смысл не пересчитывать его при каждом открытии, количество пунктов меню — эта статическая информация — раз в 10 минут обновляем и отдаем юзерам в готовом виде.И что, у меня меню выводиться не будет?
Короче говоря, как связаться с тобой, чтобы приступить к доработке?
Нужно учесть что в движке много изменений, поэтому варианты подмены конкретных файлов не покатит, нужно все файлы в которые ты
будешь вносить изменения пробивать вручную.