What makes a website slow?
from 
WinCustomize Forums
WinCustomize Forums
Most people assume that it's just bandwidth that makes a site slow.
But there are other factors, especially here at WinCustomize. One problem the site faces is that indeed the bandwidth is maxed.
But another problem is that when you have 700 people on at once (like when I type this) accessing the database, the CPUs of the servers can get creamed.
Solving that is a trickier problem. A website like WinCustomize has two major CPU hogging processes:
1) You have the SQL database itself.
2) You have the scripts being run.
There are solutions to all of these things but the problem comes down to time. And as they say, time is money.
One way to solve problems is to have the SQL database on one machine and the scripting on another. This has been the way WinCustomize was and will probably have to go back to doing that. The problem with that is it that creates some database latency when you're going to another machine, even on a 100 base T. So we may have to go back to a 3 machine setup (machine 1 for SQL, machine 2 for scripts, machine 3 for files). And acutally there's a 4th machine involved for handling your Stardock.net accounts.
On scripts, if you can convert them to being DLLs rather than on-the-fly scripts, you can reduce things dramatically. Of course, that makes it tougher to modify them in the future and takes work.
A really effective way to reduce CPU usage is to rely less on dynamically generated pages. WinCustomize could reduce this quite a bit by switching to this in more areas. For example, if we took away the option to let users pick how many skins they see per page, that would let us generate the page once and everyone else would just reload it somewhat easier. Throughout the pages if the material was just generated once when it changed and then just read that would help. But on the other hand, it would make having the site itself "skinnable" (you can customize the way WinCustomize looks) much harder.
WinCustomize itself has evolved over the months to be much more efficient than it used to. And more and more users have come to visit the site since th site's popularity seems largely limited to how many visitors it can handle before it gets too slow.
To become faster, the site will have to continue to be modified so that it hits the database less and the scripts use less CPU power while somehow either getting bandwidth use down or increasing the amount total.
But there are other factors, especially here at WinCustomize. One problem the site faces is that indeed the bandwidth is maxed.
But another problem is that when you have 700 people on at once (like when I type this) accessing the database, the CPUs of the servers can get creamed.
Solving that is a trickier problem. A website like WinCustomize has two major CPU hogging processes:
1) You have the SQL database itself.
2) You have the scripts being run.
There are solutions to all of these things but the problem comes down to time. And as they say, time is money.
One way to solve problems is to have the SQL database on one machine and the scripting on another. This has been the way WinCustomize was and will probably have to go back to doing that. The problem with that is it that creates some database latency when you're going to another machine, even on a 100 base T. So we may have to go back to a 3 machine setup (machine 1 for SQL, machine 2 for scripts, machine 3 for files). And acutally there's a 4th machine involved for handling your Stardock.net accounts.
On scripts, if you can convert them to being DLLs rather than on-the-fly scripts, you can reduce things dramatically. Of course, that makes it tougher to modify them in the future and takes work.
A really effective way to reduce CPU usage is to rely less on dynamically generated pages. WinCustomize could reduce this quite a bit by switching to this in more areas. For example, if we took away the option to let users pick how many skins they see per page, that would let us generate the page once and everyone else would just reload it somewhat easier. Throughout the pages if the material was just generated once when it changed and then just read that would help. But on the other hand, it would make having the site itself "skinnable" (you can customize the way WinCustomize looks) much harder.
WinCustomize itself has evolved over the months to be much more efficient than it used to. And more and more users have come to visit the site since th site's popularity seems largely limited to how many visitors it can handle before it gets too slow.
To become faster, the site will have to continue to be modified so that it hits the database less and the scripts use less CPU power while somehow either getting bandwidth use down or increasing the amount total.
I don't get enough traffic to see if it slows the servers at all, though.