Запрос MySQL занимает много времени в запросе AJAX

Проблема

Каждый запрос AJAX, содержащий любой запрос БД, занимает намного больше времени, чем обычно.

Я не обновлял кодовую базу с недели, но внезапно все запросы БД, выполненные в запросе AJAX, занимают много времени. Здесь следует заметить, что если запрос написан на странице, а затем обычно загружается страница, как если бы вы посетили: www.example.com/mypage.php,

mypage.php:

<?php

   $query = $db_handler->prepare(
      "SELECT * FROM table_x LIMIT 5"
   );
   $query->execute();
   $fetch = $query->fetchAll(PDO::FETCH_ASSOC);

?>

Страница загружается очень быстро со всем результатом.

Но, если это сделано в файле ответов AJAX, требуется много времени (например, 15 секунд) для загрузки

Код AJAX на стороне клиента:

$.ajax
({
    url: 'server_files/ajaxtest.php',
    type: 'POST',
    dataType: 'JSON',
    data:
    {
        data: 'some data'
    },
    success: function(data)
    {
        if( data.success === true )
        {

        }
        else if( data.success === false )
        {

        }
    },
    error: function(e)
    {
        alert('Error');
    }
});

ajax_response.php:

<?php

   header('Content-Type: application/json');

   if( isset($_POST['data']) )
   {
       $query = $db_handler->prepare(
          "SELECT * FROM table_x LIMIT 5"
       );
       $query->execute();
       $fetch = $query->fetchAll(PDO::FETCH_ASSOC);

       echo json_encode([
           'success'  => true,
           'response' => $fetch
       ]);
    }
?>

^ занимает 15 секунд для загрузки (запрос с 5 наборами строк (LIMIT 5) выполняется в то же время, что и запрос с 10 наборами строк (LIMIT 10).)

если тот же файл содержит только этот

<?php

   header('Content-Type: application/json');

   if( isset($_POST['data']) )
   {    
       echo json_encode([
           'success'  => true
       ]);
   }
?>

^ берет 300-400 мс для загрузки

Очевидно, что запрос увеличит время отклика немного (1-3 сек.), но 15 секунд больше.


Что я сделал

1) Я связался с моим хостинг-провайдером, но это мало помогло.

2) Я также установил mysqltuner, и он показывает это:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.49-0ubuntu0.14.04.1-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[--] Data in MyISAM tables: 27K (Tables: 13)
[--] Data in InnoDB tables: 6M (Tables: 21)
[!!] Total fragmented tables: 21

-------- Security Recommendations  -------------------------------------------
[!!] User '[email protected]' has no password set.
[!!] User '[email protected]::1' has no password set.
[!!] User '[email protected]' has no password set.

-------- Performance Metrics -------------------------------------------------
[--] Up for: 11h 23m 42s (21K q [0.533 qps], 11K conn, TX: 6M, RX: 2M)
[--] Reads / Writes: 92% / 8%
[--] Total buffers: 432.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 837.8M (84% of installed RAM)
[OK] Slow queries: 2% (488/21K)
[OK] Highest usage of available connections: 3% (6/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/156.0K
[OK] Key buffer hit rate: 99.2% (133 cached / 1 reads)
[OK] Query cache efficiency: 61.9% (6K cached / 10K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 113 sorts)
[!!] Temporary tables created on disk: 50% (421 on disk / 842 total)
[OK] Thread cache hit rate: 99% (6 created / 11K connections)
[OK] Table cache hit rate: 33% (75 open / 223 opened)
[OK] Open file limit used: 1% (76/6K)
[OK] Table locks acquired immediately: 100% (4K immediate / 4K locks)
[OK] InnoDB data size / buffer pool: 6.5M/128.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
    tmp_table_size (> 16M)
    max_heap_table_size (> 16M)

3) Искал много и обновил мой файл my.cnf. Это мой файл my.cnf (этот файл выглядел несколько иначе в момент возникновения проблемы)

[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
local-infile=0
log=/var/log/mysql-logfile
skip_name_resolve

user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir     = /usr
datadir = /var/lib/mysql
tmpdir      = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking

slow-query-log = 1 
slow-query-log-file = /var/log/mysql-slow.log 
long_query_time = 2 
log-queries-not-using-indexes 

key_buffer      = 16M
max_allowed_packet = 32M
thread_stack        = 192K
thread_cache_size       = 8

myisam-recover         = BACKUP

query_cache_type=1
query_cache_limit=2M
query_cache_size=256M

tmp_table_size=16M
max_heap_table_size=16M
table_cache=3084

log_error = /var/log/mysql/error.log

expire_logs_days    = 10
max_binlog_size         = 100M
big-tables

[mysqldump]
quick
quote-names
max_allowed_packet  = 16M

[mysql]

[isamchk]
key_buffer      = 16M

!includedir /etc/mysql/conf.d/

4) Оптимизировал все таблицы в БД

5) Я также обновил свой сервер от 1GB memory and 1CPU, 2TB Transfer до 2GB memory and 2CPUS, 3TB Transfer

Я все еще не понимаю, почему это происходит и как это можно решить.

Ответ 1

Проблема была в строке подключения. Я использовал свое доменное имя (example.com) для подключения к базе данных. Поэтому я изменил его на свой IP-адрес и решил проблему.

Спасибо всем за вашу помощь.

Ответ 2

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

Надеюсь, что это поможет.