I'm using a simple jQuery AJAX function that runs extremely slow (10-15 seconds) the first time it's called, and then runs normally at <1 - 2 seconds each time it's called after that first time. I cannot figure out why this is happening but need to speed it up as much as possible. Here is the function:
function getNewItemAlt(apiUrl, callType, apiKey, dataType, returnValue, appendToWrapper) {
// ajax call to the api
return $.ajax({
type: callType,
url: apiUrl,
data: apiKey,
dataType: dataType,
success: function(result) {
appendToWrapper.closest('.game_play_area').find('.game_loader').remove();
// this is the thing that we want (probably either
// an image url or an actual value)
var desiredReturn = deepValue(result, returnValue);
var specialClass = '';
console.log(typeof desiredReturn)
if (typeof desiredReturn === 'number') {
specialClass = 'number'
}
// if it's a URL then it's an image and can be setup
// in an imgage tag and added to the dom
if (desiredReturn.toString().substring(0, 4) == "http") {
$(appendToWrapper).children('.game_image').remove();
$(appendToWrapper).prepend('<img class="game_image" src="' + desiredReturn + '" />');
} else {
$(appendToWrapper).children('.game_value_return').remove();
$(appendToWrapper).prepend('<p class="game_value_return ' + specialClass + '">' + desiredReturn + '</p>');
}
// clear the space to play the game
// $(currentGameWrapper).children('.game_intro').remove();
// show the game
// currentGameWrapper.children('.game_play_area').removeClass('hide');
},
error: function(err) {
console.log(err);
}
});
}
An example of an API that I'm making a request to is the Giphy API. I'm not convinced this is a server issue because it happens only on the first call to the api and then the subsequent calls are speedy.
Any ideas why this is happening and what can be done to make this run faster?
Considering the whole issue Javascript (client side) + API (server side) could complicate diagnosing the issue, so my suggestion to get a more specific answer would be to isolate the issue first.
Answering your general question, Reasons why?: It could be a lot of things but the remarkable ones are:
Handshake: the first interaction between your page and the server makes the remote server to authenticate you and validate your session. Later calls wont go through that process.
Server first execution: (less probable if you are using public APIs) if you are using a remote server with Java for example, that you are restarting, the first time you call a service it will load the instances, but for future calls those instances are already created hence they respond faster.
Network: (I don't think so... but...) trace your HTTP request to see how many jumps it has and how much is taking for them to be resolved.
How to Diagnose (isolation): Measure the time each step takes, it could be a simple print of your current time. I would break it the in the following steps:
Preparing the call to the API.
Calling the API.
Getting the data.
Manipulate the received data on the client side.
NOTE: steps 2 and 3 could go together.
How to mitigate this from happening (it doesn't solve the issue, but mitigates it):
Handshake: if the issue is related with authentication/authorization I recommend you to do an empty pre-fetch (without requesting any data) to deal with the handshake. Then you do a data fetch when you need it without that overhead.
Server first execution: you don't have too much to do here unless you own the server also. In this case I recommend also a pre-fetch but calling the entire service to initialize the server objects.
Javascript API: if the problem is dealing with the data on your client side then review how to optimize your Javascript code.
This might be a long shot. "appendToWrapper" is an object passed in by reference. If it's taking a long time to resolve (ie it takes 10 seconds or so to find ".game_play_area" etc... in the DOM) then it would be slow the first time, but saved in the calling function and fast subsequent times.
It might be easy to check. If you could make a deep copy of the object before passing it in, we would expect the AJAX to be slow every time, not just the first time. If that's the case, you'd need to clean up your selectors to make them faster. Perhaps use ids instead of classes.
Related
I'm trying to figure out if there's any chance to receive the status of completion of a task (triggered via an ajax call), via multiple (time intervalled) ajax calls.
Basically, during the execution of something that could take long, I want to populate some variable and return it's value when asked.
Server code looks like this:
function setTask($total,$current){
$this->task['total'] = $total;
$this->task['current'] = $current;
}
function setEmptyTask(){
$this->task = [];
}
function getTaskPercentage(){
return ($this->task['current'] * 100) / $this->task['total'];
}
function actionGetTask(){
if (Yii::$app->request->isAjax) {
\Yii::$app->response->format = \yii\web\Response::FORMAT_JSON;
return [
'percentage' => $this->getTaskPercentage(),
];
}
}
Let's say I'm in a for loop, and I know how many times I iterate over:
function actionExportAll(){
$size = sizeof($array);
$c = 0;
foreach($array as $a){
// do something that takes relatively long
$this->setTask($size,$c++);
}
}
While in the client side i have this:
function exportAll(){
var intervalId = setInterval(function(){
$.ajax({
url: '/get-task',
type: 'post',
success: function(data){
console.log(data);
}
});
},3000);
$.ajax({
url: '/export-all',
type: 'post',
success: function(data){
clearInterval(intervalId); // cancel setInterval
// ..
}
});
}
This looks like it could work, besides the fact that ajax calls done in the setInterval function are completed after "export-all" is done and goes in the success callback.
There's surely something that I'm missing in this logic.
Thanks
The problem is probably in sessions.
Let's take a look what is going on.
The request to /export-all is send by browser.
App on server calls session_start() that opens the session file and locks access to it.
The app begins the expensive operations.
In browser the set interval passes and browser send request to /get-task.
App on server tries to handle the /get-task request and calls session_start(). It is blocked and has to wait for /export-all request to finish.
The expensive operations of /export-all are finished and the response is send to browser.
The session file is unlocked and /get-task request can finally continue past session_start(). Meanwhile browser have recieved /export-all response and executes the success callback for it.
The /get-task request is finished and response is send to browser.
The browser recieves /get-task response and executes its success callback.
The best way to deal with it is avoid running the expensive tasks directly from requests executed by user's browser.
Your export-all action should only plan the task for execution. Then the task itself can be executed by some cron action or some worker in background. And the /get-task can check its progress and trigger the final actions when the task is finished.
You should take look at yiisoft/yii2-queue extension. This extension allows you to create jobs, enqueue them and run the jobs from queue by cron task or by running a daemon that will listen for tasks and execute them as they come.
Without trying to dive into your code, which I don't have time to do, I'll say that the essential process looks like this:
Your first AJAX call is "to schedule the unit of work ... somehow." The result of this call is to indicate success and to hand back some kind of nonce, or token, which uniquely identifies the request. This does not necessarily indicate that processing has begun, only that the request to start it has been accepted.
Your next calls request "progress," and provide the nonce given in step #1 as the means to refer to it. The immediate response is the status at this time.
Presumably, you also have some kind of call to retrieve (and remove) the completed request. The same nonce is once again used to refer to it. The immediate response is that the results are returned to you and the nonce is cancelled.
Obviously, you must have some client-side way to remember the nonce(s). "Sessions" are the most-common way to do that. "Local storage," in a suitably-recent web browser, can also be used.
Also note ... as an important clarification ... that the title to your post does not match what's happening: one AJAX call isn't happening "during" another AJAX call. All of the AJAX calls return immediately. But, all of them refer (by means of nonces) to a long-running unit of work that is being carried out by some other appropriate means.
(By the way, there are many existing "workflow managers" and "batch processing systems" out there, open-source on Github, Sourceforge, and other such places. Be sure that you're not re-inventing what someone else has already perfected! "Actum Ne Agas: Do Not Do A Thing Already Done." Take a few minutes to look around and see if there's something already out there that you can just steal.)
So basically I found the solution for this very problem by myself.
What you need to do is to replace the above server side's code into this:
function setTask($total,$current){
$_SESSION['task']['total'] = $total;
$_SESSION['task']['current'] = $current;
session_write_close();
}
function setEmptyTask(){
$_SESSION['task'] = [];
session_write_close();
}
function getTaskPercentage(){
return ($_SESSION['task']['current'] * 100) / $_SESSION['task']['total'];
}
function actionGetTask(){
if (Yii::$app->request->isAjax) {
\Yii::$app->response->format = \yii\web\Response::FORMAT_JSON;
return [
'percentage' => $this->getTaskPercentage(),
];
}
}
This works, but I'm not completely sure if is a good practice.
From what I can tell, it seems like it frees access to the $_SESSION variable and makes it readable by another session (ence my actionGetTask()) during the execution of the actionExportAll() session.
Maybe somebody could integrate this answer and tell more about it.
Thanks for the answers, I will certainly dig more in those approaches and maybe try to make this same task in a better, more elegant and logic way.
Working on a platform, to enable auto-ticketing functionality. For which a REST API request is used for ticket creation. Unfortunately, there are 2 requests popping simultaneously, which results in creating duplicated tickets.
How to handle such case and send only one of these requests?
Tried adding the 2nd request in the response callback of the first, though this does not seem to work.
if (flag == 1){
logger.debug("Node-down alarm-Request raised - +sitn_id);
clearTimeout(mouseoverTimer);
mouseoverTimer = setTimeout(function(){
logger.debug("Inside Call back function - ");
//function call for ticket creation
incidentRequest(sitn_id,confUtil.config.mule_url);
}, 10);
You really should show more of the code that makes the request, though it seems as if you are doing some ajax inside your 'incidentRequest', so I will presume that (if that isn't what you are doing, then please, show your code....) - and since you tags say javascript and jquery - well, here goes...
To stop the 'double send' in an AJAX call, it is simple:
function incidentRequest(sitn_id,confUtil.config.mule_url){
// stop the double by clearing the cache
$.ajaxSetup({cache: false});
// continue on with the AJAX call
// presuming the url you want is confUtil.config.mule_url
// and the data you want to send is sitn_id
$.post(confUtil.config.mule_url, 'sitn_id=' + sitn_id, function (data) {
// do cool stuff
});
}
Hopefully that will help you get moving. If not, then we will need more code of what is going on around all this.
The question is about speeding up the loading of a ASP.NET web app, and I found that the loading time of the filtering feature of the web app is unacceptable. The filter list is generated from a database. Please see the following code:
This function is in .js and is invoking the webservice method.
function filterSetup() {
filterChanged = true;
var reset = true;
DDL_WebService.fillFilter(SucceededCallbackWithContext, FailedCallback,new ddlContext("My_Filter", reset));
filterSystemSetup();
}
This function is in .js too and is executed after the webservice method.
function SucceededCallbackWithContext(result, userContext) {
var ddl = $get(userContext.cntrl);
var curVal = userContext.getVal();
// Fetching result...
}
This function is one method in a web service file called "DDL_WebService.vb". It is in .vb and is getting the data from a database.
<WebMethod()> _
Public Function fillFilter() As List(Of String)
Dim strSQL As String
strSQL = "select '(All)' from My_Table "
Return getData(strSQL)
End Function
Problem: I thought after the last line of fillFilter(), it should go to SucceededCallbackWithContext()in almost no time (The step-into command tells me nothing happens in between too). However, getting to SucceededCallbackWithContext() from the last line of fillFilter() takes around 7 seconds.
I am not sure what is taking the time and how can I confirm and resolve that.
Any help is greatly appreciated :)
Updates:
Looking at the problem from another angle using Developer tool, I get the result shown in the sceenshot. Now my question becomes what are the possible reasons that some methods take too long to run (Note: For the webservice method with the longest request time, I speed up the query from 10 seconds to less than 3 seconds, but the request time is still arount 15 seconds). Could it be that the executing of one webservice method would affect the speed of another webservice method? Thanks again!
If you are going to filter data why you try to load all records with all columns?
If your my_table records is around 1000 or less than 1000(I mean you have a small data set) you can not understand performance issue but after a while as your data grow(for example it reaches up to 100000) you notice that your service is getting slower and slower.
If you query is not your main query in code so first use browsers developer tools or any other tools to measure response time of your service to be sure that problem is in your server side codes or in your javascript codes
Try to compress your datataTable before sending it !I share with you two functions thaallow the compression and decompression :
Public Shared Function CompressData(ByVal ds As DataSet) As Byte()
Try
Dim data As Byte()
Dim memStream As New MemoryStream()
Dim zipStream As GZipStream = New GZipStream(memStream, CompressionMode.Compress)
ds.WriteXml(zipStream, XmlWriteMode.WriteSchema)
zipStream.Close()
data = memStream.ToArray()
memStream.Close()
Return data
Catch ex As Exception
Return Nothing
End Try
End Function
Public Shared Function DecompressData(ByVal data As Byte()) As DataSet
Try
Dim memStream As New MemoryStream(data)
Dim unzipStream As New GZipStream(memStream, CompressionMode.Decompress)
Dim objDataSet As New DataSet()
objDataSet.ReadXml(unzipStream, XmlReadMode.ReadSchema)
unzipStream.Close()
memStream.Close()
Return objDataSet
Catch ex As Exception
Return Nothing
End Try
End Function
Hope help you.
Although it has been a long time since I posted the question, I still want to update my progress on this problem just to thanks Beldi and mostafa for the suggestions and to give people some hints when having similar issues.
Overall the problem has not been resolve but we came up with a workaround.
We were guessing that some queries might take a long time to finish, so I carved out all the queries that take a long time according to the developer tool. I tested them one by one and found that they are all pretty fast. In the next quite a bit of time, I was stuck on verifying what the developer tool indicates.
One breakthrough happens when I dissect the following code:
$.ajax({
type: "POST",
contentType: "application/json; charset=utf-8",
url: "dataservice/getSimData_WebService.asmx/getSimsList",
data: JSON.stringify(params),
dataType: "json",
success: function (data, textStatus) {
if (textStatus == "success") {
var thegrid = $("#jqGrid_sims")[0];
thegrid.addJSONData(data.d);
}
},
error: function (data, textStatus) {
alert("Error from get grid data");
}
});
In this piece of ajax call, the code sends out the request upon executing. The time between the beginning of the execution and the beginning of the if statement is requesting time, and that is the time the developer tool indicates.The time that code inside if statement spends is the fetching time.
After looking into the requesting time and the fetching time for each ajax call, I found the fetching time for a simulation functionality takes a relatively significant amount of time. Since loading the functionality would cause the page to be frozen and trying to reduce the frozen time has more uncertainties and takes longer, we finally decide to not load it initially. Instead, it will load once a user clicks on a button.
Hope this would help anyone who has similar problems.
I am currently working on a web based time tracking software. I'm developing in grails, but this question is solely related to javascript and asynchronous requests.
The time tracking tool shall enable users to choose a day for the current month, create one or multiple activities for each day and save the entire day. Each activity must be assigned to a project and a contract.
Upon choosing "save", the partial day is saved to the database, the hours are calculated and a table is updated at the bottom of the page, showing an overview of the user's worked hours per month.
Now to my issue: There may be a lot of AJAX request. Patient users might only click the "create activity" button just once and wait until it is created. Others, however, might just keep clicking until something happens.
The main issue here is updating the view, although i also recognized some failed calls because of concurrent database transaction (especially when choosing "save" and "delete" sequentially). Any feedback on that issue -- requests not "waiting" for the same row to be ready again -- will be apreciated as well, yet this is not my question.
I have an updateTemplate(data, day) function, which is invoked onSuccess of respective ajax calls in either of my functions saveRecord(), deleteRecord(), pasteRecords(), makeEditable() (undo save). Here is the example AJAX call in jquery:
$.ajax({
type: "POST",
url: "${g.createLink(controller:"controller", action:"action")}",
data: requestJson,
contentType:"application/json; charset=utf-8",
async: true,
success: function(data, textstatus) {updateTemplate(data["template"], tag); updateTable(data["table"]);},
});
In the controller action, a JSON object is rendered as a response, containing the keys template and table. Each key has a template rendered as a String assigned to it, using g.render.
Now, what happens when I click on create repeatedly in very short intervalls, due to the asynchronous calls, some create (or other) actions are executed concurrently. The issue is that updateTemplate just renders data from the repsonse; the data to render is collected in the create controller action. But the "last" request action only finds the objects created by itself. I think this is because create actions are run concurrently
I figure there is something I'm either overcomplicating or doing something essentially wrong working with a page that refreshs dynamically. The only thing I found that helps are synchronous calls, which works, but the user experience was awful. What options do I have to make this work? Is this really it or am I just looking for the wrong approach? How can I make this all more robust, so that impatient users are not able to break my code?
*********EDIT:********
I know that I could block buttons or keyboard shortcuts, use synchronous calls or similar things to avoid those issues. However, I want to know if it is possible to solve it with multiple AJAX requests being submitted. So the user should be able to keep adding new activities, although they won't appear immediately. There is a spinner for feedback anyway. I just want to somehow make sure that before the "last" AJAX request gets fired, the database is up to date so that the controller action will respond with the up-to-date gsp template with the right objects.
With help of this Stackoverflow answer, I found a way to ensure that the ajax call -- in the javascript function executed lastly -- always responds with an up-to-date model. Basically, I put the javascript functions containing AJAX calls in a waiting queue if a "critical" AJAX request has been initiated before but not completed yet.
For that I define the function doCallAjaxBusyAwareFunction(callable) that checks if the global variable Global.busy is 'true' prior to executing the callable function. If it's true, the function will be executed again until Global.busy is false, to finally execute the function -- collecting the data from the DOM -- and fire the AJAX request.
Definition of the global Variable:
var Global = {
ajaxIsBusy = false//,
//additional Global scope variables
};
Definition of the function doCallAjaxBusyAwareFunction:
function doCallAjaxBusyAwareFunction(callable) {
if(Global.busy == true){
console.log("Global.busy = " + Global.busy + ". Timout set! Try again in 100ms!!");
setTimeout(function(){doCallAjaxBusyAwareFunction(callable);}, 100);
}
else{
console.log("Global.busy = " + Global.busy + ". Call function!!");
callable();
}
}
To flag a function containing ajax as critical, I let it set Global.busy = true at the very start and Global.busy = false on AJAX complete. Example call:
function xyz (){
Global.busy = true;
//collect ajax request parameters from DOM
$.ajax({
//desired ajax settings
complete: function(data, status){ Global.busy = false; }
}
Since Global.busy is set to true at the very beginning, the DOM cannot be manipulated -- e.g. by deletes while the function xyz collects DOM data. But when the function was executed, there is still Global.busy === true until the ajax call completes.
Fire an ajax call from a "busy-aware" function:
doCallAjaxBusyAwareFunction(function(){
//collect DOM data
$.ajax({/*AJAX settings*/});
});
....or fire an ajax call from a "busy-aware" function that is also marked critical itself (basically what I mainly use it for):
doCallAjaxBusyAwareFunction(function(){
Global.busy = true;
//collect DOM data
$.ajax({
//AJAX SETTINGS
complete: function(data, status){ Global.busy = false; }
});
});
Feedback is welcome and other options too, especially if this approach is bad practice. I really hope somebody finds this post and evaluates it, since I don't know if it should be done like that at all. I will leave this question unanswered for now.
Basically just looking to see if a particular txt file exists on the server, and if so, do further processing; however, I don't think my recursion is correct, so can someone offer a few pointers - here's what I have:
function fileExists(filename) {
$.ajax({
type: 'HEAD',
url: 'http://www.example.com/system/'+filename+'.txt',
success: function() {
// Further processing if file exists
},
error: function() {
// File does not exists, run through function again-
return arguments.callee(filename);
}
});
}
It's pretty basic, there's some processing before hand that actually creates the file; however the issue is it's FTP-ed up to our domain, which means timing can vary by a few seconds, so basically I just want it to recheck until it sees that the file exists. I'll modify it a little afterwards to control the stack, possibly setting a timeout of half a second or something, but I'm not that great with javascript, so I need a few pointers to make this recursive. Any help is GREATLY appreciated.
the issue is when you try to call fileExists again via arguments.callee(fileName), the scope of the error method isn't what you think it is.
Just call fileExists.
The other you are going to have is that if your server is quick, you are going to be firing a ton of requests. You probably want to wait some time between requests. So make error contain
setTimeout(function(){
console.log('trying again....'); // this won't work in IE, I *think*
fileExists(filename);
}, 1000); // try again in a second
Finally, you should realize that the error callback only gets invoked if the server returns a 500. The 500 code usually means there was an error on your server. If a file doesn't exist, you should probably return json to indicate the file doesn't exist, and handle that case in your success callback.
error: function() {
fileExists(filename);
}