Дана інформація - витяжка для просунутих новачків. Чекліст для більш просунутих становить близько 60 пунктів.
Швидкість сайту це один з його найважливіших параметрів. Якщо сайт буде завантажуватися довго, то відвідувач просто піде c сайту, не дочекавшись завантаження. Гугл так само став звертати увагу на швидкість завантаження сайту і знижує позиції сайту, якщо він повільний.
Взагалі, повна досконала оптимізація вимагає дуже серйозного підходу і залучення фахівців, які на цьому спеціалізуються. Вони протягом декількох днів досліджують вузькі місця сайту і виправляють їх. Але є багато швидких і простих технік, які допоможуть дихати сайту набагато вільніше. Не обов'язково застосовувати всі техніки зі списку нижче, пробуй кожну і дивись як це впливає на швидкість роботи сайту.
Є два класних інструменту для перевірки швидкості сайту - YSlow і GTmetrix. їх потрібно використовувати після кожного внесення зміни. Записуй ключові параметри вимірювань (завантаження сторінки, розмір сторінки, число HTTP запитів і загальну оцінку в балах) перед кожним внесенням змін, щоб бути впевненим, що ти рухаєшся у правильному напрямку. Також можна спробувати JMeter і Apache Bench.
kosHta написав:
орієнтовані на программеров?
після того як я почав розвивати інші пальці в друпалі, він почав ставати легше. У сенсі ти просто береш і робиш що потрібно, замість читання купи інтернету, установки 2-3 модулів, намагаєшся зрозуміти як вони працюють, і чому не роблять що тобі треба, або не так роблять. І судячи з того як воно там все влаштовано і за кількістю контріба - мені здається що таки да, більше на программеров.
deb написав:
Дуже дивний модуль. Чим файлове зберігання краще Мускл? Вибірка по первинному ключу в Мускл працює дуже швидко. Коротше користь від такого модуля вкрай сумнівна.
у MySQL виникають проблеми продуктивності після 20МБ / сек трафіку (in out з бази даних)
VIEWS - генерує цей трафік. І чим більше у вас уявлень і даних тим більше трафіку.
По суті виходить що велика частина часу витрачається на отримання цих даних з бази ніж на їх вибірку.
В результаті при перенесенні на файловий кеш, навантаження йде на IO дискової системи, яка краще розрахована на такі навантаження.
По суті різниця виходить між "IO по мережі + IO по файлу бази даннихх" і "IO по диску". Це дозволяє зберегти продуктивність бази даних для цільового використання, замість зберігання кеша.
Альтернативно можна зберігати кеш в memcached але його установка на більшій частині хостингів недоступна або вимагає певних знань від користувача.
Знову ж memcached використовує пам'ять для зберігання кеша. Вона дорожча ніж дисковий простір.
Тут вже треба дивитися на конкретний проект.
У той час як використання filecache (cacherouter) дає миттєвий результат.
На прикладі DH.Elastic вартість хостингу падає в рази для клієнта.
«У MySQL виникають проблеми продуктивності після 20МБ / сек трафіку (in out з бази даних)»
Це просто не так. Це залежить від мережі, заліза, налаштувань і.т.п. Тобто ця фраза, в реальності, відображає один конкретний кейс, і не пов'язана з Mysql взагалі. Немає у нього такого архітектурного обмеження. У вашому конкретному випадку це так працює не більше того.
IO по мережі може не бути взагалі, наприклад, якщо сервер бази на тому ж сервері, оверхед при роботі через сокети дуже малий. Або сума затримок диска і мережі бази, може бути менше, ніж затримка накопичувача з файлами, який теж може бути не локальним, і до того ж не швидким.
Або затримки мережі, які гальмують все при великій кількості запитів (а не трафік, до речі, в першу чергу), можуть бути дуже малі.
Або кеш файлової системи може чимось вимиватися, і буде божевіллям класти туди кеш.
Або, як окремий випадок, на кеш файлової системи просто пам'яті мало залишили.
Маса кейсів, коли кеш в БД буде краще, в результаті.
І якщо на якомусь вашому хостингу і вашому тарифі цей кейс працює добре, і дозволяє економити, варто це і писати в описі цього тарифу, ймовірно, а не підносити як оптимальний варіант для всіх випадків.
Резюме з цього приводу: Так, іноді, файловий кеш краще. У реальності, це не так і часто. Дисковий IO на більшості хостингів є пляшковим горлечком, особливо, на не дорогих VPS.
ttenz написав:
Кешування уявлень дуже класна штука
Ситуація. Галерея з нескінченним скролл на вьювз. Прев'юшки пропадають (кожен раз в різних місцях) при перезавантаженні сторінки. Саппорт хостингу порадив включити кешування вьювз. Прев'юшки стали пропадати з подвоєною силою. Що порадите?
Нове на форумі
Вміст сайту публікується на умовах CreativeCommons Attribution-ShareAlike 3.0 або більш пізньої версії
Програмні коди в тексті статей - на умовах GNU GPL v2 або більш пізньої версії.
Drupal - торгівельна марка Дріса Байтаерта