Облако тегов. Помогите оптимизировать.

[vxc]

Облако тегов. Помогите оптимизировать.

Есть блог на собственном движке. Сделал облако тегов, но кажется, что сделал не лучшим образом. Пожалуйста, помогите оптимизировать расход ресурсов сервера.

есть таблица blog_tagcount
1 столбец - тег
2 столбец - сколько раз этот тег использовался

function tagcloud_show() 	
{ 		
         // забираем из базы все данные
         $result_tag = mysql_query("Select * from blog_tagcount ORDER by tag "); 
         $tag_blog_data=''; 	

         //перебираем теги в цикле
         while(list($tag,$count) = mysql_fetch_row($result_tag)) 		
         { 		
                  //обнуляем переменную
                  $font_size=''; 	
	
                  // в зависимости от того сколько раз использовался тег выбираем для негоразмер шрифта.
                  if($count==1) {$font_size=1;} 		
                  if($count>2) {$font_size=2;} 		
                  if($count>4) {$font_size=3;} 		
                  if($count>7) {$font_size=4;} 	
                  if($count>10) {$font_size=5;} 		

                  //генерируем html код
                  $tag_blog_data.=", <font size=$font_size><a href=\"/blog/tag/$tag/\">$tag</a></font>"; 		
         } 	

         //обрезаем запятую и пробел для первого тега.
         $tag_blog_data=substr($tag_blog_data,2); 		
         return $tag_blog_data;
}

На данный момент порядка 170 тегов.

Заранее благодарен.

 

[Adelf]

А что? уже тормозит сервер из-за тегов?

А вообще можно лишь:

$tag_blog_data='';
=>
$tag_blog_data=array();



$tag_blog_data.=", <font size=$font_size><a href=\"/blog/tag/$tag/\">$tag</a></font>";  
=>
$tag_blog_data[]="<font size=$font_size><a href=\"/blog/tag/$tag/\">$tag</a></font>";  



$tag_blog_data=substr($tag_blog_data,2);         
return $tag_blog_data; 
=>
return join(', ', $tag_blog_data);

Сильно быстрее не станет, но так писать лучше.

 

[vxc]

Не то, чтобы тормозит, но по логам xdebug видно, что на это "место" прилично времени нравится.

Спасибо за советы

Можно еще вопросик?

Периодически нужно из строки вырезать всякие символы (' _ - ! ? и прочие, порядка 10 штук).
Использую 10 раз
$data=str_replace("","_",$data);
и чувствую, что это совершенно неправильно. Как будет лучше?

 

[Wicked]

а что именно из этого тормозит, xdebug не говорит? этот код слишком простой, чтобы тупить на 170 записях, особенно если есть ли индекс по полю tag в таблице.

 

[HraKK]

print str_replace(array("(","_","x") ,'', 'fdsffhsx_(sadasd');

-~{}~ 23.02.10 22:29:

если есть

ключевое слово.

 

[vxc]

Автор оригинала: Wicked
а что именно из этого тормозит, xdebug не говорит? этот код слишком простой, чтобы тупить на 170 записях, особенно если есть ли индекс по полю tag в таблице.

В таблице есть:
Имя индекса Тип
PRIMARY PRIMARY

Переделать на
tag INDEX
?



HraKK, спасибо. То что нужно.

 

[HraKK]

Не переделать, а добавить

 

[zerkms]

на 170 записях с индексом или без - определить не получится

 

[vxc]

Автор оригинала: HraKK
Не переделать, а добавить

А в остальных таблицах тоже стоит такой индекс добавить? По уникальному полю добавлять?А что это дает?

 

[dimagolov]

vxc, ну почитай что такое индексы, для чего они нужны. это основы понимания того, как работает БД.

 

[vxc]

Автор оригинала: dimagolov
vxc, ну почитай что такое индексы, для чего они нужны. это основы понимания того, как работает БД.

Прочитал, но все-равно открытым остался вопрос....

Есть таблица в 500 строк с записями блога.
Я так понимаю для вывода конкретной записи по ID, index на ID скажется очень хорошо.
Но кроме вывода конкретной записи есть еще и лента с записями, а в этом случае лучше последовательное чтение.
Так стоит ли ставить индекс? А если записей 20.000?

 

[zerkms]

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

а сортировка?

 

[vxc]

Сортировка в ленте тоже по ID, так что лучше ставить index на ID?

А если бы в базе было 10 записей и лента записей вызывалась в разы чаще чем какая-то конкретная запись?

Прошу прощения за кучу вопросов, но что-то не совсем понимаю этот момент

 

[zerkms]

vxc
для быстрой сортировки также нужен индекс. причём WHERE должен быть полностью покрыт индексом, а сортируемое поле или совпадает с единственным полем, сравниваемым > или <, либо быть rightmost от используемых полей и все сравнения = (или подобны ему).

ps: я стал слабо понимать твои вопросы, побольше конкретики. м?

-~{}~ 25.02.10 17:19:

А если бы в базе было 10 записей и лента записей вызывалась в разы чаще чем какая-то конкретная запись?

и что бы это изменило?

 

[vxc]

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

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

 

[zerkms]

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

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

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

индекс работает для сортировки. и в случае выборки 10 записей из 10 всего - индекс не будет использоваться. (потому что внутренние механизмы mysql определят, что записей слишком мало). вот как только их будет > 30 (примерно), тогда индекс будет использован.

 

[Wicked]

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

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

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

в в случае с 10 записями это никого особо и не волнует

 

[vxc]

Автор оригинала: Wicked
при наличии нескольких индексов в таблице mysql сам выбирает наболее подходящий. Так что тебе сейчас лучше думать, что не сможешь... и спокойно экспериментировать.

Просто тогда не совсем понятно что мешает зафигачить индексы на все поля куда только модно)

Если 95% выборок идет по полю ID, и только 5% по полю CUSTOM есть ли смысл ставить индекс и на CUSTOM тоже?

 

[zerkms]

vxc

Просто тогда не совсем понятно что мешает зафигачить индексы на все поля куда только модно

тем что:
1. это замедлит модификацию таблы
2. увеличит её вес
3. и даже это не гарантирует эффективность выборок

Если 95% выборок идет по полю ID, и только 5% по полю CUSTOM есть ли смысл ставить индекс и на CUSTOM тоже?

есть
прими за правило, что КАЖДЫЙ запрос должен выполняться с использованием индексов.

 

[vxc]

Всем огромное спасибо за разъяснения!

-~{}~ 25.02.10 13:50:

Автор оригинала: vxc
В таблице есть:
Имя индекса Тип
PRIMARY PRIMARY

Переделать на
tag INDEX
?

Автор оригинала: HraKK
Не переделать, а добавить

Значения поля tag - уникальны и не повторяются.
Добавляю для него же индекс - index
phpmyadmin ругается - Следующие индексы определены как идентичные, и один из них должен быть удален: PRIMARY, tag