Почему один и тот же последовательный запрос работает медленнее?

и что же не так с кодом? То что это не ООП?

Даже не знаю с чего начать. Я ведь не могу сказать, что код ужасен везде и всюду )
Давайте я попозже сделаю вам небольшой рефакторинг, а вы сами найдете ваши косяки.

Хорошо, спасибо заранее

Специально оставил «не-ООП», просто причесал ваш код. Если будут вопросы — спрашивайте.

<?php

session_start();
require_once($_SERVER['DOCUMENT_ROOT'] . '/includes/db_connect.php');

/**
 * @return bool|PDO
 */
function get_db_connection() {
  static $_instance = null;
  if (is_null($_instance)) {
    $_instance = new PDO(
      'mysql:host=myhost;dbname=mydb',
      'login',
      'password',
      array(PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8')
    );
    if (is_null($_instance)) {
      return false;
    }
  }
  return $_instance;
}

/**
 * Получает ID автора.
 * @param $post_id Post id
 * @return int
 */
function get_post_author_id($post_id) {
  $db = get_db_connection();
  $stmt = $db->prepare('SELECT from_user FROM posts WHERE id = :id LIMIT 1');
  if (!$result = $stmt->execute(array(':id' => $post_id))) {
    return null;
  }
  if (!$post = $stmt->fetch(\PDO::FETCH_ASSOC)) {
    return null;
  }
  return $post['from_user'];
}

/**
 * Получает картинки поста.
 * @param $post_id
 * @return array
 */
function get_post_images($post_id) {
  $db = get_db_connection();
  $stmt = $db->prepare('SELECT post_images FROM posts WHERE id = :id AND from_user = \'1\' LIMIT 1');
  if (!$result = $stmt->execute(array(':id' => $post_id))) {
    return array();
  }
  return $stmt->fetchAll(\PDO::FETCH_ASSOC);
}

/**
 * Удаляет картинки поста.
 * @param $post_id
 */
function delete_post_images($post_id) {
  foreach (get_post_images($post_id) as $row) {
    $images_array = explode(',', $row['post_images']); // В БД у вас похоже тоже ужас.

    foreach ($images_array as $image) {
      $img_path = $_SERVER['DOCUMENT_ROOT'] . $image;
      $pathinfo = pathinfo($img_path);
      $small_img_path = $pathinfo['dirname'] . DIRECTORY_SEPARATOR . $pathinfo['filename'] . '_little' . '.' . $pathinfo['extension'];

      if (file_exists($img_path)) {
        unlink($img_path);
      }
      if (file_exists($small_img_path)) {
        unlink($small_img_path);
      }
    }
  }
}

/**
 * Удаляет пост.
 * @param $post_id
 * @return bool
 */
function delete_post($post_id) {
  $db = get_db_connection();
  $stmt = $db->prepare('DELETE FROM posts WHERE id = :id');
  if (!$result = $stmt->execute(array(':id' => $post_id))) {
    return false;
  }
  delete_post_images($_POST['id']);
  return true;
}

/**
 * Отправляет ответ.
 * @param bool $result
 * @param mixed $data
 */
function send_response($result, $data = '') {
  header('Content-Type: text/html; charset=utf-8');
  print json_encode(array('result' => (bool)$result, 'data' => $data));
  exit();
}

/**
 * Проверяет доступ пользователя.
 * @param $action
 * @param $post_id
 * @return bool
 */
function check_user_access($action, $post_id) {
  switch ($action) {
    case 'post_del':
      if ($_SESSION['user_type'] != '1' && $_SESSION['search_access'] != '1') { // Почему строка '1'??
        return false;
      }

      $author_id = get_post_author_id($post_id);
      return ($author_id != '1' || $_SESSION['user_type'] == '1');

    case 'compl_del':
      return ($_SESSION['user_type'] == '1' || $_SESSION['compl_access'] == '1');

    default:
      return false;
  }
}

if ($_SESSION['user_type'] == '4' || $_SESSION['is_auth_vk'] != '1') {
  send_response(false, 'Доступ запрещен');
}

if (!is_numeric($_POST['id'])) {
  send_response(false, 'Неверные параметры запроса');
}

if (!check_user_access($_POST['action'], $_POST['id'])) {
  send_response(false, 'Недостаточно прав');
}

if (!delete_post($_POST['id'])) {
  send_response(false, 'Неизвестная ошибка');
}

send_response(true);

$('.adm_posts_cont, .rossr_cont').on('click', '.close', function(e) {
  e.preventDefault();

  var $this = $(this);
  var $next = $this.next();
  var action_val = $next.find('.action').val();
  var id = $next.find('.post_id').val();
  var action = 'post_del';

  if (action_val == 'post_upd_complaint') {
    action = 'compl_del';
  }
  else if (action_val == 'rossr_upd') {
    action = 'rossr_del';
    id = $this.next().find('.rossr_id').val();
  }

  $.ajax({
    type: 'POST',
    url: '/includes/ajax_actions.php',
    data: {action: action, id: id},
    dataType: 'json',
    xhrFields: {withCredentials: true} // Вместо передачи PHPSESSID
  })
    .done(function(data) {
      if (!data.hasOwnProperty('result')) {
        alert('Unknown error');
        return;
      }
      if (!data.result) {
        alert('Error: ' + data.data);
        return;
      }

      $this.parent().remove();
    })
    .error(function() {
      alert('Ajax error');
    });
});

Почему вы используете DELETE FROM? На больших таблицах это будет тяжелая операция

withCredentials: true — возьму на заметку.

По поводу вашего кода — он не отражает моего мышления, поэтому мне будет не комфортно. Да и скакать по нескольким функциям мне неудобно, но всё равно спасибо.

DELETE FROM будет не тяжелее вашего UPDATE. К тому же, как указали выше, при использовании AUTOINCREMENT ID не будут использоваться повторно, так что переживать не о чем.
А смысл кода не в разбиении на функции. Сравните внимательнее. Вы можете развернуть его обратно в «лапшу», главное ошибки не допускайте.
Да, его тоже еще можно долго «причесывать», например, строго указывать тип параметров в PDO, «магические числа» записать в константы, лучше проверять входные данные, но общий смысл и основные ошибки я исправил.

Ответ от запроса возвращается в браузер с задержкой ( в фаербаге смотрю ). Думаю дело не в js. Просто очень странный глюк, как может один и тот же запрос ( post_id только разный ) — выполнять всё дольше и дольше…

Тормозит в месте Ожидание — смотрел в фаербаге

там проверка на is_numeric( $_POST['id'] )

Осторожнее с is_numeric() для нее и 0xFA будет true…

Спасибо, не знал… А тот факт, что пропускаются такие строки — чем череват?

Почему вы числа пишете строками?

У меня поле ENUM в базе, поэтому решил пусть будет строкой в сессии хранится, чтобы по образу и подобию

И с подходом «пусть будет строкой, чтобы по образу и подобию» вы удивляетесь тормозам?
Integer будет значительно быстрее.

А если эти значения используются в запросе mysql — тогда integer будет переведено обратно в string? ( поле то ENUM )

Если вы в поле храните число — сделайте поле Integer (TINYINT для флагов).

INTEGER 5 занимает больше памяти, чем строка «5» и работает медленнее. Всё не так просто как кажется. И причина у автора не с типом полей.

TINYINT — 1 байт
Но да, проблема не в этом.

Попробовал, только вместо session_close(); использовал session_write_close()

Эффетка нет…

Тогда нужно локализовать проблему. Если вы уверены что тормозит запрос, то попробуйте выполнить несколько раз этот запрос из консоли mysql…
Дальше в зависимости от результатов. Или искать причину в SQL (например… DB индексы большие, кеш забивают) или всё таки пхп.

Да, один и ото же запрос тормозит, Говорите смотреть в сторону кеширования в mysql? Причем даже когда в phpmyadmin у хостера посредством интерфейса манипулируешь базой данных — одни и те же запросы тормозят после первого раза…

Попробовал — эффетка нет, но меня это натолкнуло на мысль, что так как пользователей много — а хостинг самый простой — то возможно кеш mysql забивается другими запросами? ( в остальных местах везде mysql_query() )

А индексы правильно проставлены? Я как-то раз забыл проставить индексы, сервер начинал дико тормозить. Проблему искал несколько дней, пока не вспомнил про индексы. Как только проставил — сервер начал летать.

            $res = mysql_query("INSERT INTO 
                                b_lists_users_ids 
                                SET user_vk_id = ".$_POST['user_vk_id']."
                                , bl_acc_to_app = '1'
                                , not_srch_posts_vk = '1'
                                , reason = '".mysql_real_escape_string($_POST['reason'])."'
                                , user_vk_id_add = '".$_SESSION['vk_id']."'
                                , date_add = UNIX_TIMESTAMP()
                                , user_vk_id_edit = '".$_SESSION['vk_id']."'
                                , date_edit = UNIX_TIMESTAMP()
                                ON DUPLICATE KEY UPDATE
                                is_active = '1'
                                , bl_acc_to_app = '1'
                                , not_srch_posts_vk = '1'
                                , reason = '".mysql_real_escape_string($_POST['reason'])."'
                                , user_vk_id_edit = '".$_SESSION['vk_id']."'
                                , date_edit = UNIX_TIMESTAMP()
                                ");

Структура таблицы:

CREATE TABLE IF NOT EXISTS `b_lists_users_ids` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_vk_id` bigint(20) unsigned NOT NULL,
  `b_comment` text CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
  `reason` text CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
  `user_vk_id_add` bigint(20) unsigned NOT NULL,
  `date_add` int(10) unsigned NOT NULL,
  `user_vk_id_edit` bigint(20) unsigned NOT NULL,
  `date_edit` int(10) unsigned NOT NULL,
  `is_active` enum('1','0') CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '1',
  `bl_acc_to_app` enum('1','0') CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '1',
  `not_srch_posts_vk` enum('1','0') CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '1',
  PRIMARY KEY (`id`),
  UNIQUE KEY `user_vk_id` (`user_vk_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=cp1251 AUTO_INCREMENT=259 ;

Есть конечно индексы в других таблицах — но они же не могут влиять на запрос к этой таблице… К тому же всегда в первый раз запрос выполняется быстро, а потом всё медленнее и медленнее