Вопрос в следующем

еще не законченная страница сайта генерируется за 0,52 ms на локальном сервере,
это время включает все операции (выборка из базы, работа php)

Хороший ли это показатель? Надо ли оптимизировать?


Страница состоит из двух  частей:

1 левая рубрикатор - на ее часть отводится примерно 0,25-0,30 ms
2 Центральная список данных - очень большая 0,25-0,3ms думаю здесь нормально

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

Что касается базы, то выбоки не дожны тормозить, построены индексы по полям:
order_
id_categ
 

скажи, ты буковки ms для красоты пишешь, или это действительно миллисекунды?


прелестное утверждение. вне зависимости от того, тормозит база, или нет.
Просто прелестное.

Это первое открытие страницы, или второе? (результаты обычно отличаются из-за внутреннего кеширования в php)
Понимаю, что сравнивать нехорошо, но форум, подобный этому, со второго раза у меня отображается за 0.05-0.08 s. Так что есть к чему стремиться 

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

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

жутко криво... очень много времени.

Давайте попорядку..

1. Я построил индексы по полям которые учавствуют в запросе where и order, не силен в оптимизации но мои знания подсказали что нужно сделать именно так.

Результат: страница стала генерироваться за 0,13-0,10 ms после кешировая запросов

Это долго?Что можно еще сделать? Код PHP оптимизируемый?

sanich_, обычно оптимизируют логику, а не просто код

sanich_, наверное, ты имеешь в виду все-таки секунды.
а оптимизировать работу БД надо не теоретически,  "я там где-то какие-то индексы поставил", а практически.
В частности, измерять время выполнения запросов. А не заявлять, что они работают быстро, хотя ты это никак не проверил

sanich_, дам свои несколько комментариев:
1. Код который ты привел очень "кривой". Построение этого списка нужно делать с помощью 1 запроса. Нужно избегать вложенные с цикл запросы.
2. На мой взгляд, если БД практически пустая и ты это делаешь на локальном сервере, то это большое время. (Опять таки если ты имеешь в виду 0.52 сек, если это 0.52 миллисекунды то  это очень хороший результат).
3. Измерей кол-во запросов к БД при генерации одной страницы, их кол-во желательно тоже минимизировать.

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

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

Только на запрос уходит ~16ms-30ms


План запроса показал следующее, подскажите пожалуйста как оптимизировать


Присоединённый файл ( Кол-во скачиваний: 14 )
 Untitled_1___________.jpg 33,99 Kb

mishaSL, вот хотел я возразить, но не стал.
И что получилось.
От такой вот "оптимизации" - один вред.
Во-первых, запросы в цикле - не всегда зло. 20, скажем, однострочных выборок  по первичному индексу никого ничем не затормозят.
Во-вторых, желание "хоть тушкой, хоть чучелком" но запихнуть все в один запрос приводит к появлению таких вот монстров. Злокачественных опухолей на теле реляционной модели. Суть осталась та же, но можем гордо рапортовать, что один запрос!!!
Вообще, появление в мускуле вложенных ползапросов и юниона принесло очень много вреда, учитывая тот факт, что в подавляющей массе своей люди, использующие мускуль, являются новичками.
Это как коробка-автомат. Да, научиться ездить очень легко. Но водителем он уже никогда не станет. 

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

sanich_, 
если вернуться к первому варианту.
Сколько времени выполняется запрос 
select id_categ,categ from categ order by order_
в консоли mysql.exe
и сколько - вложенный в него, из рубрик. один, не все.

они должны исполняться, каждый, не дольше одной сотой секунды (мускуль пишет что-то вроде (0.05 sec).
причем выполнять надо не один раз, а несколько раз подряд.

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

Это сообщение отредактировал(а) GeneralElectric - 4.3.2008, 11:38

sanich_, SQL запрос должен быть примерно такой:


Как его результаты обработать в PHP думаю уже разберешься.

Добавлено через 8 минут и 36 секунд
GeneralElectric, я не говорю что всегда стоит все пихать в один запрос, но конкретно в данной ситуации - это практически стандартный и очень простой запрос. Здесь не должно быть никаких UNION и тем более вложенных запросов. Именно по-этому я дал такую критику вложенных в цикл запросов, т.к. в данном случае не используется никаких LIMIT, что может с ростом сайта привести к проблемам в его загрузке.

to GeneralElectric
Ну если чесно то самый первый вариант получения данных был хотябы проще для понимания, выбрал категорию, выбрад рубрики и.д.
А щас большой массив данных который еще пришлось по хитрому обработать, но повышения производительности это не прибавило!

Консоли Mysql у меня нет, стоит пакет TopServer, в папке mysql5 только mysqld-max-nt.exe ядро и тулза для дампа
Короче, я пользуюсь SQL yog enterprise

Запрос
select id_categ,categ from categ order by order_
в статус баре пишет то 0ms то 16ms, но чаще 0ms при многократном вызове, всего строк 42
Возможно не точно время определяется, подскажите как его точно засечь

Запрос
select id_rubrika,rubrika from rubrika where id_categ=2
7 строк, время 0ms

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

Щас и не знаю как проверить, разве что на ПХП мастерить цикл.