I have php web applications, mostly on reporting section if a report is taking long for one user, it stops whole server, means all other clients or users wait for his request to finish after that their page loads completly.
What are possible ways to remove this in web (server client) applications?
how can we do specifically in wamp/PHP. something like restrict user to use server so that it do not affect other users...
MORE SPECIFIC DETAILS:
I have data entry appliactoin about 2000-4000 records being entered per 4 hours by multiple users.
as admin each record then (about after min 10 mins) I need to check in another application through web service and get more information and updating that record fields.
I noticed if i am running this re-checking in loop. All other users complain they can not use application.
Related
I am currently creating a stock market simulation and am working on the moment that the user logs into the simulation. I have a PHP script that will generate a certain price for a company four times and update it into my MySQL database while running. I currently have the following code:
PHP:
if (isset($_SESSION['userId']))
{
$isPlaying = 0;
while ($isPlaying <= 3)
{
$priceTemp = (rand(3300, 3700) / 100);
$sql = "UPDATE pricestemp SET price = $priceTemp WHERE companyName = 'Bawden';";
mysqli_query($conn, $sql);
sleep(1);
$isPlaying++;
}
echo '<h1>Welcome to the simulation</h1>';
}
I am aiming for these updates to happen in the background once the user has logged into the simulation. When refreshing my database every second, the updated prices are shown which is one of my objectives. However, what I would like it to do is still load the HTML onto the page (to say "Welcome to the simulation") while updating the database with every second with an updated price.
So far, when I log in, I have to wait 4 seconds before the HTML will load. In the future, I hope to have it consisently updating until a certain condition is met but when I have set an infinite loop earlier the HTML never loaded.
What do I have to do to allow the HTML to load once logged in and have the prices being generated and updated in the MySQL database in the background with no delay in either of these tasks happening?
You have a fundamental misunderstanding of how web-based requests work.
What you need to understand is that PHP is a server-side language. PHP generates any combination of HTML, CSS, JavaScript, JSON, or any other forms of data you want and sends it to your web browser when it's finished. While it's doing that, it can also manage data within a database or perform any other number of actions, but it will never send what the web browser can make use of until it finishes setting everything up. So if you're within an infinite loop, it will never finish and therefore nothing will be sent back to the web browser.
To remedy this, you need to use something called "asynchronous JavaScript", more commonly referred to as "ajax". Specifically, you first send some initial HTML to the web browser in one request and let the request end immediately. This allows the user to see something without waiting around for an indefinite period of time. Then, on the web browser end, you can use JavaScript to automatically send a second request to the server. During this second request to the server, you can perform your data processing and send back some data when you're finished to display to the user.
If you want to periodically update what you show the user, then you would repeat that second request to refresh what is shown on the user's webpage.
Any time you see some kind of "real-time" updating on a website, it's not coming from a single, persistently open connection to the web server--it's actually a series of repeated, broken up requests that periodically refresh what you see.
Broken down, standard web request workflows look something like this:
Web browser asks the web server for the webpage. Web browser waits for a reply.
Web server generates the webpage and sends the webpage to the web browser. Web server is done.
Web browser receives the webpage and shows it to the user. Web browser stops waiting for a reply.
Web browser runs any JavaScript it needs to run and requests data from the web server. Web browsers waits for a reply.
Web server processes the request and sends the requested data back to the web browser. Web server is done.
Web browser receives the requested data and updates the HTML on the webpage so the user can see it. Web browser stops waiting for a reply.
As you can see, each series of requests is 1) initiated by the web browser, 2) processed by the web server, and 3) any replies from the web server are then handled by the web browser after the web server is finished up. So each and every request goes browser -> server -> browser. If we add steps 7., 8., and 9. to the above, we will see them repeat the exact same pattern.
If you want to avoid adding JavaScript into the mix, preferring to refresh the entire page every time, then keep your data processing short. Optimize your database calls, fix your infrastructure (make sure your server and database have a LAN connection, that your hardware is good enough, etc.), make your code more efficient... do whatever you need to do to keep the processing time to a minimum.
This is all incredibly simplified and not 100% accurate, but should hopefully help you with your specific problem. The short version of all of this is: you can't show your HTML and process your data at the same time the way you're doing things now. You need to fundamentally change your workflow.
You have to do this in 2 network calls. The first network call should fetch the html. Then you have to use Javascript to fire another call to update your data. Once that api call returns it will update the html.
The scheduling model to manage the frequency of a background operation based on the frequency of requests at the front end is a very difficult problem. It's also a problem you don't need to solve. The data doesn't need to be changed when nobody is looking at it. You just need to store when the data was last looked at and apply greater deltas to older data.
I am building a Mobile Application (Phone, Jquery Mobile) for Android.
It requires a user sending a message to the server side script using an Ajax request. I implemented a system such that messages sent are not sent immediately, instead they are stored in a SQLite database (this is so because, I want the user to think the message is sent even if the network is bad) and an iteration that runs every 15 seconds in the background picks it up and send it. So therefore, if 5 messages are in the SQLite database, they will be sent every 15 seconds apart.
The above system works fine when I tested it with my Android phone connected to my WAMP via Wi-Fi.
The problem I now foresee is that when I deploy on a production Server, the Ajax response from the server won't be that fast.
Is there a way to avoid a potential problem?
Note: The response from server is via json and it is essential because it will be used to delete the message from the phone SQlite Database.
Here is how I read your question:
A user interacts with the app and this generates actions that need to be updated on your backend. (for example, "like a post", "upvote a coment" etc.)
You have decided that the action does not need to complete synchronously and that the user does not need to wait around for the action to be completed/acknowledged; The user can continue on with new actions. At some point, the user will see that the actions have been processed but immediate updates aren't important.
Your polling loop in the app is responsible for eventually sending the actions to the backend to be completed. The backend acknowledges the action has been completed by sending a response back to the app to delete the pending action.
My answer based on above:
Since it is the app waiting on your custom protocol to complete and not the user waiting on a synchronous action to complete, you have a lot of flexibility in the server's response times.
More important is that your little protocol makes sure to eventually process the action on the backend and notify the client app. You are dealing with the concept of things becoming "eventually consistent" and thus you need to design your little protocol around that:
http://en.wikipedia.org/wiki/Eventual_consistency
I need to build a notification system for a website that gets traffic from at least 5,000 users at the moment.
The users win points performing certain activities. This activity gets recorded to a database table.
The problem is, it's not always an AJAX call to the server that does it. One of the items is an iFrame photo upload. Plus, not every user is enrolled in points, so I want to avoid building code that looks for these things when updates occur, so I don't have to write alternative code for users not enrolled. Lots of these things are normal actions that any user would do, enrolled or not.
I want to show a div on the page describing the reward the user just did. It's similar to the way XBOX Gamerscore points are shown when awarded.
My best idea thus far is to run an AJAX call to the server at an interval looking for non-alerted items. But I want to keep it light, like once every 10-15 seconds.
Any other solutions for this? I'm running this off a shared hosting environment, so I won't have the ability to do crazy things with the server nor be able to do long polling.
Thanks!
Clint
I am working on a updating an existing visitor tracking script on a high traffic website. I noticed that there is a problem not with the script itself, but with what happens when there are multiple requests. Let's say a user double clicks on certain links to my site and there end up being two requests made at effectively the same time. Request 1 gets processed and a session is created. The script then proceeds to add a visitor record to the database. At the same time, request 2 is getting processed. It checks whether a session is set and there isn't, so it does the same thing as request 1 does. Now, we have 2 different sessions and 2 records in the visitors table in the database, when there should really be one. The session id for the current session ends up being from whichever request finished last.
So, what I'm looking to do is to prevent this from happening. Even if there are 100 multiple concurrent requests from the same visitor, I want there to be only one session id created and above all, only one record (not 100 records) inserted into the visitors table in the database. This involves determining in a matter of a few milliseconds that one request was already made. Any ideas?
You can set the beginning of your script to force a specific session. http://www.php.net/manual/en/function.session-start.php
I have the following workaround for my java application. When first accessing the php server I send a blocking ping call that establishes the unique session id. Afterwards I start my concurrent requests to the php server. This should also be possible from a web page for example in an init block.
I want to create a bidding system where user can see the current price of items. And if any other user on any other location place a bid before me it should auto update bid in my browser.
I have read about autoupdate JS+Ajax functions but even if I place a 5 second timer to auto update the content on user's browser will it not put some extra load on server by making an ajax call every 5 second? Its a bidding system so user will have bids updating within 1-2 seconds so if i put an auto update ajax call for every 1-2 seconds it will put a lot of burden on server.
So I am wondering is there any better way to handle this type of stuff? how do twitter/facebook do update user's feeds?
AJAX or not, bidding systems always have high requests because people keeps refreshing the page to check for the latest bid information.
You can take a look and attempt long polling. Long polling a method where you "push" data from the server to the browser in response to the browser's HTTP request. It is a normal HTTP connection. This may reduce the number of requests sent from users to server, however you will still have many open and active connections between your users and your server.
You will want to look at long polling. In essence, this is how it works
On the server you need some sort of event mechanism (no probem with PHP)
Client (Browser) starts an AJAX request referencing a bidding item
Server checks for changes on the bid, if there is one, returns the request
If not, he waits for some time (minute range), waiting on an event concerning this bid
If such an event occurs, server returns the request with the info, if not he returns the request with "no bid" info
You might be able to get away with a streaming model...
Each JS client connects to the server once and keeps the conneciton open. As new events arrive at the server, they are broadcast to all the open connections in real time.
This is similar to the mechanism twitter uses to broadcast tweets.