Координальные методы оптимизации сайта

использовать индексы или оптимизировать выборки при помощи создания временных таблиц по крону.

Stek,

А можно поподробнее немного, насчет временных таблиц по крону?

Индексы использую (если это про поле id).

The Wishmaster

По русски можешь не писать, но базы данных знать обязан :)

По сути делается анализ базы и кода, т.е. какие данные запрашиваются.

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

Теперь смотрим как часто у нас все это обновляется. Если обновление не 10 раз за час, то делаем таблицы (или расширяем существующие) где уже идут записи "статья -> число коментариев" , "группа -> число статей" и так далее.

И при формировании страницы обращаемся уже к этим сформированным данным.

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

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

Мне известны следующие способы:

1. Кеширование вывода.

На эту тему написано много статей для программеров. Они верны. Нужно только прочесть вдумчиво.

Перепечатывать смысла не вижу.

2. "Тонкая" конфигурация апача.

Основной принцип:

Вы видели сколько пач ест памяти?

Отлично, если вы думаете что кеширование или уловки вроде пропускания трафика через более "лёгкий" (в плане памати) прокси улучшат ситуацию, вы заблуждаетесь!

Приходит к вам посетитель, на index.html, и первый раз, он прогружает все ваши .js, .css, .gif, и прочие файлы, которых может быть не один десяток на эту самую страницу, и тут уже вам никакое кеширование не поможет, потому что он пришел на ваш сайт первый раз!

Если таких посетителя прейдут 2 в одну секунду, то мы получим 40-50 потоков апача, каждый из которых съест память, будет свопить, своп ещё усугубит ситуацию.

Решение:

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

3. Уменьшить количество файлов необходимых для формирования страниц, особенно страниц посещаемых однократно новыми посетителями (где кеширование практически бесполезно).

Видимо в вашем случае, страниц со статьями, на которые попадают посетители с поисковых и постоянно разные.

Например, делать не:

<link rel="stylesheet" type="text/css" href="filte1.css">

<link rel="stylesheet" type="text/css" href="filte2.css">

<link rel="stylesheet" type="text/css" href="filte3.css">

а объединить всё в один файл.

Убрать:

<link rel="SHORTCUT ICON" href="file.ico">

и тому подобное.

4. Оптимизировать выборки из БД.

Об этом тоже написано много статей, в интернете некоторые, хорошие, можно найти по ключевой фразе:

"Оптимизация SELECT и других запросов".

5. Отказаться от php, perl, переписать самые часто вызываемые скрипты на с++, написать собственные, более специализированные и следовательно более быстрые и экономичные демоны-серверы, которые будут заниматься, скажем выводом картинок.

Пожалуй, самый смешной пункт, особенно смешным, он покажется для тех, кто понятия не имеет чем php от perl и чем perl от c++ отличается и думает что php, это самый быстрый и лучший язык для создания поистине качественных веб систем.

По этому здесь не рассматриваем :)

Вот собственно и всё что можно сделать, если жалко денег на более мощный сервер.

Наводящие на ответ вопросы:

a) А что мешает сделать для каждой категории свою таблицу?

b) Что мешает сделать ещё одну таблицу my_counter_table, где держать только значения количества записей в каждой категории и делать ++/-- значениям при добавлении или удалении статьи из той или иной категории?

c) Вообще-то если поле с ID_категории индекс и тип его, скажем bigint, и статьи идентифицируются ID тип поля которого bigint, то выборка нескольких десятков тысяч статей не должна занимать много времени, точнее будет занимать очень мало времени. У вас ID_категории - индекс?

P.S. Извините, что как всегда много написал :)

Не перебор всей базы а перебор одного только поля ID, которое индекс.

Конечно в том случае если вы делаете так:

select id from table, а не

select * from table

и после этого mysql_num_rows()

Такие запросы для подсчета количества записей занимают ОЧЕНЬ мало времени, тем более при небольших базах.

SELECT COUNT(*) FROM Table WHERE categoryID=13

Попробуйте так, если не делаете. Выборка с COUNT(*) обычно быстрее, чем COUNT(id), но это для случая, когда не указано where , а вот когда с ним точно не помню, возможно разницы не будет.

"Нагруженность" запросов и необохидомость присутствия/отсуствия индексов определяется оператором EXPLAIN о нём можно прочитать в мане по майскуэль.

Опять же не видя кода и запросов трудно что-то говорить.

К выше сказанному добавить практически нечего, ибо ответы были даные исчерпывающие.

Добавлю только, что в MySQL есть встроенная функция, показывающая сколько времени длится тот или иной запрос: benchmark().

Ситаксис:

SELECT benchmark(<сколько раз выполнять запрос>, <запрос>);

Возвращает функция время выполнения запроса.