I have several users accessing my page at the same time, with each client polling (using
setInverval) another php script that reads a value from a database and prints it.
setInterval( "printData();", 300 );
I'm relatively new to jQuery and javascript, and I'm a bit skeptical of the viability of constantly running this php script and constantly making database queries.
Can someone calm my nerves or provide an alternative to my current method?
You are updating it every 0.3 seconds - that's over 3 times a second. Way too much. Depending on how smooth it needs to be, update it at most every 5 seconds (5000) instead.
Also, just to make it a little faster, just drop the quotes and parentheses:
setInterval(printData,5000);
Related
I would like to know how to achieve some php server background functionality to process some evaluations every second (independent on users viewing page).
My current solution is done with cron job that runs every second. I would like to know if there is any other options or possibilities.
Thanks in advance
Instead of using cron, I recommend you to write a daemon, you can do this in PHP, python, node.js or the language that you prefer. Once you have your script written, you can convert it in a daemon using upstar
1) Write your program with a while loop and sleep.
while (1)
{
if (x == y) {
echo "yay!"
}
sleep(1);
}
2) Write the program with a wrapper, so it never crashes.
while test 1
do
php /usr/local/bin/continual_process.php
done
The problem with this approach is that it CONSTANTLY uses CPU cycles for it. If you write your program as a node.js application, the event-driven architecture and setTimeout feature can help scale your application (and get you thinking about a different mindset for solving issues).
Additionally, you have to consider how long it takes to process the loop. If you call the program every second, but it takes 2 seconds to loop, you are eating up your processes! The sleep method may not worth either. If the loop takes 2 seconds, and you sleep 1, you are running the process every 3 seconds.
Finally, if your process is quick and light (under 1 second loop), considering using setInterval.
I made a logger that shows me all the db queries onscreen. Average is about 30 queries a page. Is that a lot? Each call takes about 0.001 seconds to complete, some longer, some shorter. Here are some totals for a few pages: 0.9 secs, 0.09 secs, 0.8 secs. (Note: these are ONLY the times for the database queries and not image loading etc).
Are these acceptable tiems? What is ideal? What is the industry standard?
If you'd ask me, I would say a page will have to be able to load within 0.5 seconds. Almost 1 second for Queries is way to long.
But, if it is a huge page, which loads of information, a user will probably want to wait for it.
You should probably take a look at the queries, and find out why it takes so long (0.9/0.8)
Add this to your query: EXPLAIN EXTENDED and see if any indexes are used.
That depends on the query, and the level of interactivity of your application. If you have to provide a web application, you are not going to accept a query that completes in 10 seconds. If you can't avoid it, you may have to use some tricks to make it faster, or to build and return the data progressively as new results are found.
depends on the type of the query and ORM you use
I am trying to make a semi-realtime notification system sort of like on Facebook and for that I am looking forward to using long polling instead of mindless polling (polling every N seconds).
Yes, I am not using Apache, I am on Nginx which can handle this type of polling.
Now a question arose, all the tutorials I read about this subject matter of long polling show examples where the ajax request timeout in 30-50 seconds if no data is returned and then poll again, that made no sense to me because previously I used to poll the server every 30 seconds to check for notifications, how does the long polling make the situation any better? it will still be reconnecting every 30 - 50 seconds.
For that reason I considered that it might be an option to change max_execution_time from the default 60 to 300 or 400, then poll with a request that waits for at least 5 mins before timing out and reconnecting.
Can I expect any bad side effects of doing so? Is this approach flawed? Or is there a better approach?
Thank you.
The better approach would be using a backend optimized for tasks like that, e.g. node.js.
However, if you want to use PHP, there's no reason against raising the max execution time.
I have a basic HTML file, using jQuery's ajax, that is connecting to my polling.php script every 2 seconds.
The polling.php simply connections to mysql, checks for ID's newer than my hidden, stored current ID, and then echo's if there is anything new. Since the javascript is connecting every 2 seconds, I am getting thousands of connections in TIME_WAIT, just for my client. This is because my script is re-connecting to MySQL over and over again. I have tried mysql_pconnect but it didn't help any.
Is there any way I can get PHP to open 1 connection, and continue to query using it? Instead of reconnecting every single time and making all these TIME_WAIT connections. Unsure what to do here to make this work properly.
I actually ended up doing basic Long Polling. I made a simple PHP script to to an infinite while loop, and it queries every 2 seconds. If it finds something new, it echoes it out, and breaks the loop. My jquery simply ajax connects to it, and waits for a reponse; on reponse, it updates my page, and restarts the polling. Very simple!
PS, the Long Polling method also reduces browser memory issues, as well as drastically reduces the TIME_WAIT connections on the server.
There's no trivial way of doing this, as pconnect doesn't work across multiple web page calls. However, some approaches to minimise the database throughput would be:
Lower the polling time. (2 seconds is perhaps a bit excessive?)
Have a "master" PHP script that runs every 'n' seconds, extracts the data from the database and saves it in the appropriate format (serialised PHP array, XML, HTML data, etc.) in the filesystem. (I'd recommend writing to a temp file and then renaming over the existing one to minimise any partial file collection issues.) The Ajax requested PHP page would then simply use the information in this data file.
In terms of executing the master PHP script, you could either use cron or simply let the user who first requests the page when the contents of file is deemed too stale. (You could use the data file's timestamp for this purpose via the filemtime function.) I'd personally use the latter approach, as cron is overkill for this purpose.
You could take this even further and use memcached instead of a flat file, etc. if so required. (That said, it would perhaps be an over-complex solution at this stage of affairs.)
There is some way to execute a php script every 40 milliseconds?
I don't know if cronjob is the right way, because 25 times per second require a lot of CPU.
Well, If php isn't the correct language, what language I should use?
I am making a online game, but I need something to process what is happening in the game, to move the characters, to calculate projectiles paths, etc.
If you try to invoke a PHP script every 40 milliseconds, that will involve:
Create a process
Load PHP
Load and compile the script
Run the compiled script
Remove the process and all of the memory
You're much better off putting your work into the body of a loop, and then using time_sleep_until at the end of the loop to finish out the rest of your 40 milliseconds. Then your run your PHP program once.
Keep in mind, this needs to be a standalone PHP program; running it out of a web page will cause the web server to timeout on that page, and then end your script prematurely.
Every 40 milliseconds would be impressive. It's not really suited for cron, which runs on 1-minute boundaries.
Perhaps if you explained why you need that level of performance, we could make some better suggestions.
Another thing you have to understand is that it takes time to create processes under UNIX - this may be better suited to a long running task started once and just doing the desired activity every 40ms.
Update: For an online game with that sort of performance, I think you seriously need to consider having a fat client running on the desktop.
By that I mean a language compiled to machine language (not interpreted) and where the bulk of the code runs on the client, using the network only for transmitting information that needs to be shared.
I don't doubt that the interpreted languages are suitable for less performance intensive games but I don't think, from personal experience, you'll be able to get away with them for this purpose.
PHP is a slow, interpreted language. For it to open a file takes almost that amount of time. Rxecuting a PHP script every 40 milliseconds would lead to a huge queue, and a crash very quickly. This definitely sounds like a task you don't want to use PHP for, but a daemon or other fast, compiled binary. What are you looking to do?
As far as I know a cronjob can only be executed every minute. That's the smallest amount of time possible. I'm left wondering why you need such a small amount of time of execution?
If you really want it to be PHP, I guess you should keep the process running through a shell, as some kind of deamon, instead of opening/closing it all the time.
I do not know how to do it but I guess you can at least get some inspiration from this post:
http://kevin.vanzonneveld.net/techblog/article/create_daemons_in_php/
As everyone else is saying, starting a new process every 40ms doesn't sound like a good idea. It would be interesting to know what you're trying to do. What do you want to do if one execution for some reason takes more than 40ms? If you're now careful you might get lots of processes running simultaneous stepping on each other toes.
What language will depend a lot on what you're trying to do, but you should chose a language with thread support so you don't have to fork a new process all the time. Java, Python might be suited.
I'm not so sure every 40 MS is realistic if the back end job has to deal with things like database queries. You'd probably do better working out a way to be adaptive to system conditions and trying hard to run N times per second, rather than every 40 MS like clockwork. Again, this depends on the complexity of what you need to accomplish behind the curtain.
PHP is probably not the best language to write this with. This is for several reasons:
Depending on the version of PHP, garbage collection may be broken. If you daemonize, you run a risk of leaking memory N times a second.
Other reasons detailed in this answer.
Try using C or Python and keep track of how long each iteration takes. This lets you make a 'best effort' to run N times a second, or every 40 MS, whichever is greater. This avoids your process perpetually running since every time it finishes, its already late to get started again.
Again, I'm not sure how long these tasks should take on a 'worst case' scenario system load .. so my answer may or may not apply in full. Regardless, I advise you to not write a stand alone daemon in PHP.
PHP is the wrong language for this job. If you want to do something updating that fast in a browser, you need to use Javascript. PHP is only for the backend, which means everything PHP does has to be send from your server to the browser and then rendered.