<b>PHP is an HTML-embedded scripting language</b>. The goal of the language is to allow web developers to write dynamically generated pages quickly.
Но это всё лирика! Макс всё равно БОЛЬШОЙ МОЛОДЕЦ!!! Проделать такую огромную работу за такой короткий срок! А оптимизация — дело техники. ;)
про лимиты:
Цитата:
Инногда достаточно большой проблемой является LIMIT в запросах, я не буду тут говорить, что некоторые вытягивают 100 записей, а иногда и 1000 если реально используют 10; скажу следующее — польза от лимита есть только тогда когда в запросе используется индекс по полю, которое сортируем, т.к. в противном случае Using temporary; Using filesort нивелируют всю пользу от лимита. Также стоит избегать лимитов следующего вида LIMIT 1000000, 25 т.к. выбраны все равно будут 1000025 записей, и только потом 1000000 отброшен. Такое часто используется для pagination, и многие программисты часто оправдываются тем, что пользователи все равно в основном ходят на новые страницы (последние в хронологическом порядке), т.е. запросы с такими лимитами выполняются достаточно редко… Да, пользователи заходят на страницы годичной, двухгодичной давности не часто, но если на сайт зайдет поисковый бот, то он зайдет на все страницы, и этот бот, индексирующий контент сайта, положит нам сервер БД.
btw! Какая разница, сколько записей в базе — сто или сто тысяч? Если структура базы и запросы написаны оптимально, то время их выполнения практически не будет отличаться вне зависимости от размеров базы. Что вывести десять записей из таблицы со ста записями, что из таблицы со ста тысячами — это фиолетово. Хотя у MySQL, конечно, есть и предел быстродействия, но он ГОРАЗДО выше выбора десятка строк джоином из пары таблиц с пятью тысячами записей. ;)
про цикл вайл:
ессно имелось ввиду не запросы по одному к базе :-)
я имел ввиду примерно
$res = mysqli_query(...);
while($row = $res->fetch_assoc()) { ...}
другими словами, запрос к базе ессно один (парсинг SQL один раз, если хотите), а вот получение результирующих рядов по одному
надеюсь с тем, что mysqli быстрее mysql, спорить не будете? :)
while($row = getSingleRow()) { ... }
Вы считаете, что запрос в цикле быстрее? Ой-ой!
Limit большое число, другое большое число
MySQL оптимизирует LIMIT, т.к. при выборе нескольких строк он не выполняет полное сканирование таблицы, а использует индексы. ;)
кинул в личку ссылку.
В качестве версии могу предположить вот что:
запросы
$rows = getAllRows()
foreach($rows as $row){ ... }
значительно медленнее, чем
while($row = getSingleRow()) { ... }
так как в первом случае приходится все ряды загружать в память php-интерпретатора/модуля веб-севрера, а во втором только по одному. при использовании смарти, к сожалению, из коробки возможен только первый вариант :( если отделять логику и представление и передавать ее объекту результирующий массив.
ну и, конечно, Limit большое число, другое большое число значительно тормознутее, чем where чтото >= чегото AND чтото < чего-то или чтото BETWEEN чегото AND чегото, т.к. в первом случае мускль сначала выбирает все ряды, удовлетворяющие where-у и условиям JOIN-ов, создает временную таблицу и из нее уже отдает что указано LIMIT-ом. создание временных таблиц операция дорогая до памяти и времени, а во 2-м и 3-м случае этого не происходит
В журнале ошибок пишет такую хрень [Wed Sep 24 20:07:33 2008] [error] [client 66.249.71.198] SoftException in Application.cpp:544: Directory «/***путь***/public_html» is writeable by group
В общем как я и подозревал поддомен оказался ни при чем. Поставил в основной домен и вот что происходит, после изменения аватары в профиле папка public_html получает права 777, дальше внутри все нормально ибо когда возвращаю ей права 755 сайт нормально запускается. Что я могу предъявить хостеру? Разные нюки, слаеды, жумлы, друпалы и прочее нормально работали. Хостер просто пошлет меня подальше…да и как бы он будет прав. Раз после моих действий с движком папка public_html получила права 777 то они и скажут — разбирайтесь со своими скриптами. Я спрошу конечно у них почему такое может быть, но ответ очевиден. Посуди сам Максим. Насчет хостера могу сказать, что php установлен как CGI, а так нормальный вполне хостер.
ща дамп сниму и залью куданить. ссылку на куданить кину в личку.
только там дамп «грязный» — комментов в базе нет, теги в таблице для поиска по тегу не перенесены, где-то слеши лишние экранирующие не удалены. короче чисто база для экспериментов по быстродействию. но даже на этой базе без комментов, только что проверил, тормоза более чем заметны
можешь дать эту БД? чтоб реально оценить запросы
текст хранится в 3-х видах как раз для оптимальности: анонс — чтоб не воротить большой текст при выводе списка блогов, сам текст и исходный текст до обработки парсером — без этого никак, иначе будет много проблем с парсером.
если тормаза из-за ордер бая при больших текстах то это решается через селфджойн. Вобщем мне нужна большая БД чтоб что то сделать :)
Быстрее, имхо, ничего не придумано. :)
<b>PHP is an HTML-embedded scripting language</b>. The goal of the language is to allow web developers to write dynamically generated pages quickly.
Но это всё лирика! Макс всё равно БОЛЬШОЙ МОЛОДЕЦ!!! Проделать такую огромную работу за такой короткий срок! А оптимизация — дело техники. ;)
Смарти вообще урод! Зачем его использовать в языке, который изначально создан для отделения кода от представления. ;)
<html><body><?=$var?></body></html>
будет выполнятся точно быстрее, чем отпарсенное смарти:
<html><body>{var}</body></html>
Но раз автор движка выбрал его — значит руководствовался некими соображениями на этот счет.
Всё верно. Выше я отметил, что mysql использует индексы вместо полного сканирования таблицы. Если индексы по этим полям есть! +))
SELECT
*
FROM
`table`
WHERE
id>X*Y-1
LIMIT
X;
Зачот! :)
по спорить сори)
Цитата:
Инногда достаточно большой проблемой является LIMIT в запросах, я не буду тут говорить, что некоторые вытягивают 100 записей, а иногда и 1000 если реально используют 10; скажу следующее — польза от лимита есть только тогда когда в запросе используется индекс по полю, которое сортируем, т.к. в противном случае Using temporary; Using filesort нивелируют всю пользу от лимита. Также стоит избегать лимитов следующего вида LIMIT 1000000, 25 т.к. выбраны все равно будут 1000025 записей, и только потом 1000000 отброшен. Такое часто используется для pagination, и многие программисты часто оправдываются тем, что пользователи все равно в основном ходят на новые страницы (последние в хронологическом порядке), т.е. запросы с такими лимитами выполняются достаточно редко… Да, пользователи заходят на страницы годичной, двухгодичной давности не часто, но если на сайт зайдет поисковый бот, то он зайдет на все страницы, и этот бот, индексирующий контент сайта, положит нам сервер БД.
А! Ну это:
$res = mysqli_query(...);
while($row = $res->fetch_assoc()) { ...}
правило хорошего тона уже :)
Я вообще не спорю, а высказываю свое имхо :)
про цикл вайл:
ессно имелось ввиду не запросы по одному к базе :-)
я имел ввиду примерно
$res = mysqli_query(...);
while($row = $res->fetch_assoc()) { ...}
другими словами, запрос к базе ессно один (парсинг SQL один раз, если хотите), а вот получение результирующих рядов по одному
надеюсь с тем, что mysqli быстрее mysql, спорить не будете? :)
while($row = getSingleRow()) { ... }
Вы считаете, что запрос в цикле быстрее? Ой-ой!
Limit большое число, другое большое число
MySQL оптимизирует LIMIT, т.к. при выборе нескольких строк он не выполняет полное сканирование таблицы, а использует индексы. ;)
кинул в личку ссылку.
В качестве версии могу предположить вот что:
запросы
$rows = getAllRows()
foreach($rows as $row){ ... }
значительно медленнее, чем
while($row = getSingleRow()) { ... }
так как в первом случае приходится все ряды загружать в память php-интерпретатора/модуля веб-севрера, а во втором только по одному. при использовании смарти, к сожалению, из коробки возможен только первый вариант :( если отделять логику и представление и передавать ее объекту результирующий массив.
ну и, конечно, Limit большое число, другое большое число значительно тормознутее, чем where чтото >= чегото AND чтото < чего-то или чтото BETWEEN чегото AND чегото, т.к. в первом случае мускль сначала выбирает все ряды, удовлетворяющие where-у и условиям JOIN-ов, создает временную таблицу и из нее уже отдает что указано LIMIT-ом. создание временных таблиц операция дорогая до памяти и времени, а во 2-м и 3-м случае этого не происходит
только там дамп «грязный» — комментов в базе нет, теги в таблице для поиска по тегу не перенесены, где-то слеши лишние экранирующие не удалены. короче чисто база для экспериментов по быстродействию. но даже на этой базе без комментов, только что проверил, тормоза более чем заметны
текст хранится в 3-х видах как раз для оптимальности: анонс — чтоб не воротить большой текст при выводе списка блогов, сам текст и исходный текст до обработки парсером — без этого никак, иначе будет много проблем с парсером.
если тормаза из-за ордер бая при больших текстах то это решается через селфджойн. Вобщем мне нужна большая БД чтоб что то сделать :)
для попадания в эфир..., сорри