jQuery ajax async'true'让我的web-app卡住，直到返回数据 [英] jQuery ajax async 'true' gets my web-app stuck until the data is returned

问题描述

我正在开发基于PHP的Web应用程序（我没有构建）。

I am working on a PHP based web app (that i didn't build).

我正在运行这个ajax请求：

I am running this ajax request:

$.ajax({
    type: 'POST',
    url: "/potato/ajax.php?module=test_module",
    dataType: 'json',
    async: true,
    data: {
            start_ts: that.start_date,
            stop_ts: that.end_date, 
            submitted: true
    },
    beforeSend: function() {
        console.log('Start: ' + new Date().toLocaleString());
        // Show Chart Loading 
        that.qwChart.showLoading({ 
            color: '#00b0f0', 
            // text: that.returnNumWithPrecent(that.progress)
            text: that.qwChartProgress
        });

        // If data div isn't displayed
        if (!that.dataDisplayed) {
            // Show divs loading
            that.showMainDiv();
        } else {
            that.$qwTbody.slideUp('fast');
            that.$qwTbody.html('');
        }
    },
    complete: function(){},
    success: function(result){
        console.log('End: ' + new Date().toLocaleString());

        // Clear timer
        clearInterval(timer);

        // Set progressbar to 100%
        that.setProgressBarTo100();

        // Show Download Button
        that.downloadBtn.style.display = 'inline-block';

        // Insert Chart Data
        that.insertChartData(result);

        // Insert Table Data
        that.insertTableData(result);
    }
});

由于某种原因，它会让我的整个网络应用程序停滞不前，直到它返回数据。我知道默认情况下ajax请求被设置为'true'但我还是添加了它确保它是。
如果它是异步的，它应该可以完成这项工作而不会让我的网络应用程序卡住，我是对的吗？可能是什么问题？这是服务器端问题吗？我该如何调试这种情况？

And for some reason it gets my whole web-app stuck until it returns the data. I know that by default ajax requests are set to 'true' but i added it anyway just to make sure it is. If it is async, it should do the job without getting my web-app stuck, am I right? What can be the problem? Is this a serverside problem? How do I debug this situation?

编辑：通过说卡住我的意思是 - 当我在提交ajax调用后等待响应，刷新页面或打开其他页面（在我的网页内）仅限应用程序）显示白色加载屏幕。每当ajax调用返回数据时 - 白页加载到请求的页面。

By saying "stuck" I mean - when I wait for the response after submitting the ajax call, refreshing the page or opening in parallel other pages (within my web app only) display a white loading screen. Whenever the ajax call returns the data - the white page loads to the requested page.

从PHP文件返回数据：

Data is returned from the PHP file:

<?php 
require_once("/www/common/api/db.php");

    if (!empty($_POST['submitted'])) {

    // error_reporting(-1);
    // Users Array:
    $users      = get_qw_data($start_ts_to_date, $stop_ts_to_date);

    // Summary Array:
    $summary    = get_qw_summary($users);

    // QW Score Array:
    $qws        = get_qw_score($users);

    // Generate CSV Report files
    /* Remove old:*/ 
    if (!is_file_dir_exist($customer))
        create_qw_directory($customer);

    /* Report #1: */ users_apps_google_macros_ma($users['users'], $customer);
    /* Report #2: */ usage_and_qw_summary($summary, $customer);
    /* Report #3: */ qw_score($qws, $customer);
    /* Zip Files: */ zip_qw_files($customer);

    echo json_encode($qws);
}

推荐答案

PHP会话是主要候选人对于其他请求卡住，因为会话文件被写入锁定，因此只要一个正在运行的脚本实例打开会话，所有其他请求都必须等待。

PHP sessions are a prime candidate for other requests getting "stuck", because the session file gets write-locked, so as long as one running script instance has the session open, all others have to wait.

解决方法是尽快调用 session_write_close 。

一点扩展说明：

会话数据的默认存储机制就是文件系统。对于每个活动会话，PHP只是将一个文件放入配置的会话目录中，并将$ _SESSION的内容写入其中，以便在下一个需要访问它的请求时从那里读回它。

The default storage mechanism for session data is simply the file system. For every active session, PHP simply puts a file into the configured session directory, and writes the contents of $_SESSION to it, so that it can be read back from there on the next request that needs to access it.

现在，如果有几个PHP脚本实例试图同时将更改的会话数据写入该文件，那么这显然会产生很大的冲突/错误。

Now if several PHP script instances tried to write changed session data to that file "simultaneously", that would quite obviously have great conflict/error potential.

因此，只要一个脚本实例访问会话，PHP就会对会话文件进行写锁定 - 其他所有人，其他请求（对同一个脚本，或使用会话的另一个脚本）都必须等待，直到第一个脚本完成会话，然后再次释放写锁。

Therefor PHP puts a write lock on the session file, as soon as one script instance accesses the session - everybody else, other requests (to the same script, or a different one also using the session), will have to wait, until the first script is done with the session, and the write lock gets released again.

默认情况下，脚本运行完毕后会发生这种情况。但是如果你有更长的运行脚本，这很容易导致你遇到这种阻塞效果。解决方法是明确地告诉PHP（通过 session_write_close ），我在这里完成了会话，不会从这一点写入任何新的/更改的数据on - 所以随意释放锁，以便下一个脚本可以开始读取会话数据。

Per default, that happens when the script is done running. But if you have longer running scripts, this can easily lead to such "blocking" effects as you are experiencing here. The solution to that is to explicitly tell PHP (via session_write_close), "I’m done with the session here, not gonna write any new/changed data to it from this point on - so feel free to release the lock, so that the next script can start reading the session data."

重要的是你只能在脚本之后执行此操作完成操纵任何会话数据。在脚本的其余部分中，你仍然可以从$ _SESSION 读取 - 但你不能再写它了。 （因此，在您发布会话后， $ _ SESSION ['foo'] ='bar'; 之类的东西必须失败。）

The important thing is that you only do this after your script is done manipulating any session data. You can still read from $_SESSION during the rest of the script - but you can not write to it any more. (So anything like $_SESSION['foo'] = 'bar'; would have to fail, after you released the session.)

如果此时会话服务的唯一目的（在此特定脚本中）是检查用户身份验证，那么您可以在此之后直接关闭会话。然后，脚本的其余部分可以根据需要运行，而不会阻止其他脚本再次访问相同的会话。

If the only purpose the session serves at this point (in this specific script) is to check user authentication, then you can close the session directly after that. The rest of the script can then run as long as it wants to, without blocking other scripts from accessing the same session any more.

这不仅限于AJAX请求 - 这些只是您通常首先注意到这类内容的地方之一，因为否则您通常不会使用在并行中运行的会话来获得那么多请求。但是，如果你是f.e.在多个浏览器选项卡中多次打开一个长时间运行的脚本，您会注意到相同的效果 - 在第一个选项卡中脚本将运行并开展业务，而在以下选项卡中您应该注意到这些请求挂起为好吧，只要前一个脚本实例在会话中保持写锁定。

This isn’t limited to AJAX requests - those are just one of the places where you usually notice stuff like this first, because otherwise you usually don’t have that many requests using the session running in "parallel". But if you were to f.e. open a long-running script multiple times in several browser tabs, you would notice the same effect there - in the first tab the script will run and do its business, whereas in the following tabs you should notice that those requests are "hanging" as well, as long as the previous script instance holds the write lock on the session.

这篇关于jQuery ajax async'true'让我的web-app卡住，直到返回数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！