Benefits of a seperate image server?

How to tell if it will be worthwhile...

[limitup]

My site is heavily database driven, and getting pretty busy. I'd like to delay the inevitability of moving the entire site to a mega powerful server, or setting up a separate database server, so for now I was thinking of just setting up a seperate image server which would be nice and simple. The site does not use a ton of large graphics, but due to the navigation, etc. each page probably has about 20-30 small images. Would I notice a measurable drop in the load of the main server if I were to start loading images off another server? Is there any way to estimate it in advance? I've heard that this can work wonders as a sort of cheap and lazy way of load balancing, but I'd hate to setup the new server and updates all my pages and then find that it really makes no noticable difference.

[limitup]

Also, I heard that using a dedicated image server can cause problems with P3P but I don't understand this. Does anyone know about this? Will my compliant cookies no longer work right because the page loads images from another server?

[figment88]

if the bulk of the images are from nav, a separate server likely will not help much. Most visiors' browsers will cache the images for subsequent use and not take them off your server.

I would instead think that your problem is more of a cpu limitation as your scipts grab from the database and process the output. If you are dynamically constructing each page for each request, the biggest performance boost you can probably get is caching some of your dynamic pages. That is generating a static version and refreshing it every so often.

Choice of refresh time would vary depending on how complex your page are, number of visitors, and how often the underlying data changes.

This approach gives you a lot of flexability - not just in refesh time but also in choosing which sections of your site to cache.

[blaze]

yeah, won't help at all with the images.

I think you can turn caching on automatically for php as well as other application servers.

Won't really help you if you are cookie / user dependent though..

[limitup]

Thanks for the reply, I didn't even think of that. I can implement what you describe for a good portion of the site and that should definitely help. I think the other big thing that would help is switching over to mod perl as much of the site runs on perl cgi scripts. Anything else that can be done?

[jomaxx]

It depends. My dedicated server for an extremely busy site was getting quite slow. CPU usage was sometimes quite high as well. I moved a whole bunch of images to a second dedicated server (so that about 40% of all HTTP requests go to the second server), and it helped hugely.

I don't know precisely why it helped, but I have two theories:
1. The server was reaching the limit of the simultaneous HTTP requests it could handle.
2. The server was reaching a limit on bandwidth used during some period of time, and the ISP was throttling it down.

[digitalv]

If you're running SQL from the same physical machine as your web server, that's probably the problem. Retrieving images from a server doesn't hurt the CPU any more than retrieving web pages, it's all a bunch of 1's and 0's that get turned into a picture on the client side - so don't waste your time putting images on another server.

The first thing you should try is adding more RAM to your server - as a general rule, you should try to have more RAM than the size of your database so SQL can load the entire DB into memory (which it will do eventually anyway - commonly mistaken for a memory leak, but it's not) and still have enough RAM available to do everything else. If this is possible, it will cut down on CPU performance too because the DB will be loaded into memory and won't be wasting as much CPU horsepower using swap files.

Second thing that will help - convert everything you can to stored procedures. It will run more efficiently, and that = faster.

Take a look at your table structure and make sure you're using the most suitable data type for each field. Use numbers vs. text whenever possible (including varchar/nvarchar) because those will take up more space in the DB and and take longer to search than numbers do.

Also make sure you're doing all of the little things like closing your database connection, trimming requests before they're sent to SQL server, and that you're running the latest ODBC drivers to connect to the data.

There are so many little things you can do to SQL to increase performance. I currently run a database that's about 8 GB in size, receives about 300,000 INSERT statements a day, and is constantly being accessed to both insert and display data. It runs just as well now with hundreds of millions of records in the DB as it did when I had 10 records, and that's just a dual 800 Mhz machine.

[Storyteller]

Moving all stating content (not just images) to a separate light-weight server should be the first thing you do as your load goes high. At least if you're running Apache.

Serving every request grabs an Apache instance from the pool and keeps it busy until the last byte is sent to the user. Spending server instances fully loaded with PHP/mod_perl/whatnot on serving static content is a giant waste of memory that could otherwise be spent on larger disk cache and database buffers. And having cache and buffers large enought is often critical for good performance of DB-driven web apps.