Я работаю над веб-приложением на основе PHP (которое я не создавал).
Я запускаю этот запрос ajax:
$.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.info('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.info('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, но я все равно добавил его, чтобы убедиться, что это так. Если он асинхронный, он должен выполнять свою работу без зависания моего веб-приложения, я прав? В чем может быть проблема? Это проблема на стороне сервера? Как мне отладить эту ситуацию?
Обновлено: говоря «застрял», я имею в виду - когда я жду ответа после отправки вызова ajax, обновления страницы или параллельного открытия других страниц (только в моем веб-приложении) отображается белый экран загрузки. Всякий раз, когда вызов ajax возвращает данные - белая страница загружается на запрошенную страницу.
Данные возвращаются из файла PHP:
<?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);
}
Попробуй все закомментировать внутри beforeSend, это что-то меняет? Возможно, qwChart. showLoading вызывает блокировку?
@RoryMcCrossan Я отредактировал свой пост, если он все еще неясен, пожалуйста, обновите мой, и я постараюсь объяснить лучше.
Такое поведение похоже на то, что ваш сервер ограничивает количество подключений и / или запросов, поступающих с вашего IP-адреса. Вы работаете на удаленном сервере или на локальном?
@RoryMcCrossan, это происходит как в моей локальной среде разработки, так и в производственной среде.
@mulquin Я пробовал это, и это не решило проблему ...
@CBroe Да, я использую сеансы (зарегистрированные пользователи имеют сеансы, сохраненные для проверки и т. д.)
удалить перед отправкой и успехом и проверить, где он все еще блокирует ваше приложение. потому что иногда из-за тяжелых операций пользовательского интерфейса приложение перестает отвечать.
@sirajpathan нет. не сработало.
Думаю, проблема может быть в коде, который выполняет загрузку страниц и т. д.
Или же это происходит во всех браузерах?
Вы пытались как можно скорее закрыть сеанс в своем сценарии, который обрабатывает этот запрос AJAX?
@CBroe РЕШЕНА! Я добавил session_write_close(); сразу после require_once("/www/common/api/db.php");, и все работает параллельно с вызовом ajax. Я действительно не понимаю, почему это происходит и как session_write_close решил это. Чтобы запросить файл url: "/potato/ajax.php?module=test_module", через ajax, мне НЕОБХОДИМ сеанс (без него: веб-приложение не может подтвердить меня как зарегистрированного пользователя). Значит, я просто прерываю сеанс? Итак, как теперь параллельно работают другие вещи, которые зависят от него? Как именно он заблокирован? При запуске чего-то в ajax - он блокирует сеанс? по какой причине?
@CBroe Можете ли вы написать мне ответ, в котором подробно объясняется, что происходит за сеансом? Как именно сеанс работает в моем случае?
Добавлен ответ с расширенным объяснением для вас ;-)



![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)


Сеансы PHP являются основным кандидатом для «зависания» других запросов, потому что файл сеанса блокируется для записи, поэтому, пока один запущенный экземпляр скрипта открывает сеанс, всем остальным приходится ждать.
Решение - как можно скорее вызвать в session_write_close.
Немного расширенное объяснение:
Механизм хранения данных сеанса по умолчанию - это просто файловая система. Для каждого активного сеанса PHP просто помещает файл в настроенный каталог сеанса и записывает в него содержимое $ _SESSION, чтобы его можно было прочитать оттуда при следующем запросе, который должен получить к нему доступ.
Теперь, если несколько экземпляров сценария PHP попытаются записать измененные данные сеанса в этот файл «одновременно», это, очевидно, будет иметь большой потенциал конфликта / ошибки.
Поэтому PHP устанавливает блокировку записи в файл сеанса, как только один экземпляр сценария получает доступ к сеансу - все остальные, другие запросы (к тому же сценарию или другому, также использующему сеанс), должны будут ждать, пока первый сценарий завершается с сеансом, и блокировка записи снова снимается.
По умолчанию это происходит, когда скрипт завершен. Но если у вас есть более длительные скрипты, это может легко привести к таким «блокирующим» эффектам, как вы здесь. Решение состоит в том, чтобы явно сказать PHP (через session_write_close): «Я закончил с сеансом здесь, с этого момента я не буду записывать в него какие-либо новые / измененные данные - поэтому не стесняйтесь снимать блокировку, чтобы следующий сценарий может начать чтение данных сеанса ».
Важно то, что вы делаете это только после того, как ваш скрипт завершит манипулирование любыми данными сеанса. Вы все еще можете читать из $ _SESSION во время остальной части скрипта, но вы больше не можете писать в него. (Так что что-нибудь вроде $_SESSION['foo'] = 'bar'; должно выйти из строя после того, как вы освободите сеанс.)
Если единственная цель сеанса на этом этапе (в этом конкретном сценарии) - это проверка аутентификации пользователя, то вы можете закрыть сеанс сразу после этого. Остальная часть скрипта может работать столько, сколько захочет, без блокирования доступа других скриптов к тому же сеансу.
Это не ограничивается запросами AJAX - это лишь одно из тех мест, где вы обычно замечаете подобные вещи в первую очередь, потому что в противном случае у вас обычно не так много запросов, использующих сеанс, выполняющийся «параллельно». Но если бы вы были к f.e. открыв долго работающий скрипт несколько раз на нескольких вкладках браузера, вы заметите там тот же эффект - на первой вкладке скрипт будет работать и выполнять свои функции, тогда как на следующих вкладках вы должны заметить, что эти запросы «зависают» как хорошо, пока предыдущий экземпляр сценария удерживает блокировку записи в сеансе.
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. - значит, если я запустил скрипт, а другой пользователь (другой сеанс) попытается связаться с этим файлом, ему придется дождаться завершения моего скрипта?
@RickSanchez, нет, это ограничено одним и тем же сеансом. Другой пользователь имеет другой идентификатор сеанса и, следовательно, другой файл, в котором хранится его информация о сеансе. Каждая сессия имеет свой собственный файл данных.
Можете дать еще инфу, что "прижилось". Что именно происходит? Или не происходит, если кажется, что он застрял. Заблокирован ли весь браузер на время запроса? Сколько данных возвращается из запроса?