OK - I've now implemented DJMazes mainfile.php hacks and haven't seen a noticeable drop in page generation times
I'm beginning to get very suspicious about the setup of my MySQL server and was wondering if the more knowledgeable of you can have a quick look for anything that's looking dodgy.
My site generally has 30-60 simultaneous users on it - the box is a Sun Cobalt RAQ with a 450mhz processor, 512meg RAM and a 30 gig HD - My site is functionally the only site being run on this site (a couple of small static HTML sites are served.) It is running Linux, Apache and MySQL 3.23.49.
I would of thought that a box like this would have no probs with 30-60 simultaneous users. Anyway, here's the MySQL settings. Any help is much appreciated.
Cheers
Tama
Code:
Variable Value
back log 50
basedir /
binlog cache size 32768
character set latin1
character sets latin1 big5 czech euc_kr gb2312 gbk sjis tis620 ujis dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 cp1251 danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr greek win1250 croat cp1257 latin5
concurrent insert ON
connect timeout 5
datadir /home/mysql/
delay key write ON
delayed insert limit 100
delayed insert timeout 300
delayed queue size 1000
flush OFF
flush time 0
have bdb NO
have gemini NO
have innodb NO
have isam YES
have raid NO
have openssl NO
init file
interactive timeout 60
join buffer size 131072
key buffer size 104853504
language /usr/share/mysql/english/
large files support ON
locked in memory OFF
log OFF
log update OFF
log bin OFF
log slave updates OFF
log long queries OFF
long query time 10
low priority updates OFF
lower case table names 0
max allowed packet 1047552
max binlog cache size 4294967295
max binlog size 1073741824
max connections 100
max connect errors 10
max delayed threads 20
max heap table size 16777216
max join size 4294967295
max sort length 1024
max user connections 0
max tmp tables 32
max write lock count 4294967295
myisam max extra sort file size 256
myisam max sort file size 2047
myisam recover options 0
myisam sort buffer size 8388608
net buffer length 15360
net read timeout 30
net retry count 10
net write timeout 60
open files limit 0
pid file /home/mysql/mondo.vorb.org.nz.pid
port 3306
protocol version 10
record buffer 131072
record rnd buffer 131072
query buffer size 0
safe show database OFF
server id 0
slave net timeout 3600
skip locking ON
skip networking OFF
skip show database OFF
slow launch time 2
socket /var/lib/mysql/mysql.sock
sort buffer 524280
sql mode 0
table cache 128
table type MYISAM
thread cache size 0
thread stack 65536
transaction isolation READ-COMMITTED
timezone NZDT
tmp table size 33554432
tmpdir /tmp/
version 3.23.49
wait timeout 60
Fully agree- you've got to trade off your free time against the dollars. Which is why I now drop my car off at the garage. Taking all of a Saturday to replace brake pads isn't really rewarding if you can pay some guy $40 to do it in a hour.
I took a package that upped the speed but dropped the bandwidth for around the same dollar amount. With Nuke running as slow as it did I would of never reached the original servers bandwidth allowance anyway.
The 10-12 times faster is after I spent far too much time tuning Nuke to get the older server to run 3 times faster - so 30-36 times faster than when I first started - pretty damn pleased with that.
Tama
steven111 Lieutenant
Joined: Dec 30, 2003
Posts: 283
Posted:
Thu Jun 10, 2004 3:32 pm
I was seeing a lot of thrasing about by my server. To see that, at unix prompt do "vmstat 1". If you see "si" and specially "so" having any values other than zero, that means your server is swapping to disk!!
Very bad.
So what you do? Well, after spending a good two days, I figured out that PHPBB portion of nuke does not have all the proper indecis set up, so it was causing a table scan on some large tables. Very bad for performance.
Moral of the story: before investing in an even larger server, get yourself a step debugger (e.g. zend), and single step thru the main threads of your code (or where you see huge swapping). Find all the joins, and make sure there are indecis for all the table joins.
Also if you have large tables, most of your performanc problems would be memory bound (not cpu bound, but you can use "top" at promot to see that). So invest in more memory.
Moral of the story: before investing in an even larger server, get yourself a step debugger (e.g. zend), and single step thru the main threads of your code (or where you see huge swapping). Find all the joins, and make sure there are indecis for all the table joins.
You can also consider using a good caching system, e.g. mm turck, afterburner, APC, and others - there's a lot of choices out there.
Use JMeter to test the systems and use the best one for your configuration.
That performance tool looks good (so do the results)
I am trying to use one of the cache tools.. I develop on Windows and server on Linux, and I have not found a tool that works on both (Cache-lite which I use, works on both since it is 100% php code). But I don't think the above tools work on Windows.
[[actually, tried mmcache for windows, but could not figure out how to install it ]]
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
]]