Какую нагрузку на сервер создает Vivvo?

[parempi]

ну значит не работает

Извини, ничего умнее не могу сказать. Не юзал 4.* и не собираюсь.
На демке она мне не нравится и жалоб куча на баги и кривоту от тех, кто юзал...

 

[Saboteur]

А собственно в админке проверяли, что опция кеширования включена?
Preferences -> Layout & modules : Enable caching

 

[gaiwan]

Поставил недавно плугин (или адд-он) Yslow к Firefox. Прекрасный анализатор страницы. При нажатии на performance выдает оценку (по шкале ABCDEF и %) скорости загрузки, причины тормозов и рекомендации.

Vivvo 4 в разных ипостасях держит B и C (что очень хорошо), а джумла выше D не поднимается ни в какой комплектации.

Всем советую.

 

[Sipaj70]

Грузовик Vivvoo v3.5

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

Глянул нагрузку на серваке и действительно - при 15 тысячах новостюх, загрузку даёт на базу серьезную (MySQL).

Первое что обнаружил в таблице tblArticles - поле created не проиндексированно. Т.е., при большом числе статей мускулу приходилось просматривать всю таблицу, из-за чего тормоза... Включение индексации для этого поля дала сразу 50% рост производительности.

Но вся проблема не в этом... Как оказалось, движок регистрирует просмотры в той же таблице tblArticles и сохраняет дату и время в поле last_read. К чему это приводит? Каждый просмотр страницы приводит к сбросу в MySQL кеширования для всех запросов к этой (основной!) таблице. Т.е., оптимизация запросов в БД для Vivvoo v3.5 не работает ВООБЩЕ! У меня сложилось впечатление, что те, кто делал двиг в некотором смысле лузеры. Нельзя часто изменяемые поля и часто читаемые хранить в одной таблице...

Помог своему знакомому так:
папка Class, файл Article.class.php
Дальше коментируються следующие обращения к БД в соответствующих функциях.

	// Method which update time of reading.Each time call in ShowArticle method.
	function UpdateReadings()
	{
		$this->ResetReadings();
		if (empty($this->Id)) return false;
		$id=$this->Id;
		$time=date("Y-m-d H:i:s");
//		$query="UPDATE tblArticles SET
//						times_read=times_read+1,
//						today_read=today_read+1,
//						last_read='$time'
//						WHERE id=$id";
//		$result=mysql_query($query) or sql_error($query, "Bad query update readings");
	}
	function ResetReadings()
	{
		$date=date("Y-m-d");
//		$query="UPDATE tblArticles SET
//						today_read=0
//						WHERE last_read<'$date' and today_read>0";
//		$result=mysql_query($query) or sql_error($query, "Bad query reset readings");
	}

После этого скорость генерации страницы с 3,5 секунд упала до 0,14 сек.

Так что если у вас такие же проблемы - можете воспользоватся этим решением.

 

[alexanderman]

по нагрузке

вот о нагрузке другого плана, у меня при создании бекапа
разговаривал с хостером, говорит их процессоры специально ограничены на такие операции сторонних движков, хотя можно бэк базы создавать и в панели управления хостингом, но можно ли как устранить данную проблему? ведь удобней сохранять исходную базу sql через личную систему ви.... (v.4.O3)
Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 8651267 bytes) in /home/base/public_html/name00000.ru/lib/backup/mysql_backup.php on line 167

 

[Saboteur]

Попробуй в начало conf.php file - добавить:
ini_set("memory_limit","32M");

 

[gimmo]

Vivvo -apache -php

Смотрим на страничку (морда или категория)
видим на каждой картинке нечто вроде

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

который втихаря вызывает ещё и files.php
Что мы имеем? Невменяемое количество чайлдов апача (prefork+mod_php) тянущее в своп при относительно небольшой нагрузке.
worker + fcgi не совсем спасает (в своп не лезем, но работаем потупше)
Что делать? - а вот что:

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

Попутно вопрос - никто не цеплял к этому чуду memcashed на mysql ?
Собственно даже это вопрос не по vivvo, а по mdb2 - как я понимаю..
И ещё - индексы все составные ( типа status_created_category_id ) - а как-то давно я подметил, что составные индексы в добрые пару раз тормознутей , нежели отдельные . Кроме того, в этих самых составных индексах у вивы одно поле участвует по нескольку раз, на что даже phpmyadmin ругается желтыми варнингами...
Или иначе - не переводил ли кто вивву на InnoDB?

 

[gimmo]

вот о нагрузке другого плана, у меня при создании бекапа
разговаривал с хостером, говорит их процессоры специально ограничены на такие операции сторонних движков, хотя можно бэк базы создавать и в панели управления хостингом, но можно ли как устранить данную проблему? ведь удобней сохранять исходную базу sql через личную систему ви.... (v.4.O3)
Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 8651267 bytes) in /home/base/public_html/name00000.ru/lib/backup/mysql_backup.php on line 167

Sypex dumper light ?

 

[InoffLine]

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

 

[maochai]

Не могу сказать в цифрах, но моя vivvo 3.4 имея одноврменно на борту 500 юзров и 3000 статей, сервак особо не грузит. Вот 3.5 чуток тормознее. Про 4.00 я промолчу, неоднозначное мнение о нем у меняю