Как ускорить любую CMS? Нужна помощь

И что там в замен предлагали ? Редкий курс приносит полезное решение, в 99% это пережевывание соплей и уже известной каши.

Во-первых, у меня самого достаточно большой опыт построения и обслуживания веб-проектов. Во-вторых, основное в конференциях и семинарах не готовые решения, а общение. И решение проблем с БД разные: шардинг, партиции, кеширование и пр. Я уже выше писал про это.

Но Вы так и не ответили на вопрос: на чем основывается утверждение, идущее вопреки мировой статистике, что БД не может быть узким местом? Навскидку, могу предположить пару-тройку вариантов:

1. Узкий канал, который забивается быстрее, чем падает база. Gzip+браузерное кеширование+cdn легко решают подобную проблему.

2. Слабый фронтенд, не успевающий обслужить поток входящих соединений. Nginx, при правильной настройке, решит и эту проблему.

3. Сложные вычисления в скриптах. Тут проблема в неправильной архитектуре.

Все выше основано на общении с создателями довольно сложных и масштабных проектов + личный опыт. Именно эти факторы позволяют мне утверждать, что в большинстве случаев проблема ТОЛЬКО в БД. А Вы на каких данных утверждаете обратное? Мне действительно очень интересно, т.к. это позволит узнать что-то новое, что-то, что я возможно упустил в своей практике.

Ну так откажитесь от БД. С таким же успехом можно утверждать, что в машине самое узкое место - это мотор, так как постоянно туда требуется бензин подавать.

Если у вас вся логика завязана на БД, естественно вы туда упретесь. Но и называть БД узким местом не правильно. Вы почему то разрешаете расширять себе канал, менять фронтенд, а как проблемы с базой - то тут же БД виновата. Возьмите и расширьте процессорную мощность, перепишите структуру под проект. Если для генерации 1 страницы вы 100 раз обращаетесь к БД, то это совершенно не проблема БД.

дык "узкое место" - это не козел отпущения виноватый во всех грехах, которого надо сжечь на костре, это просто напросто самый медленный компонент, вот и все

зы. удивляюсь чему вы тут еще спорите....

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

Я ни разу не сказал, что не надо использовать базу, говорил только о том, что БД узкое место веб-проектов. И да, в автомобиле часто движок узкое место - из-за него автомобиль не может ехать быстрее и/или быстрее разгоняться ;)

На БД у меня завязанно только хранение данных. Логика в коде. А у Вас иначе? ))

По поводу канала - я не говорил о его расширении, говорил о снижении нагрузки на него. Не надо перевирать слова ;). Так же и с базой - часто надо не расширять ресурсы под нее, а изменить логику приложения, разгрузив БД. Разве я не это говорил выше? )

100 раз на 1 страницу?! Да Вы, сударь, ни разу не писали бизнес-приложения, но рассуждаете о нагрузках? o_O Я могу показать Вам приложение, в котором на одну страницу идет около 3000 запросов к базе и еще больше у другим компонентам. При этом, генерация этой самой страницы занимает 0.0055 сек.

Проблема БД - долгая обработка запроса к ней. Долгая - понятие относительное. Для какого-то запроса это может быть 1 сек, а для какого-то и 0.0001 - долго. И перенеся логику этих запросов на другую технологию (да хоть на кеширование) можно ускорить приложение в десятки/сотни/тысячи раз. Именно это и называется "узкое место" - то место, которое занимает самые большие ресурсы (включая временные) на обработку запроса.

История из практики (которую и Вы можете у себя проверить): заменив поиск данных с sql-запроса на сфинкс получите ускорение поиска по сайту раз в 100. И это при том, что меняется только формат индексирования (даже не хранения - данные так же остаются в БД). Разве в данном случае узкое место не БД? )))))

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

))) Неее, работа с базой МЕДЛЕННАЯ. Точка. Пример, который я вам привел показывает только одно - "медленная" понятие относительное. В данном случае, скорость была бы НАМНОГО МЕДЛЕННЕЕ, если бы использовалась только БД. Но сумма нескольких техник позволяет сильно ускорить работу приложения.

Я думал, что Вы делаете утверждения на каких-то данных, оказалось нет. Давайте на этом и закончим диалог.

Я вопрос задал как полный профан в деле оптимизации загрузки страниц.

В руки мне попадалась интересная книга "Разгони свой сайт. Методы клиентской оптимизации веб-страниц", но вникать и пробовать все времени не хватает.

Предполагал поиск каких-либо советов общего употребления. Сам я работаю в seo-конторе, к нам часто попадают тормознутые сайты (по гуглпейджспид) им банально нужно поднимать на 40-30 балов скорость до приемлимых 80 из 100. По статистике этого достаточно для хорошего ранжирования по позициям ТОП1-3.

NitrOx, на что стоит обратить внимание:

1. Архитектура движка. Скорее всего, используется один из популярных движков. В той или иной степени они имеют вполне адекватную архитектуру. Но все равно могут тормозить. Чаще всего из-за накрученных плагинов и модулей, которые пишутся (очень часто) людьми, которые слабо представляют архитектуру самого движка. Отсюда лишние запросы, трафик, обращения к файловой системе. Здесь вы можете повлиять на ситуацию, удалив ненужные плагины или заменив их мене требовательными (более удачными в своей архитектуре)

2. Хостинг - канал забитый, много сайтов на одном сервере - никак не повлияете. Разве что можете переехать к другому хостеру.

3. Клиентская часть, верстка. Для начала дать на анализ хорошему верстальщику, он скажет - можно ли улучшить верстку. Возможно придется весь шаблон переверстать. Обращать внимание:

- на количество картинок на сайта (даже самых мелких). Каждая картинка - это обращение к файловой системе сервера, это лишний запрос. Мелкие или однотипные картинки рекомендуется объединять в спрайты (иконки, кнопки, иногда фоновые градиенты).

- на вес картинок. Тяжелые картинки долго грузятся. Рекомендуется оптимизация графики. Использование более подходящих под ситуацию форматов. Вместо PNG -- JPG, где-то вместо JPG -- GIF и так далее. JPG в свою очередь тоже можно оптимизировать, сохранив при этом достаточное видимое качество картинки.

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

- инлайновые стили и другие параметры тегов. Все стили выносятся в отдельный файл стилей (меньше вес самой страницы, быстрее грузится. Сами стили кеширутся браузерами. В оценке скорости загрузки не участвуют).

- файлы стилей и мелкие скрипты. Если позволяет архитектура, то мелкие скрипты или стилевые файлы лучше объединять. Быстрее загрузится один большой файл, чем две половинки. И, опять же, меньше запросов к серверу.

Ну вот, примерно такой общий свод моментов, которых должно хватить для первичной (ударной) оптимизации. Все остальное, скорее всего, сведется к серьезным переписываниям движка, что довольно дорого.

offtop Th0rn, личка не работает - потому сюда.. болд в подписи не приветствуется.