That's not been one of our bottlenecks, traditionally. The beginning of this year was pretty hellacious though.
I don;t think I understand. What is our problem then?
Xander ,'Lessons'
A thread to discuss naming threads, board policy, new thread suggestions, and anything else that has to do with board administration and maintenance. Guaranteed to include lively debate and polls. Natter discouraged, but not deleted.
Current Stompy Feet: ita, Jon B, DXMachina, P.M. Marcontell, Liese S., amych
That's not been one of our bottlenecks, traditionally. The beginning of this year was pretty hellacious though.
I don;t think I understand. What is our problem then?
What is our problem then?
CPU cycles. There's very little we can do to change the amount of bandwidth we use, save a killing spree (which I'm always down for). But the way that our current architecture uses CPU cycles, we need a box to ourselves, because we'd bring everyone else on a shared server to a halt.
oh. and what increases CPU cycles?
Bugs in the MySQL code, which our code hits.
Also general usage, which is paralleled pretty closely by bandwidth.
Bugs in the MySQL code, which our code hits.
Which bugs are these?
Those bugs don't cause any extra resource usage. They just cause the count of open connections to be incorrect.
I don't know of any bugs in MySQL that cause the board to consume extra resources.
Those bugs don't cause any extra resource usage. They just cause the count of open connections to be incorrect.
Well, money is a resource, and all of our shared servers charged us for the miscounts.
Rob, were you the one working on MARCIE?
I don't know of any bugs in MySQL that cause the board to consume extra resources.
Hmm. Odd. The previous host correlated the incidences of us eating every connection with the CPU usage spiking and bringing server performance to its knees.
You're saying there's something else we should be looking at in our code? Did you notice anything while you were working on the filter?