Интересная логика кода

[celsoft 6 044]

Это принято. Спасибо. Уберем.

[proba 57]

В файле engine/modules/feedback.php имеется:

$count_files = 0;
//...
if (is_array($file['name'])) {
//...
	if( $count_files < $max_mail_files ) {
		$size = $size + $file['size'][$count];
		$count_files ++;
//...
} else {
//...
	if( $count < $max_mail_files ) {
		$size = $size + $file['size'];
		$count ++;

При выполнении условия, $count относится к foreach, а когда нет - не определена. Там нужна замена на $count_files.

Такая же картина и в ajax/feedback.php.

[celsoft 6 044]

2 часа назад, proba сказал:

В файле engine/modules/feedback.php имеется:

$count_files = 0;
//...
if (is_array($file['name'])) {
//...
	if( $count_files < $max_mail_files ) {
		$size = $size + $file['size'][$count];
		$count_files ++;
//...
} else {
//...
	if( $count < $max_mail_files ) {
		$size = $size + $file['size'];
		$count ++;

При выполнении условия, $count относится к foreach, а когда нет - не определена. Там нужна замена на $count_files.

Такая же картина и в ajax/feedback.php.

Принято, спасибо

[Gameer 310]

Вроде бы как лишний запрос который сильно влияет на нагрузку. В engine/modules/cron.php в цикле есть следующий запрос

$db->query( "DELETE FROM " . PREFIX . "_views WHERE news_id = '{$row['news_id']}'" );

Но ниже, после цикла есть другой запрос

$db->query( "TRUNCATE TABLE " . PREFIX . "_views" );

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

[celsoft 6 044]

Только что, Gameer сказал:

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

Это не лишний запрос. И именно потому что новостей может быть очень много, он и присутствует. Так как часто в таких случаев если на сервере установленно ограничение на время работы, процедура переноса просмотров может быть не выполнена полностью, и если запроса не будет, то во первых перенос начнется повторно уже перенесенных при запуске, во вторых может быть потеря просмотров. Поэтому и идет эта синхронизация, когда перенесено -> сразу удалено. Поэтому она не просто так.

[Gameer 310]

1 минуту назад, celsoft сказал:

Это не лишний запрос. И именно потому что новостей может быть очень много, он и присутствует. Так как часто в таких случаев если на сервере установленно ограничение на время работы, процедура переноса просмотров может быть не выполнена полностью, и если запроса не будет, то во первых перенос начнется повторно уже перенесенных при запуске, во вторых может быть потеря просмотров. Поэтому и идет эта синхронизация, когда перенесено -> сразу удалено. Поэтому она не просто так.

Да, всё логично. Но всё же, процесс как-то этот оптимизировать нужно, порой несколько десятков тысяч запросов может выполнятся за раз. 

[celsoft 6 044]

8 минут назад, Gameer сказал:

Но всё же, процесс как-то этот оптимизировать нужно

Как? Тут нет каких то алгоритмов оптимизации. Если знаете, то скажите как можно оптимизировать.

8 минут назад, Gameer сказал:

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

Я бы вообще на вашем месте в таком случае отключил кеширование счетчика в отдельную таблицу, во первых он давно вынесен за текстовую таблицу, поэтому и в основной будет выполнятся быстро, во вторых InnoDB  не блокирует на уровне таблицы, а только на уровне строк. Поэтому кешировать отдельной таблицей давно потеряло актуальность. Это было актуально при MyISAM, и остается в DLE исключительно для очень старых сайтов, которые давно построены и их движок MySQL не изменен с MyISAM на InnoDB. Если у вас InnoDB то отключайте кеширование счетчика в отдельную таблицу, так сайту наоборот будет легче жить.