|
speed of the site
|
View this Thread in Original format
| ddominey86 |
"Hate something on the site?"
yes, i hate how slow it gets sometimes when there are lots of people browsing :(
so, my suggestion is, to install a php cache on the server, because it speed it up an inane ammount.
from my experience, Turck MMCache has been the best php caching system to speed up websites.
you can find it here: http://turck-mmcache.sourceforge.net/index_old.html
i'd really like to see this installed on the server, so we no longer have to get any errors saying that the server is too busy, or simply not connect at all |
|
|
| Freezel |
| Thursdays is always slow for TA during ASOT ;) |
|
|
| jp |
| I think the speed is rather good lately :) |
|
|
| ddominey86 |
| quote: | Originally posted by Freezel
Thursdays is always slow for TA during ASOT ;) |
well, of course, but it shouldn't be, and if this caching is used, it wouldn't be |
|
|
| Coup |
| The site speed is generally very fast. Me and Neo grind the forums to a hault when we do an IP trace to deal with suspended members coming back and causing , but other than when we do that its very fast now search has been re-coded. |
|
|
| ddominey86 |
| quote: | Originally posted by Coup
The site speed is generally very fast. Me and Neo grind the forums to a hault when we do an IP trace to deal with suspended members coming back and causing , but other than when we do that its very fast now search has been re-coded. |
actually, the only time its slow is on thursdays, ip traces take no cpu at all. its slow on thurdays because of A State Of Trance.
BUT, i'm telling you, with all of 5 minutes of work, you could make the site stay nice and speedy even then, i can even help you guys set it up if u wanted |
|
|
| Swamper |
IP trace may not take a lot of CPU but it takes up a lot of disk I/O since it has to go through the whole post table and find matching IPs across a range and then join that with the user table. It's not worth adding an index to speed things up because then the overall size of the post table would increase adding bottlenecks to other things.
MMCache has been installed since 2003 - however it hasn't been updated since 2004 and most sites now have moved to eAccelerator (especially vB 3.x sites since certain functions run into problems with mmcache installed)
When there is an error about the site being busy it is due to bottlenecking and table locking issues when big queries are done on a table -- which is why search has been modified -- to help resolve those.
Currently one big problem is when someone uploads an Unknown Track - the hash list (matching attachmentID with the corresponding filename/mp3 sample) is updated and for that it goes through the whole thread/post table looking for unclosed threads + ones with samples attached - to speed up playback from the threadlist in that forum -- problem is that while it's updating all other actions on the post/thread table (browsing/updating view count/replying) are put on hold, and sometimes it can take a minute for it to update. |
|
|
| ddominey86 |
| quote: | Originally posted by Swamper
IP trace may not take a lot of CPU but it takes up a lot of disk I/O since it has to go through the whole post table and find matching IPs across a range and then join that with the user table. It's not worth adding an index to speed things up because then the overall size of the post table would increase adding bottlenecks to other things.
MMCache has been installed since 2003 - however it hasn't been updated since 2004 and most sites now have moved to eAccelerator (especially vB 3.x sites since certain functions run into problems with mmcache installed)
When there is an error about the site being busy it is due to bottlenecking and table locking issues when big queries are done on a table -- which is why search has been modified -- to help resolve those.
Currently one big problem is when someone uploads an Unknown Track - the hash list (matching attachmentID with the corresponding filename/mp3 sample) is updated and for that it goes through the whole thread/post table looking for unclosed threads + ones with samples attached - to speed up playback from the threadlist in that forum -- problem is that while it's updating all other actions on the post/thread table (browsing/updating view count/replying) are put on hold, and sometimes it can take a minute for it to update.
|
when i posted this, and for months before, mmcache was not installed, or at least not loaded, because it didn't show up in http://www.tranceaddict.com/phpinfo.php
and the fact that it has only cached 83 scripts at this point, means it hasn't been running long, u trying to make me look stupid or what ?
and, by adding more indexes to the database, u definetly would not decrease the speed of the server, it would just slightly increase mem load, and would make any queries that use that index go insanely faster
as for the last bit, if thats the case, then u need to add some more indexes to speed it up, the easiest way to find out what needs an index, is to find the queries that take the longest, and then do a query EXPLAIN(query here) and it will tell you which indexes it uses, and also if there should be an extra index |
|
|
| Swamper |
| quote: | Originally posted by ddominey86
when i posted this, and for months before, mmcache was not installed, or at least not loaded, because it didn't show up in http://www.tranceaddict.com/phpinfo.php
and the fact that it has only cached 83 scripts at this point, means it hasn't been running long, u trying to make me look stupid or what ?
and, by adding more indexes to the database, u definetly would not decrease the speed of the server, it would just slightly increase mem load, and would make any queries that use that index go insanely faster
as for the last bit, if thats the case, then u need to add some more indexes to speed it up, the easiest way to find out what needs an index, is to find the queries that take the longest, and then do a query EXPLAIN(query here) and it will tell you which indexes it uses, and also if there should be an extra index |
I just explained to you that adding an index for IP would not be a good idea since IP searches are not frequent enough events to warrant the increase in size (which would be roughly 100 megs given a 5.1+ million post DB). It has to do with disk I/O (I never said 'speed of server' - which is ambiguous - speed of what? throughput? I/O? return on query?) and parsing through a much larger dataset (which impacts search - hence why it has been broken up into date ranges).
You claim to have such easy solutions - perhaps you'd wish to post them on the vBulletin.com forums in the thread where the people with forums much larger than TA struggle with the same issues and the vB developers admit to there being scalability issues with vB/myIsam tables with respect to not having row locking and the pros-cons of converting some to innodb.
The reason mmcache wasn't loaded when you began your post is because I'm moving the forum to vb 3.x (www.tranceaddict.com/forum3) and you cannot load any pages in vB 3 with mmcache installed - it requires eAccelerator - which I haven't bothered to install yet. 83 isn't so far away from the normal # of scripts cached (90+) - besides - the webserver is restarted nightly (after logs are sent out for processing under Urchin on another server) - at which point the # of scripts cached is reset to 0 anyways.
I'm not making you out to look stupid - but - you are naive in thinking that it is as trivial as '5 minutes of work' and adding an index to remedy the problems you encountered on TA. |
|
|
| oje_oje |
For me as a user it is not that important to have mmcache or not. The only problem I have is the same ddominey86 has: speed (or lack of). And it sucks a lot. Sometimes I am waiting for more than a minute before a minor action is completed. Stopping the reload process of the page and re-hitting "Submit reply" when you just modified something also does not help (but produces lots of double postings or even swarms of postings of the same content that you have to delete afterwards).
Edit: Hope that TA/v3 will make it smoother....
Edit2: Hope, that TA doesn't lose its unique "look & Feel". The current implementation of forums3 looks like any other forum around.... |
|
|
| Swamper |
| quote: | Originally posted by oje_oje
Edit2: Hope, that TA doesn't lose its unique "look & Feel". The current implementation of forums3 looks like any other forum around.... |
Pick 'TA Default' from the bottom left - it is still a big mess and a lot of things need to be re-coded but trust me, the last thing I want is for the forums to look like all the other generic crap out there. |
|
|
| Fl1p |
| i have eAccelerator installed on my vps server and i also optimize my my.cnf file, play around with the configuration and see what would be best for your site, with all the tweaks i've made my site load way faster :) |
|
|
|
|
