I have a weird problem in a preproduction environment.
I have a website which performs some operations on a Web Api hosted on another server.
Usually it takes under a second to make a specific post request, but after 5 minutes of inactivity the same post request will take 10-30 seconds. (According to google chrome network tab)
The mentioned post request is not the first request in a list of requests performed.
The request is done using Ajax.
I have run SQL profiler to see if the database queries were running slow, but these are all performing fine, and it looks like the POST request is just returning with a delay.
Do you guys have any idea why this is happening?
A very likely cause is compiling at the database level. The first time you run a query with most database engines, the sql has to be compiled and an execution plan developed. This is then cached for a while. When it is no longer cached, it has to be done again. The longer your sql string, the longer it takes to compile.
The solution is to use a stored procedure. Once it runs once it stays compiled and the execution plan is always available.
Problem solved!
The problem was that an email was sent using SMTPClient in the request.
In a web application the smtp client is not async and therefore it had to be sent before the POST request returned.
Making it async using the reply from TheCodeKing in this question:
How do I avoid a delay when sending email from my application?
solved the problem!
Related
I am creating a question answering application using Node.js + Express for my back-end. Front-end sends the question data to the back-end, which in turn makes requests to multiple third-party APIs to get the answer data.
Problem is, some of those third-party APIs take too long to respond, since they have to do some intense processing and calculations. For that reason, i have already implemented a caching system that saves answer data for each different question. Nevertheless, that first request each time might take up to 5 minutes.
Since my back-end server waits and does not respond back to the front-end until data arrives (the connections are being kept open), it can only serve 6 requests concurrently (that's what I have found). This is unacceptable in terms of performance.
What would be a workaround to this problem? Is there a way to not "clog" the server, so it can serve more than 6 users?
Is there a design pattern, in which the servers gives an initial response, and then serves the full data?
Perhaps, something that sets the request to "sleep" and opens up space for new connections?
Your server can serve many thousands of simultaneous requests if things are coded properly and it's not CPU intensive, just waiting for network responses. This is something that node.js is particularly good at.
A single browser, however, will only send a few requests at a time (it varies by browser) to the same endpoint (queuing the others until the earlier ones finish). So, my guess is that you're trying to test this from a single browser. That's not going to test what you really want to test because the browser itself is limiting the number of simultaneous requests. node.js is particularly good at having lots of request in flight at the same time. It can easily do thousands.
But, if you really have an operation that takes up to 5 minutes, that probably won't even work for an http request from a browser because the browser will probably time out an inactive connection still waiting for a result.
I can think of a couple possible solutions:
First, you could make the first http request be to just start the process and have it return immediately with an ID. Then, the client can check every 30 seconds of so after that sending the ID in an http request and your server can respond whether it has the result yet or not for that ID. This would be a client-polling solution.
Second, you could establish a webSocket or socket.io connection from client to server. Then, send a message over that socket to start the request. Then, whenever the server finishes its work, it can just send the result directly to the client over the webSocket or socket.io connection. After receiving the response, the client can either keep the webSocket/socket.io connection open for use again in the future or it can close it.
I'm trying to develop chat system in php, sql and ajax. I created function by ajax to get messages from database this function its event when window upload, so if i open 2 windows in browser to test the application, I found the messages bu when i send message it appear in just the window which send from not both of the 2 windows. To solve this problem i used setInterval function every 1 second to show messages.
Do this huge requests damage the server ??
I don't quite know what you meant with "Damage", but nothing can be really damaged by a few extra requests.
If you're wondering whether the webserver can handle the load, it really depends on how many chat sessions are going at the same time. Any decent web server should be able to handle a lot more than two requests per second. If you have thousands of chat sessions open, or you have very CPU intensive code, then you may notice issues.
A bigger issue may be your network latency. If your network takes more than a second for a round-trip communication with the server, then you may end up with multiple requests coming from the same client at the same time.
I'm developing a single-page application, which sends multiple AJAX request to the server.
The system works with polling, because some data-request can take about 10-20minutes to calculate.
client asks server for data
server hands out a job-id
client asks server every few seconds for the result
The polling algorithm lowers the polling frequency over time, stopping at intervals of 10seconds.
But when a client sends different data requests in a short time, he ends up with about 10-20 job-ids and starts polling for all of them.
Is it better to simply do it this way and let the browser handle those requests in parallel or should I schedule every request and serialize them all?
Would it bring performance benefits to serialize them?
If each initial request returns a unique id and each page has a unique user id then you can poll on what information for each request.
In the JSON I would return the results for any completed request, and the current status of those that haven't completed, such as whether it has started being processed, and perhaps a percentage of completion, or how many requests are ahead of that request.
This will simplify the work as you won't be making several polling calls, but just one, getting back a complex result to give feedback to the user the status of each request.
I find it useful to give some information on status for long-running queries otherwise the user may think the request was lost.
Some months ago, I faced performance issues due to multiple ajax calls, but I haven't investigated deeper this topic since then : High latencies loading stores in an ExtJS 4.1 MVC application.
This is a followup question to the one here
Here's briefly what I am trying to do. The File server creates a text file to indicate an end of the process. On a webpage on the Web Server, I loop every x seconds and make an ajax request to find out if the test file exists (ajax request to http://fileserver/files/UserFile.txt)
I've tried the following approaches so far:
Trigger a web method from the client side that creates a HttpContext object to verify if the text file exists. But this is too strenous on the server and I started getting all kinds of exceptions in the Event Viewer.
YQL works great but unfortunately it's too slow. The user waits atleast twice the amount of time.
I am looking for a solution that doesn't involve the server side. Somehow, I'd like to use JQuery to verify the existence of a text file on the fileserver.
Any thoughts?
You should be able to use JSONP and JQuery.ajax() to do cross-domain request work. Play with the jsonp and jsonpCallback attributes. Alternatively, you can use JQuery.getJSON().
Serving a single file from the filesystem is the most simple operation a web server can do. If that is already too much, then all other solutions will be worse. Find out why the server takes so long to serve a simple file and fix that.
Note: I'm assuming that the file is small since you say "test file". If it's a big file, the server will actually send it to the client which will need a lot of resources.
What you can try is to add an ASP page to the web site which runs code on the server that checks whether the file is there and just returns a tiny piece of HTML which you can add to the page with jQuery.load().
I may be miles off base here but... could you not create ONE asynchronous (!) Ajax client request with a HUMONGOUS timeout. Fire it, and wait. You would be invoking some server script that checks every so often, in a loop on the server (using sleep in between), whether the file exists. And not replying to the Ajax request until the file finally shows. The server script then replies and exits.
EDIT: Depending on the server-side scripting framework used, you may even get some OS support. You may be able to sleep on a status change in the directory...
I noticed that jquery ajax request sometimes take about 1-2 seconds before the responce comes is this normal and is there any way to short that time to minimal?
The responce type is json and it's small html code.
Thanks!
Here are the places the slowness could be:
Database <--> Web server latency
Database Query
Database <--> Web server bandwidth
Server side script code
Web server <--> client latency
Web server <--> client bandwidth
In short, yes, a delay is normal after the request is sent and before the response comes. However, you didn't specify exactly what is happening with the request.
Is it just the request that is taking up to much time? Is the delay before it sends the request? I work with jQuery's ajax engine all the time in our app. I haven't really ever seen latency before the request is sent. What do you use to monitor the ajax request? You can check this using firebug. Enable the net panel and watch the timing.
If the only delay is after the response comes then it may be the HTML that is returned. Is there a lot of HTML that is returned? Is there javascript in the HTML? Are you injecting the HTML in the page and the delay is after that?
Depending on how you coded your solution, the speed largely depends on internet connection from you to server. You can try launch it on localhost to see if it takes that long, if it does, then something is wrong with your code. If you could post a simplified code illustrating the problem we can try to figure it out :D