You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2014/11/20 23:00:39 UTC
commercial support
It's a shame that there isn't a company like Covalent
around anymore that focuses on the Apache httpd web-server.
nginx.com shows kinda clearly that having a motivated
company behind a web-server helps grab market share and
market awareness (they can continue to beat the drum about
how fast and reliable they are, when so many benchmarks
lately show that 2.4 is just as fast if not faster in
actual response time, but we have limited ability to
do that, and most reporters see us as Old "news" and
nginx as the new hotness anyway)...
So who wants to get together and create a company
around httpd? :)
Honestly though, how much of the uptake in nginx
do people think is actually due to nginx being "better"
or the "best" choice, and how much do you think is
due simply because it's *seen* as better or that we
are seen as old and tired?
This is our 20year anniversary... It would be cool
to use that to remind people! :)
Re: commercial support
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Nov 21, 2014 at 9:21 AM, Victor J. Orlikowski <
victor.j.orlikowski@alumni.duke.edu> wrote:
> On Nov 21, 2014, at 9:01 AM, Jeff Trawick <tr...@gmail.com> wrote:
>
>
> * oh, and make it possible for 90% of the potential user base to be
> running 2.4.latest in several minutes without possibly interfering with
> existing software; user guide material (above) must support having the
> user's own application deployed behind httpd a few minutes later
>
>
> The “new hotness” making something like this possible, on Linux and OS X
> at least, is Docker.
> Here’s the Dockerfile in github:
> https://github.com/docker-library/docs/tree/master/httpd
>
> The “deploy X application, according to how the developers spelled it out,
> isolated from host OS environment” scenario has been pretty much captured
> and owned by the Docker folks; they’ve done a masterful job of it.
>
Cool stuff. I can see the "Here's my application, give me a Docker file
that runs it using httpd-latest." path being very easy on the user with
Docker and relatively easy on the binary provider. (Unfortunately I don't
know nearly enough about the way Docker can be used to understand all the
implications for the user around software upgrades and managing their
configurations and applications.)
>
> Best,
> Victor
> --
> Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: commercial support
Posted by "Victor J. Orlikowski" <vi...@alumni.duke.edu>.
On Nov 23, 2014, at 10:10 AM, Issac Goldstand <ma...@beamartyr.net> wrote:
>
> Again, you're focusing on the packages, but not on configuration
> changes, which I think is what Jeff was trying to point out to begin
> with. I'm pretty sure that there's even a .spec file somewhere that the
> project used to maintain, and possibly still does.
>
> The package upgrade is easy, but non-backwards-compatible changes, like
> the historic ones between 1.3 and 2.0, and the recent ones between
> 2.0/2.2 and 2.4 are the hard part.
So - that’s been my focus, if only because Jeff mentioned the idea of wanting to get a new user up-to-speed quickly with 2.4, and mentioned earlier the issues of running into pre-installed headers, etc. being a source of pain and spurious bug reports.
I will *absolutely* agree with you about the configuration changes, as I’ve had folks working with me run head on into them.
Perhaps a tool to scan an existing configuration (single file or directory structure) and flag potential problems is in order?
Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
Re: commercial support
Posted by Issac Goldstand <ma...@beamartyr.net>.
On 11/23/2014 4:53 PM, Victor J. Orlikowski wrote:
> On Nov 23, 2014, at 8:11 AM, Jeff Trawick <trawick@gmail.com
> <ma...@gmail.com>> wrote:
>>
>> Docker would not be the right solution for someone who wants to use
>> httpd over the long haul (future updates to httpd+libs while maintain
>> existing config, etc.); beyond the complication of container layers to
>> manage this properly, these folks should have packaging that's managed
>> like other software on their system so that they don't have to learn
>> any new concepts
>
> Hrm.
>
> To my mind, at least on RPM-based distributions, that sounds like a set
> of prefixed RPM packages, that install into a non-default system
> location, and that can be built from APR-Util/APR/httpd source trees.
>
> To be a bit more specific: a buildrpm.sh that takes a templated spec
> file, does the needed configure and make, and drops out a set of
> packages that would install things under /opt/local.
>
> That about sound about right, Jeff?
>
Again, you're focusing on the packages, but not on configuration
changes, which I think is what Jeff was trying to point out to begin
with. I'm pretty sure that there's even a .spec file somewhere that the
project used to maintain, and possibly still does.
The package upgrade is easy, but non-backwards-compatible changes, like
the historic ones between 1.3 and 2.0, and the recent ones between
2.0/2.2 and 2.4 are the hard part.
Re: commercial support
Posted by "Victor J. Orlikowski" <vi...@alumni.duke.edu>.
On Nov 23, 2014, at 10:07 AM, Eric Covener <co...@gmail.com> wrote:
>
> I'm not sure there's much value in this going forward (as opposed to
> say 18 months ago) compared to say the doc or evangelism efforts
> advocated in Jeff's other thread.
Agreed, though I’d say that the true havoc has been in migrating configs from pre-2.4 to 2.4.
Perhaps *especially* when the Linux vendor bundling httpd changes versions, as the end user isn’t expecting it.
My personal experience with this has to do with the VM images we’ve been producing at my current gig; there’s a tutorial that makes use of httpd, and the unexpected change in the authz syntax caused a 1 day loss of time for the person who manages the tutorial.
If she’d reached out to me earlier, I could have saved her the time - but…that’s unrelated to the point.
Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
Re: commercial support
Posted by Graham Dumpleton <gr...@apache.org>.
On 24 November 2014 at 04:59, Jeff Trawick <tr...@gmail.com> wrote:
>
> If you're doing Python web apps it would be cool to "pip install httpd
> FRAMEWORK-httpd-wiring" and have a command that wires it up based on
> framework settings and a bit of other declarative configuration. (similar
> for other ecosystems with a packaging/build infrastructure) mod_wsgi
> actually has a version in PyPI that works like this, although it doesn't
> bring httpd with it.
>
Downloading and compiling the whole of httpd as a side effect of doing a
Python pip install isn't really practical. The process would just take too
long for a start, plus it doesn't solve the problem that many systems will
not have the dependencies installed in order to compile it. You don't want
to have to also be separately downloading and compiling APR, APU-UTIL and
PCRE now that they aren't bundled with the Apache source code.
I have tried going that path, albeit not triggered by pip, in trying to
create a build pack for Heroku which could be used to bring mod_wsgi to
that PaaS and it was a right pain, especially since the resulting size of
all the compiled components would chew up a significant part of the image
slug allowance that Heroku gave you. In the end I gave up on it because it
was so customised and unsupported by Heroku that no one would be likely to
use it.
So for the pip installable mod_wsgi it does at least rely on you having
httpd and the httpd-dev packages, plus any dependencies for those installed.
This still doesn't help with PaaS services which have such a narrow view of
what they want to allow you to do. For example, Heroku will not provide the
httpd and httpd-dev packages in the operating system image they use to
allow people to run it using their own custom configurations and compile
and use their own Apache modules. It even took me a couple of years at
least to get Heroku to update their Python installations so they provided
shared libraries and so allow any sort of dynamically loaded embedded
system such as the mod_wsgi module inside of Apache to be able to use their
Python installations. Before that I would have to also compile Python
source code from scratch as well.
Heroku isn't the only PaaS who has gone down a path which makes it near on
impossible to use them with Apache and a customised setup. OpenShift does
actually provide an Apache/Python/mod_wsgi cartridge, but they hardwire the
Apache configuration and you cannot change it. The particular configuration
actually has various problems in the way it is done and so provides a sub
optimal experience. They also use a very old mod_wsgi version which RHEL
version they use ships. Even if you could get around that you can't change
the Apache configuration and not even the startup command, it isn't even
possible to build an Apache module from scratch as they don't install the
httpd-dev package for RHEL.
The only PaaS where I could do what I want and use the pip installable
mod_wsgi was dotcloud. This as because it was what became docker and so
allowed a user to install the missing httpd-dev package in your own space
and so it was possible to then actually compile custom Apache modules.
So for me and turning around the rapid decline in mod_wsgi usage caused by
the narrow options most PaaS providers give you, docker is definitely the
way forward.
The idea of a pip installable mod_wsgi is therefore two fold.
The first is to work around the fact that Linux distributions ship very out
of date versions of packages. Most Linux distributions are over a dozen
releases behind on mod_wsgi.
The second is that the pip installable mod_wsgi does more than just compile
the mod_wsgi Apache module. It also installs a script called
mod_wsgi-express that automatically generates an Apache configuration for
you which is setup properly for mod_wsgi. This is what Jeff is alluding to
in saying 'a command that wires it up based on framework settings and a bit
of other declarative configuration'.
This solves another serious problem that mod_wsgi has had over the years.
That is that the default Apache configuration isn't particularly
appropriate. This is especially the case for prefork MPM where Python code
is run in embedded mode inside of the Apache child work process rather than
in mod_wsgi daemon mode, whereby the Python code runs in separate
processes. This isn't aided by what I would argue as being a somewhat
flawed child worker dynamic scaling algorithm in Apache which causes too
much process churn, negatively affecting embedded systems which have a
large startup cost.
So what mod_wsgi-express does is provide a turn key solution for setting up
Apache with Python as a form of appliance which is going to suit the
majority of cases where users are just running a single Python web
application. I can take all the knowledge I have accumulated over the years
as to what is the best way of setting up Apache for Python web applications
to avoid problems and distil that in a custom streamlined Apache
configuration, that even though it can still require some minor tuning to
match your specific Python web application, does all the core setup that
most people wouldn't even do for Python.
To that end I am trying to combat the perception that Apache is slow and
bloated for Python web applications, when in fact it is usually because
they are using an old Apache and never set it up properly, by providing a
best of class configuration for that use case.
Where does docker fit into this?
For mod_wsgi at least, docker means I can provide my own base docker image
which has Apache 2.4 and latest mod_wsgi version installed. A user would
then simply create their own docker image deriving from that, which adds in
their Python web application code. For the simplest case, using some of the
ONBUILD features of docker, the Dockerfile for their project could be one
line. Add a second line if they want to override the number of
processes/threads used for the Python web application to deal with whatever
throughput requirement they have. The mod_wsgi-express script will deal
with everything else for them when generating the configuration.
My view of how perhaps docker should be harnessed, is therefore not to try
and provide one docker image for Apache that just gives you a generic
Apache configuration and then you just leave it all up to the user as has
been done in the past. Instead create specialised docker images for using
Apache in certain roles. Provide a much more minimal interface for
customising the configuration where the build of the Apache configuration
is generated by a script which has been written by someone who actually
understands how to setup Apache for that use case and so streamline it and
make it run at its best for that narrow use case that that docker image
using Apache was intended for.
I am not actually far off being able to offer this docker appliance image
for mod_wsgi and Python web applications. Mostly a case of just finding the
time to work out all the requirements to get it up on the docker hub. Am
also trying to sort out issues with the official docker Python image, which
like Heroku has made the mistake of not shipping shared libraries. So right
now I can't base off their image. The other option was to base it odd the
official docker image for httpd. For that image though, they have made it
useless to people who want to use it as the base for when building other
Apache modules as they strip out at the end all the dependencies that were
originally required to actually build Apache and any additional modules.
These latter issues with the official docker images for both httpd and
Python shows another problem, quite similar to some of the things I have
seen with PaaS providers. That is that the people implementing those
systems aren't strong Apache users themselves. They therefore create
systems which they think are going to be suitable for a wide range of use
cases, where as in fact they are only suitable for very narrow use cases
and perform poorly in other cases. We need to do a better job of
highlighting that such solutions aren't actually workable and explain why.
If we don't say anything, then they aren't changed and people continue to
have a bad experience of using Apache when it isn't Apache's fault but how
the provider set it up.
Anyway, enough rambling.
Graham
Re: commercial support
Posted by Jeff Trawick <tr...@gmail.com>.
On Sun, Nov 23, 2014 at 10:07 AM, Eric Covener <co...@gmail.com> wrote:
> On Sun, Nov 23, 2014 at 9:53 AM, Victor J. Orlikowski
> <vi...@alumni.duke.edu> wrote:
> > To my mind, at least on RPM-based distributions, that sounds like a set
> of
> > prefixed RPM packages, that install into a non-default system location,
> and
> > that can be built from APR-Util/APR/httpd source trees.
> >
> > To be a bit more specific: a buildrpm.sh that takes a templated spec
> file,
> > does the needed configure and make, and drops out a set of packages that
> > would install things under /opt/local.
> >
> > That about sound about right, Jeff?
>
Yeah; the existing RPMs for httpd, apr, and apr-util template-ized to be
able to install elsewhere and not be part of the system packages is an
actual (but partial) solution I was thinking of as a way to make it easy
for some class of users.
> I'm not sure there's much value in this going forward (as opposed to
> say 18 months ago) compared to say the doc or evangelism efforts
> advocated in Jeff's other thread.
>
> * The 2014 releases of RedHat, SLES, and Ubuntu have 2.4.
> * There are already options for older RHEL (epel, although it doesn't
> seem to be servied & RedHat Software Collections) and older Ubuntu (at
> least 1 PPA)
> * Users who can't avail of these, or the source itself, are unlikely
> to move to some even more unusual way to get httpd
>
One thing to keep in mind about these is that the level of 2.4 will get
older and older and the default configuration differs significantly between
them. This doesn't support goals like the following:
* actually fix/improve issues in the code and have users able to make use
of that on your timeframe, which in turn allows you to provide how-to
guides that don't have to pretend that, for example, mod_proxy only works
with TCP sockets, since probably none of the distros above have a new
enough httpd
* providing how-to guides that aren't cluttered up with distro-specific
configuration layout
--/--
At Sun we had a relocatable distribution of httpd and friends based on
something like yum or apt; it was trivial for users to bootstrap and
install packages and keep updated, and applicable for use by root and
non-root alike. (There was also a system package distribution.) The
relocatable distribution was perfect for casual use (really just a couple
of minutes to get running) that can evolve into a permanently maintained
install. Also, there was no inherent reason why any modern OS couldn't be
supported.
--/--
If you're doing Python web apps it would be cool to "pip install httpd
FRAMEWORK-httpd-wiring" and have a command that wires it up based on
framework settings and a bit of other declarative configuration. (similar
for other ecosystems with a packaging/build infrastructure) mod_wsgi
actually has a version in PyPI that works like this, although it doesn't
bring httpd with it.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: commercial support
Posted by Eric Covener <co...@gmail.com>.
On Sun, Nov 23, 2014 at 9:53 AM, Victor J. Orlikowski
<vi...@alumni.duke.edu> wrote:
> To my mind, at least on RPM-based distributions, that sounds like a set of
> prefixed RPM packages, that install into a non-default system location, and
> that can be built from APR-Util/APR/httpd source trees.
>
> To be a bit more specific: a buildrpm.sh that takes a templated spec file,
> does the needed configure and make, and drops out a set of packages that
> would install things under /opt/local.
>
> That about sound about right, Jeff?
I'm not sure there's much value in this going forward (as opposed to
say 18 months ago) compared to say the doc or evangelism efforts
advocated in Jeff's other thread.
* The 2014 releases of RedHat, SLES, and Ubuntu have 2.4.
* There are already options for older RHEL (epel, although it doesn't
seem to be servied & RedHat Software Collections) and older Ubuntu (at
least 1 PPA)
* Users who can't avail of these, or the source itself, are unlikely
to move to some even more unusual way to get httpd
--
Eric Covener
covener@gmail.com
Re: commercial support
Posted by "Victor J. Orlikowski" <vi...@alumni.duke.edu>.
On Nov 23, 2014, at 8:11 AM, Jeff Trawick <tr...@gmail.com> wrote:
>
> Docker would not be the right solution for someone who wants to use httpd over the long haul (future updates to httpd+libs while maintain existing config, etc.); beyond the complication of container layers to manage this properly, these folks should have packaging that's managed like other software on their system so that they don't have to learn any new concepts
Hrm.
To my mind, at least on RPM-based distributions, that sounds like a set of prefixed RPM packages, that install into a non-default system location, and that can be built from APR-Util/APR/httpd source trees.
To be a bit more specific: a buildrpm.sh that takes a templated spec file, does the needed configure and make, and drops out a set of packages that would install things under /opt/local.
That about sound about right, Jeff?
Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
Re: commercial support
Posted by Jeff Trawick <tr...@gmail.com>.
On Sun, Nov 23, 2014 at 2:48 AM, Issac Goldstand <ma...@beamartyr.net>
wrote:
>
>
> On 11/21/2014 4:21 PM, Victor J. Orlikowski wrote:
> > On Nov 21, 2014, at 9:01 AM, Jeff Trawick <trawick@gmail.com
> > <ma...@gmail.com>> wrote:
> >>
> >> * oh, and make it possible for 90% of the potential user base to be
> >> running 2.4.latest in several minutes without possibly interfering
> >> with existing software; user guide material (above) must support
> >> having the user's own application deployed behind httpd a few minutes
> >> later
> >>
> >
> > The “new hotness” making something like this possible, on Linux and OS X
> > at least, is Docker.
> > Here’s the Dockerfile in github:
> > https://github.com/docker-library/docs/tree/master/httpd
> >
> > The “deploy X application, according to how the developers spelled it
> > out, isolated from host OS environment” scenario has been pretty much
> > captured and owned by the Docker folks; they’ve done a masterful job of
> it.
>
> Docker is awesome for "get started fast" (as are Chef & Puppet) with
> best-practices, but none of those 3 solutions really deal with how to
> migrate an existing pre-2.4 config to 2.4, which I think was the point
> Jeff was trying to make.
>
> I have to admit, even given my involvement in the project, I personally
> still cringe a bit every time I need to do that upgrade.
>
I wasn't referring to an upgrade to 2.4. Here's a little more of what I
was thinking about potential users that aren't prepared to manage Docker
images themselves:
* Docker could be a good way to give somebody a way to kick the tires with
2.4, hopefully with their app wired in automatically
* Docker would not be the right solution for someone who wants to use httpd
over the long haul (future updates to httpd+libs while maintain existing
config, etc.); beyond the complication of container layers to manage this
properly, these folks should have packaging that's managed like other
software on their system so that they don't have to learn any new concepts
>
> >
> > Best,
> > Victor
> > --
> > Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
> > <ma...@alumni.duke.edu>
> >
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: commercial support
Posted by Issac Goldstand <ma...@beamartyr.net>.
On 11/21/2014 4:21 PM, Victor J. Orlikowski wrote:
> On Nov 21, 2014, at 9:01 AM, Jeff Trawick <trawick@gmail.com
> <ma...@gmail.com>> wrote:
>>
>> * oh, and make it possible for 90% of the potential user base to be
>> running 2.4.latest in several minutes without possibly interfering
>> with existing software; user guide material (above) must support
>> having the user's own application deployed behind httpd a few minutes
>> later
>>
>
> The “new hotness” making something like this possible, on Linux and OS X
> at least, is Docker.
> Here’s the Dockerfile in github:
> https://github.com/docker-library/docs/tree/master/httpd
>
> The “deploy X application, according to how the developers spelled it
> out, isolated from host OS environment” scenario has been pretty much
> captured and owned by the Docker folks; they’ve done a masterful job of it.
Docker is awesome for "get started fast" (as are Chef & Puppet) with
best-practices, but none of those 3 solutions really deal with how to
migrate an existing pre-2.4 config to 2.4, which I think was the point
Jeff was trying to make.
I have to admit, even given my involvement in the project, I personally
still cringe a bit every time I need to do that upgrade.
>
> Best,
> Victor
> --
> Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
> <ma...@alumni.duke.edu>
>
Re: commercial support
Posted by "Victor J. Orlikowski" <vi...@alumni.duke.edu>.
On Nov 21, 2014, at 9:21 AM, Victor J. Orlikowski <vi...@alumni.duke.edu> wrote:
>
> The “deploy X application, according to how the developers spelled it out, isolated from host OS environment” scenario has been pretty much captured and owned by the Docker folks; they’ve done a masterful job of it.
To build on this statement:
http://mike-clarke.com/2013/11/applied-docker-continuous-integration/ <http://mike-clarke.com/2013/11/applied-docker-continuous-integration/>
This describes one approach to doing CI using Docker containers for isolation.
It’d be *just as simple* to create a Dockerfile that does a minimal install of a current version Ubuntu or Fedora, installs the base dev tools, fetches release tarballs of APR-Util, APR, and httpd, and builds.
Hell - it’d be great to do that, just for CI of APR/APR-Util/httpd anyway.
Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
Re: commercial support
Posted by "Victor J. Orlikowski" <vi...@alumni.duke.edu>.
On Nov 21, 2014, at 9:01 AM, Jeff Trawick <tr...@gmail.com> wrote:
>
> * oh, and make it possible for 90% of the potential user base to be running 2.4.latest in several minutes without possibly interfering with existing software; user guide material (above) must support having the user's own application deployed behind httpd a few minutes later
>
The “new hotness” making something like this possible, on Linux and OS X at least, is Docker.
Here’s the Dockerfile in github:
https://github.com/docker-library/docs/tree/master/httpd <https://github.com/docker-library/docs/tree/master/httpd>
The “deploy X application, according to how the developers spelled it out, isolated from host OS environment” scenario has been pretty much captured and owned by the Docker folks; they’ve done a masterful job of it.
Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
Re: commercial support
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Nov 20, 2014 at 5:00 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> It's a shame that there isn't a company like Covalent
> around anymore that focuses on the Apache httpd web-server.
> nginx.com shows kinda clearly that having a motivated
> company behind a web-server helps grab market share and
> market awareness (they can continue to beat the drum about
> how fast and reliable they are, when so many benchmarks
> lately show that 2.4 is just as fast if not faster in
> actual response time, but we have limited ability to
> do that, and most reporters see us as Old "news" and
> nginx as the new hotness anyway)...
>
> So who wants to get together and create a company
> around httpd? :)
>
(Pretending that you're completely serious for a minute)
Decision makers are extremely comfortable picking parts of their technology
stack that are backed primarily by one vendor (but are indeed "open source
projects," even if not the most inclusive or vibrant) and have a mixed
offering like that of nginx.com. That's both the way a business model can
empower the creators to make a particular solution attractive as well as a
pat answer to the question of motivation to maintain and enhance the
solution in the future. Risk is mitigated by a philosophy of integrating
components from many different sources, so it may not be worth much to
analyze one particular component too deeply. (Follow the crowd but listen
out for grumbling.) I don't think there's any benefit to technical
squabbles between nginx and httpd proponents in this environment.
The ecosystem for httpd is huge; there are uncountable programmer-years
worth of available solutions out there in the "Premium httpd" space, so I
don't see nearly as much business justification for the free/premium model
with httpd as there is with nginx. At the same time, there's no ability
(not that there is a desire) to segregate certain features into a premium
version. A support model doesn't seem worthwhile; your users are probably
on Linux and they can get a better offer for support coverage through their
Linux vendor; and given that nobody wants to use something anyway if they
don't anticipate that the answer is already on stackoverflow, quibbling
about differences in quality of support probably doesn't help in many
situations.
I don't think we're an attractive solution in the most literal sense (did
somebody say "seen as old and tired"?), even though there is a tremendous
amount of development vitality.
If I had the pile of cash to start a company centered around httpd, I'd
want to fund these work items on the open source side immediately:
* fresh, professionally designed web site (look ALIVE, look EVOLVING, look
VALUABLE)
* updated look for documentation, and significantly enhanced "User Guide"
material; the latter is DESPERATELY needed to supplant the ubiquitous
1999-era (e.g., run-that-dynamic-language-in-the-server, pre-forking, etc.)
"solutions"; we need to OWN the story for how to do X with httpd if X is at
least moderately popular or is something that works particularly well with
httpd; this is an area where we are suffering from having been around for
so long; and once the material is available, lots of SEO attention
* careful gleaning of requirements from all the reasons people give for
using another solution (even seemingly innocuous comments on blog articles
can give a valuable hints at a pain point), and prioritize these for near
term solution
* clear summations of direction for HTTP, SSL/TLS, application deployment,
complimentary statements of direction for httpd and dedicated resources to
carry it out, and regular status reports which are generally informative
beyond the httpd groupie community
* oh, and make it possible for 90% of the potential user base to be running
2.4.latest in several minutes without possibly interfering with existing
software; user guide material (above) must support having the user's own
application deployed behind httpd a few minutes later
At that point it is easy for people to kick the tires, and a baseline is in
place for the company to then pursue whatever wild idea somebody had for
making money.
----
Given no such company and perhaps 30 developers with their own disparate
means of keeping of coffee in the pantry, while potentially benefiting
financially and otherwise from a healthier httpd ecosystem, how can we
organize our apparently limited time to meet the more important goals?
> Honestly though, how much of the uptake in nginx
> do people think is actually due to nginx being "better"
> or the "best" choice, and how much do you think is
> due simply because it's *seen* as better or that we
> are seen as old and tired?
>
>
Pretty much all I can think of these days is the
deploy-heavy-application-behind-proxy scenario. Overall, httpd is fine.
httpd is generally there w.r.t. specific features in mod_proxy_X, but we
have to expect that there will be a stream of small modifications needed in
the near term to handle issues that had to be handled in nginx already.
> This is our 20year anniversary... It would be cool
> to use that to remind people! :)
>
We need a cute way to represent that the way you did things with httpd 20,
15, 10, and even 5 years ago is NOT the way you should do it now. Word
clouds that fade in and out? .conf snippets that fade in and out?
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: commercial support
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Nov 20, 2014 at 5:30 PM, Tim Bannister <is...@c8h10n4o2.org.uk>
wrote:
> On 20 Nov 2014, at 22:00, Jim Jagielski <ji...@jaguNET.com> wrote:
> >
> > Honestly though, how much of the uptake in nginx do people think is
> actually due to nginx being "better" or the "best" choice, and how much do
> you think is cue simply because it's *seen* as better or that we are seen
> as old and tired?
> >
> > This is our 20year anniversary... It would be cool to use that to remind
> people! :)
>
> Here are some plausible explanations, off the top of my head but with
> editing.
>
> I reckon that at least some of the perception is down to Apache httpd
> being used in “enterprise” systems that are a long way back from the
> bleeding edge. If your mission-critical system is running a webserver
> release that's older than nginx itself then it's likely that nginx will
> look and work better.
>
> Another challenge is compatibility. As the default webserver on lots of
> distributions, httpd has a lot of existing users who don't want to see it
> break in an upgrade. For that reason, an upgrade typically won't convert an
> installation from prefork to another MPM. Install nginx… and it performs
> very differently; it's also complicated enough to merit a HOWTO. There
> won't be as many HOWTO guides about a one-line change to select a different
> MPM.
>
> There are now plenty of guides to building nginx from source. To be
> honest, this is a bit more straightforward than the equivalent task for
> httpd 2.4.x because operating systems that include httpd 2.2 may well have
> too-old APR and APR-Util as well. AIUI, nginx has fewer dependencies.
>
+1
Beyond the need to build APR and APR-Util, many people have other problems
(reported to users@httpd list and Bugzilla) when attempting to perform
seemingly simple builds -- collisions with pre-installed headers,
difficulty with plugging in new OpenSSL, build logic that might find
libxml2 at configure time but not find it at make time, yada yada yada.
I think one aspect that makes this even worse: The nginx generally
available in a lot of version (latest-1), (latest-2) distributions is
sufficient, whereas the httpd in that same distribution is not, so more
people are trying to build (or just using nginx).
>
> Commercial support sounds nice. I think firms who'd pay for it would
> really like to get a commercially-supported web server bundled with their
> “enterprise” operating system. In that sense, Oracle and Red Hat are
> already offering commercial support for httpd.
>
> --
> Tim Bannister – isoma@c8h10n4o2.org.uk
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: commercial support
Posted by Tim Bannister <is...@c8h10n4o2.org.uk>.
On 20 Nov 2014, at 22:00, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> Honestly though, how much of the uptake in nginx do people think is actually due to nginx being "better" or the "best" choice, and how much do you think is cue simply because it's *seen* as better or that we are seen as old and tired?
>
> This is our 20year anniversary... It would be cool to use that to remind people! :)
Here are some plausible explanations, off the top of my head but with editing.
I reckon that at least some of the perception is down to Apache httpd being used in “enterprise” systems that are a long way back from the bleeding edge. If your mission-critical system is running a webserver release that's older than nginx itself then it's likely that nginx will look and work better.
Another challenge is compatibility. As the default webserver on lots of distributions, httpd has a lot of existing users who don't want to see it break in an upgrade. For that reason, an upgrade typically won't convert an installation from prefork to another MPM. Install nginx… and it performs very differently; it's also complicated enough to merit a HOWTO. There won't be as many HOWTO guides about a one-line change to select a different MPM.
There are now plenty of guides to building nginx from source. To be honest, this is a bit more straightforward than the equivalent task for httpd 2.4.x because operating systems that include httpd 2.2 may well have too-old APR and APR-Util as well. AIUI, nginx has fewer dependencies.
Commercial support sounds nice. I think firms who'd pay for it would really like to get a commercially-supported web server bundled with their “enterprise” operating system. In that sense, Oracle and Red Hat are already offering commercial support for httpd.
--
Tim Bannister – isoma@c8h10n4o2.org.uk
Re: commercial support
Posted by Jeff Trawick <tr...@gmail.com>.
On Sun, Nov 23, 2014 at 4:23 PM, Mark Blackman <ma...@exonetric.com> wrote:
> Is Apache 2.4 really just as fast as nginx for response times for an
> arbitrary number of concurrent connections?
>
> Apache is great and it’s now so mature that most enterprises are very
> comfortable with it, but where nginx started with a very simple premise and
> have kept the scope restricted.
>
> For me, Apache is a Swiss army knife that has a solution for nearly every
> use case and nginx is more like a surgeon’s scalpel, best of breed in that
> domain (maximal concurrent connections for minimum resource cost with
> minimum feature set), but unhelpful in other places.
>
The question is hard to answer satisfactorily. You have to pick a workload
that you are familiar with and try it with both (where httpd is 2.4 with
Event MPM). httpd is faster at some, and I'm sure that nginx is faster at
others.
Your characterization of httpd and nginx is a lot more nuanced than the
assumptions of a lot of people. httpd is often characterized as big and
slow based on old reality and the continued use of it in old ways, and
because of that it is passed over in a lot of cases where it is the better
overall solution.
>
>
> Cheers,
> Mark
>
> > On 20 Nov 2014, at 22:00, Jim Jagielski <ji...@jaguNET.com> wrote:
> >
> > It's a shame that there isn't a company like Covalent
> > around anymore that focuses on the Apache httpd web-server.
> > nginx.com shows kinda clearly that having a motivated
> > company behind a web-server helps grab market share and
> > market awareness (they can continue to beat the drum about
> > how fast and reliable they are, when so many benchmarks
> > lately show that 2.4 is just as fast if not faster in
> > actual response time, but we have limited ability to
> > do that, and most reporters see us as Old "news" and
> > nginx as the new hotness anyway)...
> >
> > So who wants to get together and create a company
> > around httpd? :)
> >
> > Honestly though, how much of the uptake in nginx
> > do people think is actually due to nginx being "better"
> > or the "best" choice, and how much do you think is
> > due simply because it's *seen* as better or that we
> > are seen as old and tired?
> >
> > This is our 20year anniversary... It would be cool
> > to use that to remind people! :)
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: commercial support
Posted by Mark Blackman <ma...@exonetric.com>.
Is Apache 2.4 really just as fast as nginx for response times for an arbitrary number of concurrent connections?
Apache is great and it’s now so mature that most enterprises are very comfortable with it, but where nginx started with a very simple premise and have kept the scope restricted.
For me, Apache is a Swiss army knife that has a solution for nearly every use case and nginx is more like a surgeon’s scalpel, best of breed in that domain (maximal concurrent connections for minimum resource cost with minimum feature set), but unhelpful in other places.
Cheers,
Mark
> On 20 Nov 2014, at 22:00, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> It's a shame that there isn't a company like Covalent
> around anymore that focuses on the Apache httpd web-server.
> nginx.com shows kinda clearly that having a motivated
> company behind a web-server helps grab market share and
> market awareness (they can continue to beat the drum about
> how fast and reliable they are, when so many benchmarks
> lately show that 2.4 is just as fast if not faster in
> actual response time, but we have limited ability to
> do that, and most reporters see us as Old "news" and
> nginx as the new hotness anyway)...
>
> So who wants to get together and create a company
> around httpd? :)
>
> Honestly though, how much of the uptake in nginx
> do people think is actually due to nginx being "better"
> or the "best" choice, and how much do you think is
> due simply because it's *seen* as better or that we
> are seen as old and tired?
>
> This is our 20year anniversary... It would be cool
> to use that to remind people! :)