[KyOSS Discuss] Topic Requests For next Meeting

alan blount alan at zeroasterisk.com
Thu Oct 10 14:36:55 EDT 2013


I'll take the pepsi challenge comparing Nginx+PHP-FPM and Apache+PHP any
day -- it's a no-contest battle with Nginx + PHP-FPM the clear winner.

Setup is very well covered in several walkthroughs -- here are a couple of
top hits:
http://www.howtoforge.com/installing-nginx-with-php5-and-php-fpm-and-mysql-support-on-ubuntu-11.10
http://www.howtoforge.com/installing-nginx-with-php5-and-php-fpm-and-mysql-support-on-centos-6.4
(search for your OS + needs)

As for PHP extensions, you have to have:
suhosin

You should have:
mcrypt
curl
gd
xdebug (in development only, NOT in production)
...

I highly recommend some sort of php compiled cacher (pick one):
xcache
apc
eaccelerator

You're welcome to review my phpinfo for a development/qa server at my work:
http://ahm:billrocks@upgrade.physicaltherapy.com/phpinfo.php

As for MySQL customizations, it's very dependant on the needs of your
applications and the capabilities of your server.  MySQL comes with a
handful of "preset" my.cnf files... I almost always copy the example named
"huge" in place, and the level of tweaking I have to do is minimal... I've
done some, but not a ton...

If you have PHPmyadmin running, you can go to [Status] [Advisor] and it
will give you tuning recommendations.

There are some other Perl and other scripts out there for MySQL tuning...
but I suspect the basics will be most of what you need unless you're under
very heavy load or an edge case.

NOTE: all MySQL tuning recommendations require that the server's been
running under normal load for a while (the longer the better)

--------------------------

As for what not to do... don't mess with it.  Once you get it up and
running, modify only essentials....

Always have a development environment which mirrors your production, even
if it's just a VM you run locally (Virtualbox FTW).  Ideally you should be
able to snapshot your server, and make changes... you can always revert to
the snapshot.

Do you have many servers? (like more than 2?) -- if you do, it might
behoove you to learn Puppet or Chef or Salt or any of the server management
suites... programming your installs/configs is very useful if you have to
do a lot of it.





Thanks,
-alan


On Thu, Oct 10, 2013 at 1:56 PM, Christopher Simmons <
chrissimmons2 at gmail.com> wrote:

> Thanks Chris, I meant to include that as well, although I wasn't aware of
> any other http servers.  I knew there had to be at least a few but Apache
> is all I know.
>
>
> On Thu, Oct 10, 2013 at 1:53 PM, Chris Rockwell <chris at chrisrockwell.com>wrote:
>
>> This sounds like a great idea, but maybe some more structured
>> presentations on a particular sub-topic (even if only a few minutes) would
>> be a good catalyst for group discussion.
>>
>> In addtion, I would love to hear more about other (http) servers.  Alan
>> has brought up Nginx several times, and I'm convinced I should set it up on
>> a testing server to see how our applications run on it (Drupal, static
>> sites, SugarCRM) - if we could discuss the pros/cons of different http
>> servers, that'd be cool as well.
>>
>>
>>
>>
>> On Thu, Oct 10, 2013 at 1:41 PM, Christopher Simmons <
>> chrissimmons2 at gmail.com> wrote:
>>
>>> I would like to preface this email by apologizing for any incorrect use
>>> of terminology or concepts that I mention.  I'm still learning the Linux
>>> platform and do not claim to be an expert on any of these topics.
>>>
>>> As someone that is less in the application development world and more in
>>> the systems world, I'd like to propose a couple of topics for the next
>>> meeting.  Being that I primarily in the Windows world, we do have some
>>> Linux customers that require assistance with their LAMP Configurations.
>>>  Over the last couple of years I've gotten pretty comfortable working on
>>> Redhat / CentOS servers.  However, I struggle with optimization concepts
>>> that should be applied within the LAMP stack.  I would like to request an
>>> open discussion and/or presentation regarding "LAMP Server Optimization."
>>>
>>> A few questions that I would like to see answered are:
>>>
>>> *Linux Questions:*
>>> Why RPM / .Deb?  Which do you prefer and why?
>>>
>>> We primarily use Redhat because of the Enterprise Support.  We use
>>> CentOS because it is so similar to Redhat and are already familiar with it.
>>>  We do have some ubuntu and SuSe servers as well but the majority of our
>>> *nix platforms are RPM based.  What (if any) benefits are there for running
>>> one over the other?
>>>
>>> What are some other preferred distributions for operating a *nix Server?
>>>  Why?
>>>
>>> *Apache Questions:*
>>> What modules and configuration changes should be made when deploying
>>> Apache?  Is the default configuration a good place to start?  What can be
>>> done to make it better?
>>>
>>> *MySQL (or other DB) Questions:*
>>> What standard modifications should be made the my.cnf file when
>>> installing MySQL Server?  When is it a good idea to combine Apache and
>>> MySQL roles on the same server, when is it a good idea to separate the
>>> roles on different servers?
>>>
>>> Do you recommend using MySQL, or prefer another database server?
>>>  Benefits of one over the other?
>>>
>>> *PHP (and other programming) Questions:*
>>> What PHP (or other programming) related packages should be installed on
>>> a standard build? Ex. php-mcrypt, php-common, etc..  What do these packages
>>> do?  Why are they recommended for a standard build.
>>>
>>> My goal is to improve upon the product that we hand over to a customer
>>> when they purchase a managed Linux environment.  The more work we can take
>>> of their hands for the build out, the higher their perceived value will be
>>> of our product.
>>>
>>> *Linux Sys Admin Toolbox:*
>>> What tools do you rely on when managing your server environment?  Why
>>> are they valuable?
>>>
>>> Finally, are there any tools, concepts, or ideologies related to running
>>> a LAMP server that you recommend avoiding?  What should I not do that might
>>> sound like a good idea but is just BAD?
>>>
>>> While presentations would be nice, I think this might serve well as an
>>> open forum discussion as well as this covers tons of areas and the more
>>> user input received the better!
>>>
>>> Sorry for the long email but as you can see I have a lot of questions
>>> and researching each one individually sends me in a thousand different
>>> directions.  Opinions are great but having real world experience to back
>>> them up is even better.  Please let me know if something in the paragraphs
>>> above need more clarification.
>>>
>>> Thanks,
>>> --
>>> Thanks,
>>> Christopher Simmons
>>>
>>> _______________________________________________
>>> KyOSS-Discuss mailing list
>>> KyOSS-Discuss at kyoss.org
>>> Subscribe by sending email to kyoss-discuss-subscribe at kyoss.org
>>> Unsubscribe by sending email (from the address you wish to unsubscribe)
>>> to kyoss-discuss-unsubscribe at kyoss.org
>>> Difficulty unsubscribing? Check your email headers for originally-to
>>> address in case you are forwarding your mail.
>>> More options at http://kyoss.org/cgi-bin/mailman/listinfo/kyoss-discuss
>>>
>>
>>
>>
>> --
>> Chris Rockwell
>>
>> _______________________________________________
>> KyOSS-Discuss mailing list
>> KyOSS-Discuss at kyoss.org
>> Subscribe by sending email to kyoss-discuss-subscribe at kyoss.org
>> Unsubscribe by sending email (from the address you wish to unsubscribe)
>> to kyoss-discuss-unsubscribe at kyoss.org
>> Difficulty unsubscribing? Check your email headers for originally-to
>> address in case you are forwarding your mail.
>> More options at http://kyoss.org/cgi-bin/mailman/listinfo/kyoss-discuss
>>
>
>
>
> --
>  Thanks,
> Christopher Simmons
>
> _______________________________________________
> KyOSS-Discuss mailing list
> KyOSS-Discuss at kyoss.org
> Subscribe by sending email to kyoss-discuss-subscribe at kyoss.org
> Unsubscribe by sending email (from the address you wish to unsubscribe) to
> kyoss-discuss-unsubscribe at kyoss.org
> Difficulty unsubscribing? Check your email headers for originally-to
> address in case you are forwarding your mail.
> More options at http://kyoss.org/cgi-bin/mailman/listinfo/kyoss-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kyoss.org/pipermail/kyoss-discuss/attachments/20131010/702c97aa/attachment.html>


More information about the KyOSS-Discuss mailing list