I have made a progress sheet that between 1-30 users will update constantly throughout the course of the day. It’s controlled by PHP and jQuery and all the data is stored in a mySql database.
It’s quite slow on the live server, because I re query on searches and filters. I was wondering where is the best place to store the result, because I only need the latest updates but I do not need to constantly filter and update.
Is it okay to store that kind of data in a session or who else could I store it to avoid full query on every change/search or when the page changes?
I did look into memcached, but I ended up redesigning it.
I used jQuery to filter the records using hide() and show() on the data attributes that matched, instead of using a “LIKE '%Darren%'” SQL query.
This puts the load on the user’s terminal opposed to my server (Try to keep the animations to a minimum, to keep the memory usage low).
Then I store a timestamp of the last update on the user’s terminal in the HTML then run a
“SELECT id FROW progress WHERE updated > '2014-02-20 16:54:30' LIMIT 1” query periodically.
If I get 1 record back I use Ajax to a full update and refresh the areas required with fresh HTML.
Doing it this way has made it so much quicker and smoother.
I how this helps, if you need more info let me know!
Related
I'm running a server and website for an online game.
I need to pull information from the mySQL database containing player names and messages and display it on our website.
I managed to do that with a php script which directly pulls the info from the MySQL database whenever someone opens the page.
However, this puts unnecessary load on the server.
I need to achieve so that the function pulls the data only at certain intervals, for example, every hour.
I have no idea how to do this and what to even look for in terms of functions.
Could anyone show me the right direction?
If you're worried about the load being placed on the call being made every time the user opens up the site, perhaps first you should look into caching. Something like APC or memcached, that way there isn't an actual DB lookup, it just returns the same data that it grabbed last time You just set the period that you want the cache to hold the data so that in time it will grab a fresh copy, in your case this would be an hour.
There's a bunch of questions on APC, memcached etc on stack overflow that should be able to help you out, e.g., The best way of PHP Caching
I have table called playlist, and I display those details using display_playlist.php file.
screen shot of display_playlist.php:
Every time user clicks the 'up' or 'down' button to arrange the song order, I just update the table.But I feel updating DB very often is not recommended, so Is there any efficient way to accomplish this task.
I am still a newbie to AJAX, so if AJAX is the only way to do it, can you please explain it in detail.thank you in advance.
In relative terms, yes, hitting the database is an expensive operation. However, if the playlist state is meant to be persistent then you have to hit the database at some point, it's just a question of when/how often.
One simple optimization you might try is instead of sending each change the user makes to the server right away, allow them to make however many changes they want (using some client-side javascript to keep the UI in the correct state) and provide a "Save Playlist" button that they can press to submit all of their changes to the server at once. That will reduce database hits, and also the number of round-trips made to the server (in terms of what a user experiences, a round-trip to the server is far more expensive than a database hit).
More broadly though, you shouldn't get hung up over hypothetical performance concerns. Is your application too slow to handle its current load (and if so, have you done any profiling to verify that it is indeed this database query that is causing the issue)? If not, then you don't need to worry too much about changing it just yet.
You can have a save button, so instead of updating on each move there will only be one update where you update every row at one time. This also lets you have a cancel button for people to refresh the way it was.
You can do it so users can change locally all they wish; defer writing the final result to the database until they choose to move on from the page.
if you really want to avoid updating the database, you can try some JavaScript based MP3players , which allow you to pass the path to *.mp3 files.
Then I suggest you to use Jquery UI - Sortable
and use it to update the songs list to the flash player ..
Using PHP5 and the latest version of MySQL I want to be able to track impressions and clicks for business listings. My question is if I did this myself what would be the best method in storing it so I can run reports? Before I just had a table that had the listing id, user ip address and if it was a click or impression as well as the date it was tracked. However the database itself is approaching 2GB of data and its very slow, part of the problem is its a pretty simple script that includes impressions and clicks from anyone including search engines and basically anyone or anything that accesses the listing page.
Is there an api or file out there that has an update to date list that can detect if the person viewing is a actually person and not a spider so I dont fill up the database with unneeded stats? Just looking for suggestions, do I just have a raw database that gets just the hits then a cron job at night tally up for the day for each listing for each ip and store the cumulative stats in a different table?
Also what type of database should it be? Innodb? MyISAM?
I would think that you will never create something better then what is already out there. I'd use Google's analytics. If you want to use it in an admin side of a site (for a client to run may-be) you can always use googles api and pull the data as you need. here is where I'd look.. http://code.google.com/intl/en-US/apis/analytics/
hth Cheers -Jeremy
Just in case you need to distinguish real users from bots, here's a simple solution: use javascript for sending reports to the server.
Let's say you have a link and you want to track when it's clicked. Then add an onclick handler, which will send a decent report to the server. Here's an example:
Some page
The track function would look like this one:
function track(action, data) {
var Img = new Image();
Img.src = '/track.php?action=' + action + '&data=' + data;
}
So in this case when a user clicks the link, the information about this click will be sent to the server by this piece of javascript code. Bots can't run javascript, so they won't be counted. There is one drawback though, if a user has disabled javascript in his browser, your tracking script won't count such a user. Obviously, you'll need to implement the track.php script in order to store the data.
Concerning your MySQL question, I'd pick MyIsam as it seems to be more tolerant to lots of intserts. Also, you can look at INSERT DELAYED statement, and your idea about nightly cron jobs seems reasonable to me. You can split your statistics table by days, weeks, or months as well.
99.999% of the time, you will juste write into the database.
So for this kind of work, daily partitioned MySQL tables will do the job.
Each day write on the same partition, and run an ANALYZE PARTITION on your yesterday partition.
I have an area which gets populated with about 100 records from a php mysql query.
Need to add ajax pagination meaning to load 10 records first, then on user click to let's say "+" character it populates the next 20.
So the area instead of displaying all at once will display 20, then on click, then next 20, the next... and so on with no refresh.
Should I dump the 100 records on a session variable?
Should I call Myqsl query every time user clicks on next page trigger?
Unsure what will be the best aproach...or way to go around this.
My concern is the database will be growing from 100 to 10,000.
Any help direction is greatly apreciated.
If you have a large record set that will be viewed often (but not often updated), look at APC to cache the data and share it among sessions. You can also create a static file that is rewritten when the data changes.
If the data needs to be sorted/manipulated on the page, you will want to limit the number of records loaded to keep the JavaScript from running too long. ExtJS has some nice widgets that do this, just provide it with JSON data (use PHP's encode method on your record set). We made one talk to Oracle and do the 20-record paging fairly easily.
If your large record set is frequently updated, and the data must be "real time" accurate, you have some significant challenges ahead. I would look at comet, ape, or web workers for polling/push solution and build your API to only deal in updates to the "core" data--again, probably cached on the server rather than pulled from the DB every time.
your ajax call should call a page which only pulls the exact amount of rows it needs from the database. so select the top 20 rows from the query on the first page and so on. your ajax call can take a parameter called pagenum and depending on that is what records you actually pull from the database. no need for session variables.
I am writing a PHP/MySQL application (using CodeIgniter) that uses some jQuery functionality for dragging table rows. I have a table in which the user can drag rows to the desired order (kind of a queue for which I need to preserve the rank of each row). I've been trying to figure out how to (and whether I should) update the database each time the user drops a row, in order to simplify the UI and avoid a "Save" button.
I have the jQuery working and can send a serialized list back to the server onDrop, but is it good design practice to run an update query this often? The table will usually have 30-40 rows max, but if the user drags row 1 far down the list, then potentially all the rows would need to be updated to update the rank field.
I've been wondering whether to send a giant query to the server, to loop through the rows in PHP and update each row with its own Update query, to send a small serialized list to a stored procedure to let the server do all the work, or perhaps a better method I haven't considered. I've read that stored procedures in MySQL are not very efficient and use a separate process for each call. Any advice as to the right solution here? Thanks very much for your help!
Any question that includes "The table will usually have 30-40 rows max" ends with "Do whatever you want to it." I can't imagine an operation, however frequently it's performed, that would have any appreciable performance impact on a table that tiny.
The only real question is what the visitor will be doing while your request is going to and returning from the server. Will they be locked out of making other changes? If not, make sure you have a mechanism to ensure that the most recent change is the one that's really taken effect. (It's possible for requests to reach the server out of order, and you wouldn't want an outdated request to get saved as the final state.)