Секреты мастерства оптимизации

[lifestar 18]

Итак, господа, пришло время поговорить об оптимизации.

Речь пойдёт не работе над сайтом для поисковых машин, а о суть не менее важной вещи, как оптимизация кода, кеширование и о прочих не мало интересных вещах.

---

Глава 1. аля SQL

Сейчас многие помешались прямо таки на кешировании sql запросов. И иногда я спрашиваю себя - а всегда ли оправданно это делать?

Я встречал многих людей, которые думаю, что "чем меньше запросов - тем быстрее и лучше", совсем не задумываясь о других параметрах скорости выполнения и загрузки скрипта.

К примеру, простой запрос как

SELECT id, date, title, text FROM table WHERE approve=1 LIMIT 0, 5

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

Разве чтение файла с кешем и выполнение этого запроса не одно и тоже с точки зрения процесса?

Конечно есть такие ньюансы как индексы и количество рядов (размер).

Мне бы хотелось узнать, если индексы расставлены верно, да и проект БД удачный то когда наступает тот момент, когда уже действительно следует кешировать результат запроса?

Глава 2. Работа с файлами

Предположим перед нами стоит задача вывести на экран фотографии из какой-либо директории.

Что-то наподобие фотогалереи.

Каким образом мы можем это сделать?

Способ 1.

Примерно так

	$files = array();

	$path = 'Путь к директории';

	if (is_dir($path))

	{

		if ($dh = opendir($path))

		{

			while (($file = readdir($dh)) !== false)

			{

				if ($file == "." || $file == ".." ) continue;

				$files[] = $file;

			}

			closedir($dh);

		} else die ("Не могу открыть  $path");

	} else die ("Это не директория нифига");

Загнали имена файлов в массив и работаем с ним.

Способ 2.

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

Может есть и ещё способы, но я их не знаю.

Таким образом получается, что кажется будто способ 2 лучше и быстрее.

Внимание вопрос: а что если файлов будет 10 тысяч и размер нашего xml файла несколько мегабайт, тогда что быстрее и мене енагружабельно для сервера?

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

P.S. конечно файлы можно выводить по 20 штук например. Опять таки, какой способ лучше для этого случая?

Изменено 28 августа 2007 пользователем lifestar

[sk-soft 0]

lifestar, очень интересная тема, хотя я мало в этом разбираюсь, но я так понял, что кешировать большие запросы нет смысла, и это будет больше грузить сервер чем без кеширования, может мне попробовать отключить временно кеширование? возможно в нем все и дело?

Этот вопрос скорее всего задаю я сам себе.

Да и в оффтоп - хотел спросить. Есть ли у тебя какие нибудь реальные наработки с оптимизацией дле? мне очень нужно, так как у меня поднялась посещалка до 10 000 а реальной помощи от разработчика двига я получить не могу, да это и понятно, я не оплатил платную тех поддержку.

Был бы очень благодарен еслиб возможно ты поделился версией оптимизированной, если что, могу ее даже купить, деенг не много но 10-20 wmz могу дать. просто я сейчас как у разбитого корыта, хостеры говорят что это не их дело ковыряться в движке, разраб тоже самое, + мою тему закрыл. Я не пиарю, просто действительно некоторые сайты с дле с базой более 300 метров вполне живут, (натахаус, бинмуви) некоторые с базой 70 метров(мой суперварез) просто умирают от нагрузки.

Я бы тебе ПМ отправил, но они у тебя вроде отключены

[lifestar 18]

sk-soft, дело в том, что я как раз не занимался механизмом кеширования и поднял эту тему для того, чтобы самому разобраться что к чему.

Когда сделаю - поделюсь.

А насчёт больших и сложных запросов - их то я думаю кешировать как раз и следует, другое дело маленькие =)

[Akela 9]

...

а реальной помощи от разработчика двига я получить не могу, да это и понятно, я не оплатил платную тех поддержку.

Был бы очень благодарен еслиб возможно ты поделился версией оптимизированной, если что, могу ее даже купить, деенг не много но 10-20 wmz могу дать. просто я сейчас как у разбитого корыта, хостеры говорят что это не их дело ковыряться в движке, разраб тоже самое, + мою тему закрыл. Я не пиарю, просто действительно некоторые сайты с дле с базой более 300 метров вполне живут, (натахаус, бинмуви) некоторые с базой 70 метров(мой суперварез) просто умирают от нагрузки.

...

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

По поводу кэша - при большой базе чтение файла кэша на порядки быстрее обращения к базе данных.

В любом случае МуСКЛльный сервер читает данные из файла, просто при маленькой базе это время не сильно дольше, чем чтение обычного текстового фала кэша. От кэша можно отказаться, разместив базу в памяти, но так есть больше шансов ее испортить или вовсе потерять при возникновении проблемы на сервере.

[lifestar 18]

Akela, что скажете по поводу "Глава 2. Работа с файлами"?

Что всё таки лучше - "обзор" директории или считывание xml файла?

[Akela 9]

lifestar,

Также как и в 1 пункте, тут все зависит от количества картинок. При количестве более 100 - однозначно лучше второй способ, только сохранять надо не в один файл, а группировать по 20-30 картинок в файл. Кроме того, дополнительным аргументом следует учесть, что частота добавлений и изменений картинок не сравнима с частотой их просмотра, а выводить готовый файл всегда быстрее.

[lifestar 18]

а выводить готовый файл всегда быстрее.

Быстрее чем что?

[Akela 9]

Чем каждый раз сканировать директорию и записывать имена файлов.

[lifestar 18]

Хорошо, спасибо!

[fogmaker 0]

Не совсем оффтоп: разве DLE разрабатывалась без оглядки на nginx?

[lifestar 18]

разве DLE разрабатывалась без оглядки на nginx?

Раскройте полнее вопрос, не совсем ясно что значит "без оглядки"