Как разбить выполняемую работу на удобоваримые сервером куски? - страница 4 - Разработка расширений для Joomla

borro, попробуйте вариант от dmitry_stas и отпишитесь, раз

Филипп, ваш файл с настройками не разбит на секции c [] Это нормально?

я ошибся до секунды там далеко
старт 1500039943.7579, финиш 1500039943.7904

получается никакого AJAX не надо? И так будет практически на любом даже слабом хостинге?

вы у себя попробовали?

...
class Vm3delpicsControllerDBDelete extends JControllerAdmin{

	protected $view_list = 'dbdelete';//вид, который будет загружаться после удаления фотографии(й)
	
	public function getModel($name='DBDelete', $prefix='Vm3delpicsModel', $config=array()){//$name - имя модели
		return parent::getModel($name, $prefix, $config);
	}
...

...
class Vm3delpicsModelDBDelete extends JModelList {
	
	protected function getListQuery(){
		$db = JFactory::getDbo();
		$query = $db->getQuery(TRUE);
		$query->select('file_title,file_url,published,m.virtuemart_media_id');
		$query->from('#__virtuemart_medias m LEFT JOIN #__virtuemart_product_medias pm ON pm.virtuemart_media_id = m.virtuemart_media_id');
		$query->where('m.file_type = \'product\' AND pm.virtuemart_media_id IS NULL');
		return $query;
	}
...

в phpMyAdmin то с результатами возвращается надпись о том, что запрос выполнялся 8 секунд. Тем не менее по часам - все полторы минуты.

Может быть Вам банально не хватает оперативки или процессорной мощности.

пытаюсь, но я пока не могу понять, куда вставить ваш код

Согласно phpMyAdmin, запрос занял 0.7512 сек. Ищите проблему в настройках сервера. Может быть Вам банально не хватает оперативки или процессорной мощности.

медленнее чем 2 независимых запроса, потому что просто в данной ситуации без индексов не может быть по другому

это как проверить?

Логи нагрузки на сервере обычно показывают расклад.

А зачем замерять между началом и окончанием удаления лишних строк из массива?

у меня на ПК c Win 64 бит около 60 сек в phpMyAdmin занял этот запрос.

ОК, сейчас проверю

ALTER TABLE `ytgb1_virtuemart_product_medias` ADD INDEX `idx_vm_product_medias_media_id` (`virtuemart_media_id`);
ALTER TABLE `ytgb1_virtuemart_medias` ADD INDEX `idx_vm_medias_media_id` (`virtuemart_media_id`);

их где искать, по какому пути?

RESET QUERY CACHE;

после того, как я добавил индексы:
Запрос с JOIN стал в 3 раза быстрее двух независимых запросов.

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

Было 60 сек

поля проиндексированы.
переделываю на вариант с left join, протестирую...

Видимо надо было создать 1 дополнительный индекс чисто на virtuemart_media_id для vm_product_medias. Правильно?
И добавить в архив компонента запрос по созданию индекса на таблицу. Проблем же с правами не будет на это?

Видимо надо было создать 1 дополнительный индекс чисто на virtuemart_media_id для vm_product_medias. Правильно?

А 2 запроса оказались быстрее JOIN, кстати, потому что поле file_type проиндексировано уже, и по нему нет перебора. Так бы, если бы и на file_type индекс отсутствовал, то можно было бы вообще повеситься

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

Количество строк в выборке может быть меньше 30%, и тогда индексы используются. Короче говоря, это всё условно и с большой натяжкой.