- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть такая ситуация.
Сайт на Wordpress. В нём ~ 20 000 статей, общей площадью 166 Мбайт. Да, сам написал :)
Как это ни странно, всё работает. Правда, очень медленно. Главная страница генерируется около 3 секунд. Другие страницы на движке Вордпресса на этом же сервере - 0.3 - 0.5 секунды.
Так вот вот в чем вопросы:
1) это от размера базы (в Мегабайтах) так падает производительность? или от количества записей? (... или оба)
2) В какую сторону оптимизировать MySQL в таких условиях? Что повышать и что понижать?
Всё это работает на 2.5Celeron + 512M + 160G+80G + FreeBSD 6 + PHP4 + MySQL 4.0 + Apache 1.3
Размер базы не такой уж и большой. Видали и побольше:)
Индексы делай по ключевым полям(по которым идет выборка, допустим по дате)
Смотри все запросы которые выполняются и делай их EXPLAIN
Так вот вот в чем вопросы:
1) это от размера базы (в Мегабайтах) так падает производительность? или от количества записей? (... или оба)
В разумных пределах - ни от того, ни от другого, если правильные запросы. А запросы в WP наверно правильные.
2) В какую сторону оптимизировать MySQL в таких условиях? Что повышать и что понижать?
В даном случае необходимо периодично делать OPTIMIZE TABLE, так как таблицы содержат большие куски текста. И смотреть настройки MySQL
OPTIMIZE TABLE надо делать только в том случае, если идет много удалений из базы. А т.к. речь идет о статьях, они врядли удаляются и висят на сайте все время.
Может за тебя и зарплату получить?
OPTIMIZE TABLE надо делать только в том случае, если идет много удалений из базы. А т.к. речь идет о статьях, они врядли удаляются и висят на сайте все время.
Статьи еще могут и редактироваться.
Может за тебя и зарплату получить?
Это с кем вы там еще разговариваете?
Не... Они только добавляются пока.
Оптимизировал. Драматического прироста пока не заметил :)
table cache поднял с 64 до 256
key buffer c 16M до 32М
- работает стабильно, но также долго :)
Туда же
query_cache_size=8M
И дважды открыть главную страницу
Оптимизировал. Драматического прироста пока не заметил :)
О чем и речь:)
table cache поднял с 64 до 256
key buffer c 16M до 32М
- работает стабильно, но также долго :)
Покажи типичный запрос к БД и результат его EXPLAIN'a мне кажется индексы тебя спасут.
Попробуй еще включить кэширование запросов:
SET GLOBAL query_cache_size = 30000000;
Мы бы кэширование прикрутили... 20к статей, имхо могут этого заслужить.
Второй вариант - что бы не перебирать все запросы - включить лог slow query - посмотреть что в него нападает.
На таблицу posts повесили бы индексы на дату и категорию - там их почему-то по умолчанию вроде нет, хотя некоторые выборки с ними идут.
......................