perkiset

Hello all -

I have two very powerful new multiprocessor boxes going into my cluster. they will simply be LAMP or OBAMP boxes  Applause (

Apache

 , MySQL,

PHP

 Applause - I've heard some compelling arguments that OpenBSD is way cleaner and faster but I'd love some opinions. There won't even be a GUI on these boxes so that is immaterial. They're strictly command line access web service appliances. Is there even a difference between different

linux

  distros when it comes to speed? I don't think so - but I'd love to hear anything you've got.

Let'r rip!

Thanks,
/p

dink

Not an expert here but, don't think the OS will make as much difference as the internals.

ie.  The hard drive speed, the memory capacity and access time, and so on.

<where'd the $.02 smiley go?>

D

perkiset

Applause Moved it to the front of the line d

The

mac

 hines are rocking. all the way down the line - gonna bump the ram a WAY lot (prolly around 16G) and cache my ass off.

I agree, I don't know just how much the OS will affect speed (although prolly some Windows/

OS-X

 /*nix/

Solaris

  arguments could clearly be taken up here...) but what are the other benefits / downsides of these to OS bases in relationship to each other? I've been told that load time on OpenBSD is incredibly quick... well the way I reboot, that'd affect me about once every 3 years  Applause - so that might be cool a bit... perhaps this is just a simple Lutheran versus Methodist sort of thing... not a whole bunch of difference when you break it down... but if that's the case, then why did they choose OpenBSD as the base for

OS-X

 ? Why is

Linux

  so much more popular than OpenBSD? Enquiring minds want to know!

/p

dink

quote
perhaps this is just a simple Lutheran versus Methodist sort of thing...

Subjective.  Biased by who is using which OS for what.

I think that if there were big differences in the various flavors, the folks who push the $*AMP projects would be shouting from the roof tops.

qq.  Do you have to have

Apache

 ?

perkiset

Interesting question - I am curious about lighttpd but I use mod_rewrite pretty significantly. What is your thought?

BTW - the "lighty" thread @ sk8 has me thinking, so I am very open to this line of thought.

dink

Ya.  That's what caused me to ask.  Also might check this one out>

thttpd  http://www.acme.com/software/thttpd/

Configuration: Athlon 700, 800MB RAM. Before:

Apache

 , load=170,

mac

 hine unusable, capped at 4Mbits, SWAPPING. After: thttpd, load=.09 (yes, that's point-zero-nine), happy at 8Mbits, only using ~300MB of RAM.


You didn't specify what the new boxes would be required to do.  That's fine, and none of my biz.  However, if you are going to use one box for a database server (for instance), or for image storage, or (?), then the overhead load from

Apache

  <>may be a factor.

Applause

perkiset

gonna look at that service...

they are both *n[u|i]x flavor

mac

 hine running MySQL and

PHP

  apps. Some really tight

ajax

  responses, some huge dynamic page stuff as usual. Cron jobs as necessary, but predominantly http request delivering

mac

 hines. Of course graphics delivery as well, perhaps some vids.

All of my

mac

 hines are behind an IPCop, but still want to make sure of security issues (buffer overflow attacks and such) against the

mac

 hines via any public service I offer.

I'm wondering as well if SQUID in front then proxied back to

Apache

  et al would be a good fit if my caching is almost entirely graphical...

dink

quote
I'm wondering as well if SQUID in front then proxied back to

Apache

  et al would be a good fit if my caching is almost entirely graphical...


Very likely.

Would the services performed by the boxes be close enough to offer a comparison?  For instance, load one of the boxes up with a full blown OpenBSD, with all the bells and whistles (as required), load the other one with thttpd.

<aside>
If these two screaming

mac

 hines are gonna be housed in your cage there in "Butterfly" county, I'm gonna notify the Sheriff to disregard reports of tires burning and such.  Applause
</aside>

perkiset

quote author=dink link=topic=198.msg1206#msg1206 date=1178909249

Would the services performed by the boxes be close enough to offer a comparison?  For instance, load one of the boxes up with a full blown OpenBSD, with all the bells and whistles (as required), load the other one with thttpd.

unfortunately not

apple

 s-for-

apple

 s, but close enough that I could try it. But since I'm really fine with

Linux

 , I am hoping a BSDboi will come sell me on why I should take the time/headache of getting comfy with anotherOS...

quote author=dink link=topic=198.msg1206#msg1206 date=1178909249

If these two screaming

mac

 hines are gonna be housed in your cage there in "Butterfly" county, I'm gonna notify the Sheriff to disregard reports of tires burning and such.   Applause

lol good plan - they've both got cold air intake, DOHC, blowers and tuned exhaust... I expect delightful things from them.

/p

tobsn

i dont read every post above this buuuut...

openBSD or freeBSD (i would go with freeBSD) are better scalable, take hard loads without giving up and are in fact the better "workers".

for example:
back in 2001 we had a huuuge site on a suse box with a intel cpu and

apache

 /mysql as services. after a time we found out that in the peak times the load goes up and the server gets slow as hell.
a good friend told us to use a sun box with

solaris

 . so we tried freeBSD on

solaris

  because my coworker worked with it since a few years.
and guess what happend? a sun box with a BSD os is freakin fast.

i try to display the results back then in a little graph here...


   

Linux

 
    -----
    |      ********************
    |    *
    |    *
    |  *
    |  *
    | *
    |*
load|__________________________
      time


    freeBSD
    -------
    |
    |    *****
    |    *    *****
    |  *          ***********
    |  *
    | *
    |*
load|__________________________
      time


thats in short what we found out back then...

linux

  takes the load and stays in that high load mode. freeBSD takes the load and tries to optimize... somehow. im not good in OS things but i

learn

 ed from the opinions of my coworkers and friends.

...and all those guys would say "take freeBSD and better take BSD on a SUN box and you're save for years."

same with lighttpd.
i made a similar "graph" for jan (inventor of lighttpd, german like me Applause):

APACHE

  2
========

fast|
    |
    |  ** *** ***  ***  **
    | *  *  *  **  ***  ****
    |*
slow|__________________________
      past                  now



LIGHTTPD
========  * * ** * ***********
          * * *  * *
fast|    *
    |  *
    |  *
    | *
    |*
slow|__________________________
      past                  now


thing is,

apache

  is extremly blown up, has more than a handfull of developers in the back and tries to match all possibilities...
lighttpd on the other site is startet as "how small can a webserver be"-project and has less than a handfull of coders who are not trying to blow up the code - in fact more in the other direction - how to get useless code out of the daemon...

so its not unussual that you get 20-40 requests per second with

apache

  on a normal project and 500 and much more with lighttpd. because lighttpd has some nasty build in tricks to handle huge loads and the

php

 /rewrite stuff.
for example

php

  is included in a fast-cgi container. thats what ppl tell you to do with

apache

  to get more speed out of it.
its default with lighttpd.
same with the mod_rewrite module for lighttpd and everything else...

lighttpd is what i would call the best example for "reduce to the max".

(and its pretty easy to install  :spleefApplause

(sorry for my horrible english hehe.)


(oh and btw. hi, i'm tobias.)

perkiset

man I knew inviting you over here was the ticket  Applause

QQs:
Looking at the lighttpd site I must've missed the mod_rewrite portion... is it the same as

apache

 ? Same code? How is url rewriting handled?

PHP

 : I've never used

php

  in a fast-cgi kind of way - why is this faster than hooking it up with apsx and such?

PHP

  in Fast-cgi: do you know how this affects the APC cache? Is it still available then or would I lose that capability? (BIG drag here)

thanks,
/p

perkiset

Thread mod: I really meant free bsd rather than open bsd I think... I am a bsd n00b but didn't think there's a diff. The little devil seems much cooler than the penguin imo  Applause

/p

perkiset

This is old, but loks like a pretty good raw comparison. The Windows portion is extremely dated, but I think the

Linux

 /FreeBSD columns prolly still apply

http://people.freebsd.org/~murray/bsd_flier.html

nutballs

lol. that windows column makes it sound dire dont it.

Fatty

IMHO the OS does't make as much of a difference as the ability to manage it.  If you're comfortable with

Linux

 , use that.  I wouldn't choose BSD just because some benchmark said it has somewhat better performance.  You're going to have to have a bunch of servers, you want to spend as little time as possible playing sysadmin.  Personally I like RedHat

Linux

 , either Fedora, CentOS, or RH Enterprise.

Separate out the db from the web servers if you can, tune that thing pro

perl

 y, and make sure to start using memcached from the beginning.  The fastest query is one that never touches a database.  If you plan on heavy reads, make sure your application can handle separate read and write handles for databases for when you start replicating.  Don't forget about

PHP

  opcode caching!

Squid is nice as a frontend, at a side job of mine I have squid fronting 6 LAMP boxes and just on static content I get 60% of the load off the backend servers at virtually no CPU expense.

You're going to get your best performance gain by writing a good application, and laying it out pro

perl

 y on the servers.  Make sure the DB is tuned, you pounce on every slow query, and that your configurations are consistent.  Monitoring is also another excellent idea Applause

thedarkness

Vista = lots of

I agree with Fatty both in terms of his weapon of choice (I'm a Red Hat/FC man from way back) and also the fact that an OS change and subsequent steep

learn

 ng curve are not to be taken lightly. "Better the devil you know" within reason. If an OS we're to lag sygnificantly then yes, dump it but let's not forget all of these OS' are in active developement all the time and figures of a bench test done yesterday are not the same as the figures you'll get today. There is enough competition between OS' and distros, and enough hubris amongst the steerers of said entities to make sure that developement is pushed to fairly equivalent levels across the board. Sure, some OS may be faster on one level but an OS is the some of many parts.......

Applause

Cheers,
td

perkiset

quote author=Fatty link=topic=198.msg1225#msg1225 date=1178931587

IMHO the OS does't make as much of a difference as the ability to manage it.  If you're comfortable with

Linux

 , use that.  I wouldn't choose BSD just because some benchmark said it has somewhat better performance.  You're going to have to have a bunch of servers, you want to spend as little time as possible playing sysadmin.  Personally I like RedHat

Linux

 , either Fedora, CentOS, or RH Enterprise.

Pretty durn true, but I am always on the watch to see if it's time to move. That's what took me out of DOS to Windows, Windows to

Linux

  (and then sidelined to

Solaris

  also) and I am now interested to see if it is appropriate to bring another OS into the house. I'm very willing to evolve if my current toolsets are underpar - I have never been one to shirk wholesale re

learn

 ing  if the bang-for-buck is a good ratio.

quote author=Fatty link=topic=198.msg1225#msg1225 date=1178931587

Separate out the db from the web servers if you can, tune that thing pro

perl

 y, and make sure to start using memcached from the beginning.  The fastest query is one that never touches a database.  If you plan on heavy reads, make sure your application can handle separate read and write handles for databases for when you start replicating.  Don't forget about

PHP

  opcode caching!

@ DB out: Normally would. These

mac

 himes need to be standalone that can be moved to another cage autonomously.
@ memcache: I have not taken the time to see if there are queries that make sense to do this - I know it's there but haven't rethunk the DB to work this way. You're right, it needs to be analyzed.
@ OpcodeCaching: Are you kidding me? I'm Mr. APC! Changed my

PHP

  life!

quote author=Fatty link=topic=198.msg1225#msg1225 date=1178931587

Squid is nice as a frontend, at a side job of mine I have squid fronting 6 LAMP boxes and just on static content I get 60% of the load off the backend servers at virtually no CPU expense.

I'd REALLY appreciate a little of your time (post here so others can benefit) on what a config like that looks like. I am toying with lighttpd, squid and a bunch of others on the hunt for the new shape of my essential web service configuration. Please sell me. Pictures are good  Applause

quote author=Fatty link=topic=198.msg1225#msg1225 date=1178931587

You're going to get your best performance gain by writing a good application, and laying it out pro

perl

 y on the servers.  Make sure the DB is tuned, you pounce on every slow query, and that your configurations are consistent.  Monitoring is also another excellent idea Applause

You're my kind of guy. Bet you and I'd have a hella time in a race towards the most efficient systems...

thanks F,
/p

perkiset

quote author=thedarkness link=topic=198.msg1228#msg1228 date=1178932821

I agree with Fatty both in terms of his weapon of choice (I'm a Red Hat/FC man from way back) and also the fact that an OS change and subsequent steep

learn

 ng curve are not to be taken lightly. "Better the devil you know" within reason.


Again agree, within reason - it is also important to identify when it's time to get aquainted with a new devil. Ergo, my goal here.

I know you're just watching out for my P&L though td...  Applause

/p

dink

Wow.  Glad some of the pro's showed up.  Very good thread.

Fatty

quote author=perkiset link=topic=198.msg1229#msg1229 date=1178932961

@ OpcodeCaching: Are you kidding me? I'm Mr. APC! Changed my

PHP

  life!


I've been using eAccelerator...  I tried APC on one of our nodes last week and it worked just as well until the cache filled up and then it completely crapped out.  I found a known bug in the

php

  database that was similar, it doesn't sound like it's going to get fixed soon.  Applause The management interface is a lot nicer and the tuning values make a lot more sense.  Plus, some apps will store data in APC in addition to the opcode caching.

quote author=perkiset

I'd REALLY appreciate a little of your time (post here so others can benefit) on what a config like that looks like. I am toying with lighttpd, squid and a bunch of others on the hunt for the new shape of my essential web service configuration. Please sell me. Pictures are good  Applause


This is a 2.6 config...  It's a bit more complicated than necessary because I bind squid to the outside interface and

apache

  to the inside so that I can also serve pages off the squid box. We also have a lot of IPs to bind to because the load balancer does direct server return instead of a dnat.  I've stripped out most of the logging and management stuff and left just the accelerator basics.

# I use one of these per external IP address x.x.x.x
# a.a.a.a is the address of the web server itself so that any non-domain queries are handled
http_port x.x.x.x:80 vhost defaultsite=a.a.a.a
# allow for vhosting
redirect_rewrites_host_header off
# one cache_peer per backend server...  Squid does some healthchecks too
cache_peer y.y.y.y parent 80 0 no-query originserver monitorurl=/monitor.

php

  monitorinterval=15 round-robin login=PASS  no-digest
# Basic tuning
icp_port 0  # Disable
cache_mem 512 MB
cache_dir ufs /var/cache/squid/ 600 16 256
peer_connect_timeout 3 seconds

# refresh_patterns dictate what gets cached and for how long (depending on headers, too)
# here's the rule for CSS files, cache aggressively
refresh_pattern -i      .css$  900 150% 7200  reload-into-ims override-lastmod
# default is not to cache here, but you can do whatever you want
refresh_pattern        .      0 0% 1

# increase max file descriptors...  you also need to make sure you have enough descriptors available at compile time, otherwise you end up with 1024 which is not enough for peak times...  10K is a safe value
max_filedesc 10000



quote author=perkiset

You're my kind of guy. Bet you and I'd have a hella time in a race towards the most efficient systems...


Applause  Yea I like this kind of stuff.  Just wish I had more time in a day.

Fatty

perkiset

quote author=Fatty link=topic=198.msg1256#msg1256 date=1178979688

I've been using eAccelerator...  I tried APC on one of our nodes last week and it worked just as well until the cache filled up and then it completely crapped out.  I found a known bug in the

php

  database that was similar, it doesn't sound like it's going to get fixed soon.  Applause The  Applause interface is a lot nicer and the tuning values make a lot more sense.  Plus, some apps will store data in APC in addition to the opcode caching.

I've had trouble with eA on 64b systems... did you modify the apc cache size in the

php

 .ini/ Common problem for me when I fire up a new box and forget to modify that... it's default is rather small to my thinking...


quote author=Fatty link=topic=198.msg1256#msg1256 date=1178979688

This is a 2.6 config...  It's a bit more complicated than necessary because I bind squid to the outside interface and

apache

  to the inside so that I can also serve pages off the squid box.

Actually I'd really like it if talked a bit more from an overview perspective about how to get the two working together efficiently ( or even at alll...). Honestly the config doesn't mean a bunch to me because I'm not a squid guy yet. Would you be willing to post a sort of "How To" here or in another thread? I think that would be of monumental help to me as well as a bunch of the other guys...

/p

thedarkness

Fatty: What does monitor.

php

  do?

Also, your using squid basically as a caching gateway to your backend server right? I'm intrigued by this.

It's not obvious to me how the config you posted maps an external request to a "behind the cache" server. Could you moronify it a bit for me?

Cheers,
td

Fatty

quote author=perkiset link=topic=198.msg1263#msg1263 date=1178993483

I've had trouble with eA on 64b systems... did you modify the apc cache size in the

php

 .ini/ Common problem for me when I fire up a new box and forget to modify that... it's default is rather small to my thinking...


I had it up to a gig....  It was complaining about fcntl errors. 

quote author=perkiset link=topic=198.msg1263#msg1263 date=1178993483

Actually I'd really like it if talked a bit more from an overview perspective about how to get the two working together efficiently ( or even at alll...). Honestly the config doesn't mean a bunch to me because I'm not a squid guy yet. Would you be willing to post a sort of "How To" here or in another thread? I think that would be of monumental help to me as well as a bunch of the other guys...


TBH there's not much to it.  The general idea is that squid accepts all the connections from users.  If the request can't be served from the squid cache, squid makes a second connection to one of a defined list of backend servers, and returns the content to the client (such that the backend server always sees connections coming from squid, not the user).  Depending on the HTTP headers and the squid config, the data may be cached.

To answer other questions, the monitor.

php

  just returns "hello world", so that the squid cache knows the server is alive.  It is the originserver keyword that tells squid that all requests for data should go to the backend servers rather than the Inte

rnet

  (as it would if it were a regular outbound cache).  If a cache_peer is defined as an originserver, squid becomes a reverse proxy and sends all the data there.  The round-robin keyword allows for the balancing of connections across the backend servers.

You can try squid yourself on a single server.  Bind httpd to the loopback interface in httpd.conf by getting rid of the existing Listen directive


# Listen 80  don't need this anymore
Listen 127.0.0.1:80


And give a basic squid config binding itself to the outside address with your httpd instance as the originserver:


http_port 192.168.1.1:80 vhost
redirect_rewrites_host_header off
cache_peer 127.0.0.1 parent 80 0 no-query originserver
icp_port 0  # Disable
cache_dir ufs /var/cache/squid/ 600 16 256
# allow everyone to request
acl all src 0/0
http_access allow all
access_log /var/log/squid/access_log
cache_log /var/log/squid/cache_log


So the requests will come to the outside address, squid will send them all to the backend server which is bound to the loopback and return it to squid, who caches it and returns it to the client.  Then you tune your server for caching with rewrite_patterns and no_cache rules according to your application.

From there you add more backend servers just by adding more cache_peer lines.

Other advantages are that squid is way more efficient at sending data to slow clients, so

Apache

  is able to serve the request to squid very quickly, who buffers the data to send to the client.  That way slow clients don't tie up expensive httpd slots (if you just want this, and don't need caching,

perl

 bal is another option)

Fatty

perkiset

This sounds really strong. I have one of the boxes sitting beside me right now and I'm just starting to liven it up. I'm thinking now of going OpenBSD, squid in front, lighttd in back and enough APC to support it. I'm going to also consider where memcached might live in this framework for minimizing DB hits as well...

quote author=Fatty link=topic=198.msg1356#msg1356 date=1179154980

From there you add more backend servers just by adding more cache_peer lines.

Are you insinuating load balancing here?

Fatty

quote author=perkiset link=topic=198.msg1361#msg1361 date=1179158824

Are you insinuating load balancing here?


Yes, with the round-robin keyword on the cache_peer line it will cycle through all active peers.

Fatty

perkiset

Fatty -

I just posted over at the IPCop forums, but do you have any experience running squid on an IPCop box?

Fatty

quote author=perkiset link=topic=198.msg1368#msg1368 date=1179164056

I just posted over at the IPCop forums, but do you have any experience running squid on an IPCop box?


No, just RedHat & Fedora.

perkiset

They were pretty clear that I should NOT put squid on an IPCop box, instead running it behind the wall.
Thanks anyway on that one...

I'll be studying this pretty hard as I into production on it - thanks for your help fatty

/p

perkiset

OK so I post at the lighty forum (lighhtpd) yesterday and today I can't connect to the server (it's running on lighhtpd) ... prolly not a good sign...  Applause


Perkiset's Place Home   Politics @ Perkiset's