2

We are having performance issues on our server which may or may not be the inevitable result of high traffic to our sites. We would like to optimize each site for performance so that we can be sure we're getting the most "bang for our buck" before purchasing additional hardware.

I was wondering if anyone knew of some creative ways to measure the resources (memory, bandwidth, CPU time, etc) consumed by each Web site. This could allow us to spot the biggest "offenders" and start working on those first.

We are running Red Hat Enterprise Linux Server release 5.6 (Tikanga)

2
  • are these sites running CGIs? php? serving static files?
    – stew
    Feb 14, 2012 at 15:14
  • PHP/Apache and the usual static files. Most of these sites are running either Wordpress or Magento. Feb 14, 2012 at 15:35

5 Answers 5

3

I would start with mod_log_config. Define one or more LogFormat/CustomLog setups in httpd.conf with just the stats you're interested in and any metadata about the requests you care to filter by and then you can quickly generate comparative stats from those log files. For example:

LogFormat "%t %v %B %D %h %r" statlog
CustomLog "|/usr/bin/cronolog logs/stat.log.%Y-%m-%d" statlog

%t is the timestamp, %v is the virtual server hostname, %B is bytes sent (excluding headers), %D is microseconds elapsed, %h is client IP address, and %r is the first line of the actual HTTP request sent by the client. So you can leave in or out any of that other information, depending on what you're looking for, or have one log for each stat, or whatever you want. (I like using cronolog to rotate logs on a daily basis. Tack on -%H if you want hourly rotation.)

Then you can run the appropriate columns through whatever number-crunching you want to get totals, averages, identify particularly slow or abusive pages, or what-have-you.

Additionally, if you have mod_logio enabled, you can get exact byte counts (after encryption/compression/everything) for incoming and outgoing bandwidth for each request using %I and %O respectively in your LogFormat string.

1

Running suexec would make it easier to see what users are using more resources, as their php processes would appear to be running as their users instead of as the system user running apache, such as www-data or nobody.

In my experience, magento is a HUGE resource hog, especially if you are just running it as it comes out of the box. We used to perhaps put a couple moderately busy sites on a single box. With magento we find ourselves putting one site on multiple boxes.

You certainly don't want to run magento without trying to make some adjustments for performance. I'd strongly encourage you to setup memcached as a cache for magento (instructions here). and store your sessions in memcache, and turn on block caching. (This will take the html which is generated by individual blocks and store it in memcache, so that the next time the same block is accessed, the phtml files don't have to be run again).

You may want to run an opcode accellerator like APC for caching PHP opcodes.

Update:

You definitely want to make sure mysql is tuned, especially that you have enough in the innodb buffer pool. (magento's tables are all innodb). I think a good place for reading about mysql performance tuning is the the mysql performance tuning blog. I'd start with tuning the innodb_buffer_pool_size. Note that they are typically talking about running mysql on a server that does nothing but run mysql, so when they say "dedicate 12 gigs on a 16 gig box to innodb_buffer_pool" you should adjust that way down, as your box is doing more than just mysql.

4
  • Thanks stew - we've actually done all of those things - minus the "mysql tuning." Would like to know more about that. Do you know anyone who specializes in this? (And would like to also share some of their knowledge with me? :) Feb 14, 2012 at 16:16
  • updated with more clues about mysql
    – stew
    Feb 14, 2012 at 16:24
  • Thanks - actually we do have a dedicated MySQL server as well. Feb 14, 2012 at 16:26
  • The tuning-primer.sh script is a great starting point for MySQL tuning. day32.com/MySQL/tuning-primer.sh Aug 24, 2012 at 14:15
0

You're starting from the wrong end.

Traditionally (and also sanely!), you START by identifying an actual problem; then you progress to diagnosing its causes, and only THEN do you add hardware or change software configurations.

If there is an actual, observable problem occurring right now, that is the place to start: try to identify exactly under which circumstances it occurs, whether it is precisely reproducible, and guesstimate what the impact is on the business.

Next up, start collecting performance data from your application stack; this may involve but is probably not limited to : OS resource utilization, web server metrics, PHP caching, databases, disk I/O and latency.

I'm sorry if the answer seems vague or generic - so was the question.

1
  • I appreciate your opinion. But I think that wanting to make sure I am getting the maximum performance from my current configuration is valid on its own - that's just my opinion. I know it must be possible, for example, to determine the total amount of bandwidth consumed by a single Web site in a 24 hour period - I am just not sure exactly how to go about this. Surely there are tools out there that can help. Feb 14, 2012 at 15:44
0

Use a Metric Collection System like Cacti or Munin.

0

I always run collectl on all servers. It samples tons of metrics every 10 seconds and slab/process data every minute and writes it all to a file you can playback OR plot with colplot (part of collectl-utils). You can also run it in real-time at any sampling interval of your choice.

Based on what you see over several hours or even days, you can then begin to take the approach very clearly stated by apaptr, of first figuring out if there even is a problem and then taking steps to correct it. Having collectl data at each step in the process makes it very easy to tell if things have improved or gotten worse.

-mark

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .