Recently my Apache server's CPU has been at 100% (all day, that is). I think I have found my issue.
On a page, a user has the ability to click a button and send a POST request to a PHP file on my server. Sometimes the PHP file takes a LONG (and I mean VERY long) time to respond or sometimes does not respond at all:
function buttonFunction() {
$.post("http://ipaddress/core/file.php",{username:username, password:pword, coins:coins}, function(data) {
// Stuff
});
}
Hypothesis 1:
I believe that sometimes people might click this button again (while it is still trying to get the result/response from file.php from the previous click), and therefore causing two simultaneous processes from PHP on the Apache server - causing higher CPU usage (I think that's what happens, correct me if I'm wrong because I'm new to this server stuff).
Hypothesis 2:
Another thing that may be causing the high CPU usage (that I believe) is the user refreshing the page while it is still trying to get the result/response from file.php. After 12 seconds (with no response/result), I have a message appear saying "Please refresh if this takes too long." With that being the case (after refreshing the page), the user once again tries to send a post request to file.php while the old one may still be running - causing higher CPU usage (again, I think that's what happens, correct me if I'm wrong because I'm new to this server stuff).
Reasoning:
I'm saying this because on my site it may say that there are only 12 people online (and probably 12 people sending the post requests), however when I run the top command on PuTTY to see what processes are currently running, it shows nearly 30-40+ processes running (some taking as long as 17 minutes).
So, is there a way that I can abort the request on a refresh (if it's still going on) or on the click on the button (again, if the request is still going on)? In fact, can somebody either confirm or deny if my hypotheses (especially hypothesis 2) are correct - if those actually ARE causing the high CPU? Furthermore, if anybody has an idea for a more efficient way that I can go about this (sending these requests), it would be highly appreciated.
Edit 1:
I can fix the possible issue stated in my first hypothesis. However, can somebody please either confirm or deny if my second hypothesis is true/valid?
Related
To be specific, (although I am also interested in a general solution, if anyone would care to explain) I am trying to "click" Steam's 'Not Interested' button.
I have the urls of the pages I want to do this on in a Python script, alternatively I can write them in a file somewhere.
As much as I (think I) know about that button, it has no ID, and the relevant bit of code that is executed is:
$J.post('http://store.steampowered.com/recommended/ignorerecommendation/', {
sessionid: g_sessionID,
appid: store_appid
})
I am mostly unfamiliar with Javascript, but copying the headers and parameters, I managed to successfully send that post request (in Python instead), which worked. The problem with that is that it seems it requires the following cookies: steamRememberLogin, steamLogin, sessionid. I am rather sure those won't forever stay the same, and so my script would soon break.
I am unsure what to do from here on. I could imagine somehow automatically getting those cookies from somewhere, but where and how? Alternatively if something could actually send a click event from the button, I think that might be possible in Javascript?
And if this bit's important, then it doesn't need to operate in the background. As long as it can be scheduled, it's fine if it needs to actually open up that webpage in my browser.
If I make an AJAX $.post call (with jQuery) to a php file for updating a certain parameter/number, does it considered bad practise, dangerous or similar?
$.post(file.php, {var:var}, function(data){
// something
}, json);
It would be a single user on a single page updating a number by clicking on an object. For example if user A is updating a certain number by clicking on an object user B should see this update immediately without reloading the page.
It depends on 3 main factors:
How many users will you have at any given time?
How much data is being sent per request on average?
Given 1 and 2, is your sever set up to handle that kind of action?
I have a webapp that's set up to handle up to 10-20k users simultaneously, makes a request each time the user changes a value on their page (could be more than 1 req per second), and it sends roughly 1000 bytes on each request. I get an average of 10ms response time, however that's with node js. Originally I started the project in PHP but it turned out to be too slow for my needs.
I don't think web-sockets is the right tool for what you're doing, since you don't need the server to send to the client, and a constant connection can be much more expensive than sending a request every few seconds.
Just be sure to do lots of testing and then you can make judgements on whether it'll work out or not for your specific needs.
tl;dr - It's not a good idea if your server can't handle it. Otherwise, there's nothing wrong with it.
Another solution could be, to cache user actions in local storage/variables, and send them all at once every 10-15 seconds or so, then clear the cache, when sending was successful.
In this case you should also validate the data in local storage to prevent tampering.
I'm trying to make auto-reload counter (for ex.: Messages [num]).
So, I just in setTimeout(); getting JSON code from test_ajax.php. I think it's not correctly..
Can I send info by server (I think not, but suddenly I something don't know..)?
Why I think that's not correctly: because when I'm looking in my chrome network log (F12 -> network tab), I see a lot of requests (to test_ajax.php), but when, I'm visiting vk.com (great example for ajax) or facebook.com, I don't see any requests while something will not change.
So, what's incorrectly in my solution (or what's bad..)?
UPD: Sorry, vk.com sending requests to q%NUM%.queue.vk.com every 25s, but until 25s last request's status is "Pending". When someone, for example, sending me a message it immediately display it. And request has parameter "wait" which equals 25. This delay in requests doing on server side.. But how?
Ajax counter can be done in easy just include below files
index.html
counter.php (ajax file)
necessary images
JS file (for jquery paging call)
download link: https://docs.google.com/open?id=0B5dn0M5-kgfDcE0tOVBPMkg2bHc
What you are looking for is called COMET (also sometimes called Reverse AJAX) techniques.
Doing what you want to do, e.g. regular polls, is one way of doing it.
A lot is actually happening on the server side; to avoid recreating new connections on every poll, some servlet containers like Jetty started to implement techniques like Continuation which basically maintain a two-way connection open.
In the Java world, with Servlet 3, you have asynchronous calls as part of the specs.
When using geolocation API's navigator.geolocation.getCurrentPosition() how to deal with a negative response?
It says that the second callback function is called when there is an error. However when user chooses not to reveal his location by cancelling the request that function is never fired.
It seems that getCurrentPosition() waits for an answer indefinitely. (at least in Firefox 4)
How can I know when user presses cancel (or no etc.)
Any ideas?
See edit below
You are correct, the error handler should fire when a user denies the location request. The error object passed into the error handler should contain an error code and message letting you know the user denied the request. However, I'm not seeing this in FF4 when selecting the option Not Now from the location request dialogue.
In Chrome, the API/callbacks work exactly as expected, but in Chrome there is no 3rd option.
EDIT
Ahhh okay I found a little quirk in the behavior of this in FF4. In normal mode (not private browsing), the user will be presented 3 options:
Always share
Never share
Not Now
Never share triggers the error handler correctly, but Not Now does not.
What does this mean and how to handle it?
Well, it looks like if the user hits Not Now, you aren't going to get a response. Therefore, I would set a timeout which checks a flag that would be set by one of the handlers. If this flag is not set (meaning the handlers didn't fire in the allotted time), you can do one of two things:
Assume that the user denied the request (even though the denial was temporary)
You can ask the user for permission again (via the same call) and the user will be presented with the dialog again.
Option 2 is probably bad usability (and annoying), so it is probably best to assume they denied temporarily and ask them again (politely!) the next time they visit the site.
I created a JsFiddle to play around with this API:
http://jsfiddle.net/7yYpn/11/
I don't think it's a bug, but an intentional choice when it comes to making it difficult to make websites that provides undesirable functionalities.. (as the top answer implied; IF you request again- when someone already said no- is rather annoying...)...
The difference between "not now".. and "never".. is that the programmer of the website KNOWS.. that if "not now" was triggered.. there would be an actual prompt to the user IF he sent the request again.. hence he would be able to "force" the user's hand to EITHER accept it.. or simply block data until the user agrees..
Decent and respectful programmers want to use such information to better provide a service (and to not wait for things that won't happen).. but truth is that there are enough spammers out there to overwhelm the end user..
(and there is no need to even TRY to send the request again, if it has been answered with "never".. because.. the user will not be terrorized in the same manner.. and if the site becomes sluggish and unresponsive, the user will just close it)
Ps. OH, and SERIOUS programmers might actually take a rejection as an actual.. rejection.. and store this choice somewhere.. despite the fact that "not now" is actually not intended as an ABSOLUTE rejection, but rather a "I have decided to not take any definite stand as of yet".. so.. someone who say "not now".. if the server knows of this choice and takes it as a "no".. then there might NEVER be another request sent.. despite the person WANTING to be able to reconsider at a later date)
What would be the best way to display an animation while waiting for server-side processing of a jsp page to complete.Basically, the server side request can take more than a minute to process and until then I would like the user to have some way to get an update of how his request is getting along.I require an animated gif and a line stating that x% has been completed.
One of the methods I came across while surfing the net was to have an intermediate page that shows the animation while loading the actual page using javascript (location.href).So ,I figure use a couple of ajax calls from the intermediate page to a servlet to get the feedback.Problem is it works fine in IE 6/7 and Firefox 3.But the ajax callbacks dont seem to be getting executed in case of Chrome and Opera (The location.href part seems to mess it up and the callbacks never get executed).
If this approach is flawed how should I go about it?.And if not how can i fix this issue?
Thanks in advance
The simple way I've done this is to go to a JSP that displays a "X % completed" page (image, whatever) that reloads periodically. And when the request is complete, it redirects to an appropriate page to indicate completion. A lot simpler than AJAX, if not as fancy, and requires nothing that is browser-specific.
Try window.location='URL'. Also document.location='URL' works, but I think is deprecated.
Also to be opinionated I do think that a non-reloading web page is much saucier than just being forwarded.