Sensible Performance/Growth Strategies?

I’m looking for advice on how to get the most out of my servers, and
am looking for information on the advantages/disadvantages of various
strategies.

Right now, I have a production (ve) from Media Temple with 1GB and a
development (ve) with 512MB. I’m running one installation of Magento,
and get between 100-300 visitors per day. My traffic is directly
proportional to the number of products in my catalog, so I know that
as I add more products I will receive more traffic. Obviously, it’s a
humble little operation right now.

Last spring, I naively set up Apache with APC Cache and Varnish, not
realizing that it wouldn’t support SSL without further intervention.
Since Nginx can support SSL with or without Varnish, and since it has
such a great reputation for performance, I made the switch.

On the production server, I just have Nginx running by itself right
now while I work out a better system. I installed APC on the dev
server this morning, which seems to be helping with PHP memory
consumption. I intend to install Varnish as well, and should attempt
to optimize MySQL, but thought I’d consult the community before
proceeding since I’m not completely confident in the path I’m on.

I don’t really know how to weigh the pros and cons of creating a more
complicated system vs. paying for a more powerful server. Nor do I
understand at what point I should start considering memcached, load
balancing, etc. There are likely more appropriate steps between where
I’m at now and those solutions, but I’d love to have a plan of action
established for the future.

Any thoughts? Any resources where I can further educate myself? Thanks!

I would say you can run Magento with APC, php-fpm and easily server a
few hundred visitors per day on 512mb on a Debian/Ubuntu/FreeBsd
build. I have a set up on the same spec and Magento can serve fresh
pages in less than a second (which is still very slow for a cms but
much faster for Magento on Apache etc). You should be able to serve a
few thousand page views a day comfortably on a set up like this.

You can use Nginx FastCgi Cache instead of Varnish.

I haven’t tried Memcached with Magento.

Ok. Thanks for the vote of confidence. I will look into Nginx FastCgi.
How does it compare with Varnish?

What tools do you use for stress testing/performance measurements?

Thanks!

On Thu, Aug 05, 2010 at 10:08:54AM -0500, Raina G. wrote:

Ok. Thanks for the vote of confidence. I will look into Nginx FastCgi.

nginx supports caching for both proxied and FastCGI servers.
You may use this scheme:

nginx/cache -> Apache/APC

How does it compare with Varnish?

What tools do you use for stress testing/performance measurements?

I did not run tests.

Right now, I have a production (ve) from Media Temple with 1GB and a

balancing, etc. There are likely more appropriate steps between where


nginx mailing list
[email protected]
http://nginx.org/mailman/listinfo/nginx


nginx mailing list
[email protected]
http://nginx.org/mailman/listinfo/nginx


Igor S.
http://sysoev.ru/en/

On Thu, Aug 05, 2010 at 12:24:23PM -0400, Alex S. wrote:

web-performance world.

Small site / big site, audience location, content sizes, numbers of
linked static files, etc etc etc, hardware bottleneck, operating system,
network connectivity, redundancy & failover needs, everything is very
much different for every project.

For average small site (let’s say 10000 pageviews/day) differences
between Varnish and nginx will be almost identical. Remember that
Varnish created to keep as much stuff in memory as possible, and nginx
is based on OS internal things to provide performance.

Varnish relies on OS internals too: it mmap()s a huge file that
may be larger tens times physical memory and perfomance relies on
how OS flushes modified pages to a disk and how then OS reads them
back to memory.

I’m not sure about internals of each project and how they work under
Linux vs FreeBSD servers. This could be a decision reason too.

Both Varnish and nginx are developed on FreeBSD.


Igor S.
http://sysoev.ru/en/

On Thu, 2010-08-05 at 19:40 +0400, Igor S. wrote:

On Thu, Aug 05, 2010 at 10:08:54AM -0500, Raina G. wrote:

How does it compare with Varnish?
What tools do you use for stress testing/performance measurements?
I did not run tests.

Raina, my 2 cents below…

It depends on your application and needs. There is no magic bullet in
web-performance world.

Small site / big site, audience location, content sizes, numbers of
linked static files, etc etc etc, hardware bottleneck, operating system,
network connectivity, redundancy & failover needs, everything is very
much different for every project.

For average small site (let’s say 10000 pageviews/day) differences
between Varnish and nginx will be almost identical. Remember that
Varnish created to keep as much stuff in memory as possible, and nginx
is based on OS internal things to provide performance.

I’m not sure about internals of each project and how they work under
Linux vs FreeBSD servers. This could be a decision reason too.

Don’t forget about backend and application optimization too. There is
usually lots of improvements too. If you want to reach peaks of
performance you should probably consider benchmarks on every workflow
that your users go through and see how fast your backend code is.

Alex.

Thanks everyone for the replies.

A few notes to address the comments:

  1. I’m using Magento. I am willing to use plugins/extensions, and will
    apply local overrides/customizations, but don’t want to alter the code
    base to the point of having difficulties with upgrading, etc.
  2. I tried using Amazon S3 as a cheap CDN, but Varnish was WAY faster.
  3. I was using Varnish with Apache, and noticed an impressive
    performance boost. It wasn’t compatible with SSL, so I abandoned it in
    favor of Nginx.
  4. Another Magento community member had provided instructions on
    configuring Varnish for use with the combination of static and dynamic
    content that Magento relies on. I’m guessing that this will be a
    consideration with Nginx FastCgi Cache as well. So, I’ll have to sort
    that out.
  5. I just launched the site on Nginx on July 12 with the minimum
    configuration for the site to work with the extended SSL cert that I’d
    purchased.
  6. I’m on CentOS.

I really need to gain a better understanding of the basics of how
everything works. My background is in fine art–not tech. I’ve used
Lynda.com and Sitepoint to learn about front-end development. Beyond
this mailing list, blogs and general googling, I’m not sure what the
best resources are for me to become self-taught and establish a true
understanding of server management. If anyone can make suggestions
about what I should read or watch, I’m all ears.

Thanks again for joining the conversation.

On Thu, Aug 05, 2010 at 06:49:21PM +0200, [email protected] wrote:

Both Varnish and nginx are developed on FreeBSD.

Recently, we did a test with serving just static files (from a FreeBSD8.1
VM), a very small data-set.
nginx0.7 was 1.8 times faster than varnish (both mostly untuned).
So, I’d say that OOTB, just serving static files, nginx wins.
Though, I still think that varnish has a place and there are probably
certain situations where it can beat and will nginx.

What have you set behind Varnish ?


Igor S.
http://sysoev.ru/en/

Am 05.08.2010 um 18:55 schrieb Igor S.:

I’m not sure about internals of each project and how they work
Though, I still think that varnish has a place and there are probably
certain situations where it can beat and will nginx.

What have you set behind Varnish ?

Apache-worker-mpm + php (though not used, as everything is static).

IIRC, I first had no expire-headers on the apache-side and the
difference was even larger.

nginx is very impressive.

Rainer

On Thu, Aug 05, 2010 at 08:44:46PM +0200, Rainer D. wrote:

how OS flushes modified pages to a disk and how then OS reads them
VM), a very small data-set.

IIRC, I first had no expire-headers on the apache-side and the
difference was even larger.

nginx is very impressive.

It’s strange, I can not believe that Varnish may be almost two times
slower on cached responses than nginx on static.


Igor S.
http://sysoev.ru/en/

On Thu, Aug 5, 2010 at 10:41 AM, Raina G.
[email protected] wrote:

  1. I’m using Magento. I am willing to use plugins/extensions, and will
    apply local overrides/customizations, but don’t want to alter the code
    base to the point of having difficulties with upgrading, etc.

That’s my policy - never alter the core. Always extend with
plugins/modules/whatever. OO-based products are probably much easier
to extend as well. So A+ there.

  1. I tried using Amazon S3 as a cheap CDN, but Varnish was WAY faster.

a properly working CDN should offload your traffic from the origin -
it shouldn’t be considered a performance-tuning cache, it’s more for
delivering content better to different geographies and saving origin
resources for the dynamic processing, things of that nature. local
stuff will probably feel faster almost always unless there is a lot of
load :slight_smile:

I really need to gain a better understanding of the basics of how
everything works. My background is in fine art–not tech. I’ve used
Lynda.com and Sitepoint to learn about front-end development. Beyond
this mailing list, blogs and general googling, I’m not sure what the
best resources are for me to become self-taught and establish a true
understanding of server management. If anyone can make suggestions
about what I should read or watch, I’m all ears.

You’ve done quite an impressive job of picking this stuff up from that
background :slight_smile:

On Thu, Aug 05, 2010 at 12:24:23PM -0400, Alex S. wrote:

varnish relies on OS internals too: it mmap()s a huge file that
may be larger tens times physical memory and perfomance relies on
how OS flushes modified pages to a disk and how then OS reads them
back to memory.

I’m not sure about internals of each project and how they work under
Linux vs FreeBSD servers. This could be a decision reason too.

Both Varnish and nginx are developed on FreeBSD.

Recently, we did a test with serving just static files (from a
FreeBSD8.1
VM), a very small data-set.
nginx0.7 was 1.8 times faster than varnish (both mostly untuned).
So, I’d say that OOTB, just serving static files, nginx wins.
Though, I still think that varnish has a place and there are probably
certain situations where it can beat and will nginx.

Rainer

Am 05.08.2010 um 20:52 schrieb Igor S.:

It’s strange, I can not believe that Varnish may be almost two times
slower on cached responses than nginx on static.

I have very little experience with varnish - so I may have done
something wrong.

Regards,
Rainer

I would say in the long run you’re much better off using one of
Debian/Ubuntu/FreeBsd.

CentOs uses extra memory which could be used for MySql query cache or
php APC.

More MySql query cache makes a big difference to Magento.

On 08/06/2010 03:15 AM, Hone W. wrote:

I would say in the long run you’re much better off using one of
Debian/Ubuntu/FreeBsd.

CentOs uses extra memory which could be used for MySql query cache or php APC.

How exactly does Centos “use extra memory” compared to other
Distributions
or OS’s?

Regards,
Dennis

Best performance you can get is off FreeBSD, just my personal opinion.

CentOS comes with more base packages and services on by default which
causes extra unnecessary memory consumption. Usually around double
the memory of a base Debian system. Of course you can go about
turning the packages/services off in CentOS but to me its easier just
to install the base of a different system and begin from there.

On Friday, August 6, 2010, [email protected] wrote:

Best performance you can get is off FreeBSD, just my personal opinion.

You’ll probably find more people who swear linux is faster in their
opinion.

Opinions shouldn’t enter into it. The first rule of load testing &
tuning is that all changes you make must be fact-based.

  1. record actual traffic patterns with your application, to get
    relative proportions
  2. develop test scripts which mimic those proportions as closely as
    possible. Use JMeter or whatever. Apachebench doesn’t cut it.
  3. run controlled tests using your scripts to increase the user load
    in slow steps
  4. monitor systems, looking for bottlenecks
  5. vary as few parameters as possible to address bottlenecks, then
    repeat tests. One of those parameters could be Linux vs freebsd, but
    I’ll wager the OS won’t matter much. The bottleneck is usually in your
    dynamic pages or database.


RPM

Hi,

Raina G. a écrit :

  1. I tried using Amazon S3 as a cheap CDN, but Varnish was WAY faster.

Of course a local server will be way faster than S3/Cloudfront, but the
results will likely be different for a user on the other side of the
planet because Cloudfront will have a server close to that user.

BTW, you should use cloudfront instead of S3 if you want a CDN:
http://aws.amazon.com/cloudfront/

I really need to gain a better understanding of the basics of how
everything works. My background is in fine art–not tech.
You might want to check these slides from a presentation by Ask Bjørn
Hansen about scaling web services. It helped give me a good overall
understanding of web scalability:

http://develooper.com/talks/rww-mysql-2008.pdf (189 pages, 6MB PDF)

Cheers,
GFK’s

On Mon, Aug 16, 2010 at 9:43 AM, Raina G.
[email protected] wrote:

To date, I’ve been needing to manually re-start PHP-FPM about every
other day due to steadily increasing memory consumption over time. I’m
thinking about implementing a script to auto-restart it upon reaching
a certain threshold. I’m wondering if this is a ridiculously lazy
solution, or a reasonably respectable one.

what’s your pm.max_requests set to?

it’s the normal way to recycle PHP engines after N number of requests
in an attempt to avoid memory leakage over time.

what are you looking at to show/detect memory consumption? top? ps?
free?

note that over time more “free” memory gets thrown into the “cached”
bucket, and that memory is able to be reused, the kernel just doesn’t
mark it as free (at least on Linux, and I believe I summarized it
right)

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs