Is there an application or a code I can use to check which cache functions are turned on?
On this app I'm working on, I thought there was mysql cacheing, but since I started using the SELECT SQL_NO_CACHE in one of my queries (applied yesterday), the cacheing has not stopped. This leads me to assume it's a php cache function that's occurring.
I looked over php.ini for any possible cache features, but didn't see anything that stood out.
Which leads me to this: Is there an app I can download or a Shell function I can input to tell me which cache functions are on or what may be causing the cache.
You probably already know that MySQL has a query caching mechanism. For instance if you have a table named users, and run a query like this:
SELECT COUNT(*) FROM `users`
It may take 3 seconds to run. However if you run the query again, it may only take 0.02 seconds to run. That's because MySQL has cached the results from the first query. However MySQL will clear it's cache if you update the users table in any way. Such as inserting new rows, updating a row, etc. So it's doubtful that MySQL is the problem here.
My hunch is your browser is caching the data. It's also possible that logic in your code is grabbing the old row, updating it, and then displaying the old row data in the form. I really can't say without seeing your code.
You probably need to close and restart your browser. I'd bet it is your browser caching not the back end.
Related
I'm new to MYSQL and there is something really weird happened and I can't figure out why.
Recently, the INSERT query to some of the table become extremely slow. Weirdly enough, the query time all around 60 secs.
The tables are all with the only 10k to 35k entries, so I think they are not that big.(But indeed they are the biggest one in the database, though.)
And the slowness is only with INSERT query, DELETE, UPDATE, SELECT are all executed with 0.000x sec.
Can some help me find out why is this happening?
UPDATE: So I turned on the general log and noticed all my INSERT queries are followed with 'DO sleep(60)'. It seems my server got hacked?
Where can I find this malicious script inject the sleep() command after INSERT?
If you use code to build the queries, copy the code base off the server to your machine (ideally in a VM, just in case) and search for the changes within the code. Alternatively, you could restore the code base from source control (you use source control, right?!).
If it's store procedures you use, you'll need to change them back to a working version without the sleep. Check previous backups to try and find out when this happened, which might help a wider investigation as to how they got in and did what they did.
You'll also need to think about the wider implications of this. Do you store user data? If so, then you'll need to inform them that you've had your database compromised and therefore they should assume their accounts are and change their passwords.
Finally, wipe the server. A hacked server is no longer in your control (or that's how you should look at it). Wipe it, reinstall everything, and put in changes to help prevent the same hack happening again.
I have not come across a good suggestion on how to keep the database and memcache in sync.
I use MySQL 5.5.28, Zope 2.12.19 in my web application.
So, some of the suggestions are like once you do a select from memcache (during a cache hit), it sends the data from the cache. After this cache is invalidated and data is selected again from the database for the cache to be re-populated. But only because the database operations are expensive, we have opted to use cache in the first place. So how is this solving the problem of faster access ?
The other solution seems to be update memcache using triggers on the source table. Any inputs on this would be appreciated as I do not understand how this is done.
Below are the links with the best solutions that I could find to the above questions.
The answer to my first question that mentions about the use of cache with rapidly changing data.
Well, caching is not ideal if the data changes frequently. This is true with less number of users.
But if the number of hits to the website increases, then caching is really useful when the following approach is used:
INSERT, UPDATE or DELETE operations will invoke triggers that would invalidate the cache.
And when the page is loaded, SELECT will be used and the resulting data will be stored in the cache until it is changed again. This way, the application's code does not have to be modified throughout the system by using triggers for INSERT, UPDATE, DELETE on the respective tables. Only SELECT needs to be handled in the code.
Regarding my second question on how to use triggers to manipulate cache, the link below has been extemely useful in answering my question:
http://code.openark.org/blog/mysql/using-memcached-functions-for-mysql-an-automated-alternative-to-query-cache.
I'm using phpmyadmin and working on someone site whose information is pulled from a database with a table called "profile_types" I had to add a row for a new type but the website isn't reflecting the changes. I've been reading around and "have query cache" is set to yes so figured I should clear the cache and see if that helps any.
So after reading I was trying to use RESET QUERY CACHEl but kept getting an error about using RELOAD> So after some more reading I can't figure out how to use the RELOAD command. As far as I know this is the databases only user account so I'd figured it was admin and had the necessary privs. Am I missing something? Also, do you guys thinks doing the RESET QUERY CACHE would maybe allow it to update the site with the new record? I've cleared my browsers cache and tried all that and no go so figured this was my last option.
The query cache is for the results of selects. It doesn't "cache" inserts - if queries were stuck into the cache and then not reflected in subsequent results, the database wouldn't be ACID compliant.
In other words, imagine if this was a banking database, and it "cached" deposits but made sure withdrawals were reflected immediately. You'd be drowning in overdrafts. Oh... wait... That's how banks work these days.
Albeit all its greatness, it is very annoying that MySQL Workbench 5.2 freezes each time it submits a query, instead of allowing it to be performed asynchronously.
It is not even possible to launch a second instance to do other tasks in the mean time.
Do you know if there is a setting somewhere to adjust this behaviour, or is it a "feature"?
Pretty sure it's a feature. You can run more than one query in a script. There are a lot of cases where you would want/need queries to run sequentially. I don't know of any query editor tools that allow for what you want.
If you're using php you could fire off several AJAX requests to pages that each ran one of the queries you need ran, but unless you are doing something like this often; it wouldn't be worth the time to set up.
If i execute active record query after some time gap, it takes longer.
Say Item.all takes .11 sec on first query and .003 later on. what could be possible reason for this behaviour?
edited:
active record query cache 's scope is action of controller. In my case, active record query in subsequent http request is also faster.
Possible explanations:
ActiveRecord Caching
Connection Pooling (it doesn't have to restart the connection)
Load on the web server or db server.
ActiveRecord caches the results from queries. The first query is actually hitting the database - ActiveRecord then waits for the operation to complete and parses the results into its objects. The next time an identical query is made, it has the results cached so that they are returned to you immediately, instead of going all the way back to the database.
Check the API for the QueryCache: it seems like you can clear the query cache (connection.clear_query_cache) if you want to wipe out cached queries.
This SO question also suggests self.class.uncached do ... end to bypass the cache but I am not sure if this still applies in Rails 3.
It's definitely ActiveRecord's caching you're looking at. See doc.
All of the methods are built on a simple caching principle that will
keep the result of the last query around unless specifically
instructed not to. The cache is even shared across methods to make it
even cheaper to use the macro-added methods without worrying too much
about performance at the first go.