Menu
What's New
By:
Filters

Entropedia needs server maintenance

In the meanwhile I made some progress. It seems that when I replace "Chart!='Chart'" with "Chart NOT LIKE 'Chart'" the issue is solved. The query time reduces from 2.8s to 1ms.

I have absolutely no idea why but maybe to someone else this information is useful. If I do not find the cause of the problem my next course of action will be replacing all instances of "!=" with "NOT LIKE".
 
Witte said:
In the meanwhile I made some progress. It seems that when I replace "Chart!='Chart'" with "Chart NOT LIKE 'Chart'" the issue is solved. The query time reduces from 2.8s to 1ms.

I have absolutely no idea why but maybe to someone else this information is useful. If I do not find the cause of the problem my next course of action will be replacing all instances of "!=" with "NOT LIKE".
Click to expand...

Wicked, != does an exact match, "LIKE" is a wildcard match, if anything i'd imagine that'd be even slower :p
 
Glad to hear your current problem has been resolved. Even so remontoire's question is a good one. Any reason why you are returning all changes details that arent for charts?

Tried to do a quick test of the live site but clearly it is still down. Will try again tomorrow.
 
KijkkiJikki said:
Glad to hear your current problem has been resolved. Even so remontoire's question is a good one. Any reason why you are returning all changes details that arent for charts?

Tried to do a quick test of the live site but clearly it is still down. Will try again tomorrow.
Click to expand...

The actual query is a lot longer, I just removed everything that didn't influence the speed. So in actuality only the relevant data is fetched.

I experimented a bit more with what you said, the "explain" command. And there is a difference when I use "!=" or "NOT LIKE". When using !=, the key is index_2 and when using "not like" the key is index_3. In both queries there also is a possible key which is index_3. Its the same on my local machine (where is query is fast either way). Should I somehow force the query to use a key (if possible)?
 
Witte said:
The actual query is a lot longer, I just removed everything that didn't influence the speed. So in actuality only the relevant data is fetched.

I experimented a bit more with what you said, the "explain" command. And there is a difference when I use "!=" or "NOT LIKE". When using !=, the key is index_2 and when using "not like" the key is index_3. In both queries there also is a possible key which is index_3. Its the same on my local machine (where is query is fast either way). Should I somehow force the query to use a key (if possible)?
Click to expand...

Yes, if it is NOT using index_3, then it will need to do a full table scan of the table and compare Chart to 'Chart' on each row. This will be slow and is the real reason for slowness, not '!=' vs 'NOT LIKE'.

I think adding 'USE INDEX'/'FORCE INDEX' hint is what is needed, but my mysql tuning is somewhat rusty.
 
SELECT blabl FROM table USE INDEX(indexname) WHERE...
or...
SELECT blabl FROM table IGNORE INDEX(indexname) WHERE...
 
Well, it turned out that when the index is used the query becomes extremely slow. So after deleting the index, everything seems to run fine again.

I have no idea why it is like this but is seems that the trial and error method once again prevails :cool:. Thanks for the suggestions and help.
 
wow its HUGE faster today XD
 
but the search is still very slow here (and to be honest this is valid for FPC forum too, also if FPC run faster)
 
I'll second what Dr.D.C. said, site is faster but search is still dead slow.

Best regards
Zweshi
 
OMG its alot better. +rep you on an earlier post so can't again atm but many thx for working it out.

-Bemo-
 
Just something to think about, I recently converted my website (m3mi dot com) from prototype to jquery api because it works well with other frameworks and librarys. I was having the same issues you were with your site currently and after making this conversion it made things much smoother and faster. You could look into this too as it could be a possible "issue" for entropedia.

~Danimal
 
Thought it was just my computer, guess not :lmao:
 
Hard to explain in English, so i give it a try. Sometimes indexes denaturate, because the bintrees aren't implemented selfflattening. So sometimes rebuilding indicies helps a lot to speedup queries again. I had this issue in a 6Billion Entry table on oracle not so long ago.
 
If you use MySQL you can put EXPLAIN before any query to analyze the way it will retrieve data.
Also sometimes MySQL gets a hiccup and you need to call an OPTIMIZE on the table manually (very rarely but a server move might have caused a situation like this).

Also something that is important is that only one index will be used in MySQL.
I learnt that the hard way with X/Y coordinates, having an index for X and another for Y will be very slow,
while having one index with both columns, X and Y will be very fast.
 
I made some more optimizations, search and loading charts should be faster.
 
You must log in or register to reply here.
Back
Top