
Apache releases first major new version of popular Web server in six years - thenextcorner
http://www.zdnet.com/blog/open-source/apache-releases-first-major-new-version-of-popular-web-server-in-six-years/10390
======
Garbage
Overview of new features in Apache HTTP Server 2.4

<http://httpd.apache.org/docs/2.4/new_features_2_4.html>

~~~
peterwwillis
<http://httpd.apache.org/docs/2.4/mod/mod_heartbeat.html>

It frustrates me when people use ASCII instead of packed bitmaps for things
like this (packet transmitted once a second from potentially hundreds or
thousands of nodes, that each frontend proxy has to parse into a binary form
anyway before using it). Maybe it's a really small amount of CPU but it's just
one of many things which could easily be more efficient.

Some of this stuff is so simple and useful it's a wonder they weren't there
before:

<http://httpd.apache.org/docs/2.4/mod/mod_auth_form.html>
<http://httpd.apache.org/docs/2.4/mod/mod_session_dbd.html>
<http://httpd.apache.org/docs/2.4/mod/mod_buffer.html>
<http://httpd.apache.org/docs/2.4/mod/mod_data.html>
<http://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html>
<http://httpd.apache.org/docs/2.4/mod/mod_lua.html>

_"mod_ssl can now be configured to share SSL Session data between servers
through memcached"

"mod_cache is now capable of serving stale cached data when a backend is
unavailable (error 5xx)."

"Translation of headers to environment variables is more strict than before to
mitigate some possible cross-site-scripting attacks via header injection."

"mod_rewrite Allows to use SQL queries as RewriteMap functions."

"mod_ldap adds LDAPConnectionPoolTTL, LDAPTimeout, and other improvements in
the handling of timeouts. This is especially useful for setups where a
stateful firewall drops idle connections to the LDAP server."

"rotatelogs May now create a link to the current log file."_

Very nice that they rewrote the mod_rewrite and caching guides with more
examples and ease of use in mind. Here are the API changes:
<http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html>

~~~
scott_s
_It frustrates me when people use ASCII instead of packed bitmaps for things
like this (packet transmitted once a second from potentially hundreds or
thousands of nodes, that each frontend proxy has to parse into a binary form
anyway before using it). Maybe it's a really small amount of CPU but it's just
one of many things which could easily be more efficient._

I think that's a premature optimization. _If_ it becomes a performance
problem, optimize it then. Otherwise, I doubt it's worth the cost of humans
not being able to read the information on the wire, and deciding on and
implementing a binary format to represent the information.

~~~
peterwwillis
That's a fine philosophy for the just-ship-it model of startup webapp
development, but this is a piece of server software which is supposed to scale
high and far and reduce its resource use as much as possible (part of the
emphasis of the release as noted).

If you're writing a piece of some software with one specific function and it
doesn't affect anything else and it doesn't take any more time to make it
efficient, just do it efficiently the first time. This way you don't have to
come back later and rewrite it (which by the time that's required, somebody
already wrote something dependent on your crappy design, which now has to be
fixed too, etc)

~~~
scott_s
It might be the philosophy of "the just-ship-it model of startup webapp
development", but it's not why I have it. It comes from the philosophy of high
performance systems research where you can spot inefficiencies _all over_ the
system, you just don't have enough time to optimize them all, and any extra
complexity you put into the system better be worth it. Every "optimization"
you put into your system better have performance numbers associated with it;
if you can't experimentally demonstrate that the optimization is worth it,
it's not.

~~~
peterwwillis
I agree that if you try to optimize everything before proof that you need it
you'll be wasting a lot of time. But the case i'm talking about is a function
in mod_heartmonitor.c which calls apr_strtok, strchr, and ap_unescape_url(x2)
for three iterations and returns the values in a table. And that function is
duplicated at mod_lbmethod_heartbeat.c. For a cluster of 850 servers that's
10,200 function calls every second. When they could have just copied a raw
network-order bit string into a struct. Or something.

Yeah it's probably insignificant, but they could have just done it that way
the first time. There'd be no optimizing needed thereafter, and no side-effect
as it's only used in two places for a limited function. It's actually smaller
and easier and faster to write AND to run. You make the right choices at
design and implementation time and you come out with better code which doesn't
need to be optimized.

~~~
wheels
Sorry, but you're just wrong on this. Here's an example of parsing a string
like the one in there:

<http://pastie.org/3429643>

It parses that string and reads it into a struct at a rate of about 3 million
per second on a single core on my Macbook Pro. That means for your example
there of 850 machines in a cluster, we're talking about roughly a quarter of a
millisecond of one core of CPU time. Even if that's off by an order of
magnitude, _it doesn't matter_.

 _THERE IS ABSOLUTELY NO REASON TO OPTIMIZE THIS CASE_

The enemy of optimization is hard to maintain code, not small inefficiencies.

Using text in this case makes the wire protocol easier to debug and generally
easier to maintain for forward compatibility. Need to add an extra argument?
It'll be both self-documenting and backwards compatible, instead of some
versioned mess of bitflags.

Could I be wrong? Sure. There's an easy way to prove such: show me the
profiler output. Your eagerness for micro-optimizations significantly hints at
inexperience.

~~~
peterwwillis
Assuming that it'd perform that way in the real world, you are right that my
solution would have no significant performance increase over the sscanf you
use. But I don't totally agree with some of your supporting arguments.

The wire protocol you're talking about is a heartbeat protocol. This doesn't
need to be human-readable because there is no input from a human, nor is it
intended for a human to read. Debugging it would be as complicated as a
"printf". Oh the horror. We wouldn't want to add debugging to our application
- better make people read the raw data with a packet sniffer (which you can't
run unless you have root, so good luck getting your application debugged
quickly, developers).

Adding an extra argument would require appending an extra field and
incrementing the version. Oh noes the mess! Since both solutions are
versioned, forward compatibility is just updating code in the server, and if
you're going to change things you have to update code anyway, so this doesn't
sound like a good reason to oppose it.

Realistically, will more than a handful of shops have a big enough cluster for
any of this to matter? No. But even your example of using sscanf is faster
than Apache's code (<http://pastie.org/3430085>) while being 100% compatible
with the rest of the code, and still goes to show that doing it right the
first time is better than just slapping something together and waiting until
you have to optimize.

So do we _need_ to use an unreadable, simpler solution? No. But it would work
just as well as anything else and take just as much time to write - if not
less.

------
jbarham
It may sound trivial, but the thing I appreciate most about Nginx is its
lightweight config file syntax.

It's very easy to glance over and see what's been set up compared to Apache's
verbose pseudo-XML syntax which is about the worst syntax you can come up
with: the verbosity of XML but without the benefit of being able to generate
or parse it using standard XML tools!

~~~
antihero
Yep, it's utterly dire. People bitch about X11 config files, but this is in
many ways worse because it pretends to be XML. It'd be nice to submit a patch
for Apache so it can read YAML, XML, and JSON based configuration. Or even
just some sort of consistent fucking format, so we can generate configs for a
bunch of servers with lxml or something.

The other thing that fucks me off is that the server will reboot happily and
fail to start without having first checked that it can start, and configtest
doesn't pick up things like directories being missing.

~~~
gpmcadam
> _and configtest doesn't pick up things like directories being missing._

Uh, last time I checked (Apache 2.2.17 (Ubuntu)) it did.

    
    
        # apache2ctl configtest
        Warning: DocumentRoot [/dev/null/doesnt/even/exist] does not exist

------
krmmalik
I guess real world testing is going to be the best indicator of whether this
is a worthy release or not, but i sure am very glad that Apache have at least
attempted to up their game. Even if they are not able to deliver on their
promise, the effort is noble enough - at least for now.

Personally, i'm very glad to see performance considerations being taken
seriously, and even if nginx or node.js don't take over the world, its nice to
see that they're forcing others to sit up and think.

~~~
bwarp
Never underestimate the power of "good enough".

Apache is "good enough" for most people.

NGINX or Node.js really don't bring much new to the table of "good enough".

It's why plan 9 isn't as popular as it probably should be. UNIX was good
enough.

~~~
scott_w
I disagree. Nginx brings a lot to the table in simplicity and ease-of-use.

Just reading an nginx.conf and comparing it to an httpd.conf should be enough
to convince you what nginx brings to the table.

~~~
rickmb
The thing is, for the average site run under Apache, adding 5 lines of config
is all the configuration needed for the entire life cycle of the server.

On the high end, provisioning is fully automated.

Not to mention the fact that after > 15 years(!), amateur sysadmins like me
can pretty much dream the config settings.

Which leaves a relatively small target audience for whom a simpler config is
even remotely relevant.

~~~
LokiSnake
That's the wrong mindset to have, IMO. Just because the incumbent sysadmins
have gotten used to the eccentricities of Apache doesn't mean having something
easier to configure is not necessary. This is similar to what people said when
the iPhone was announced.

~~~
quanticle
There's a big difference between your two scenarios. At the time the iPhone
came out, only a very tiny fraction of people had ever owned (or even used) a
smartphone. The iPhone's success came because it was able to grow the market,
convincing feature-phone users to upgrade to a smartphone. I don't see the
same thing happening with nginx. I don't see anyone saying, "Gee wiz, I didn't
want to be a sysadmin, but now that I've seen nginx's easy config file syntax,
I want to be a sysadmin now."

------
xpose2000
I'm excited. Even if it is only a 5% to 10% improvement in performance, then
that buys me a little bit more headroom on my current server setup.

I look forward to testing it out down the road.

------
tutu55634
Micro Benchmark of Apache 2.4 vs Nginx 1.0:
[http://blog.causal.ch/2012/02/micro-benchmark-
apache-24-vs-n...](http://blog.causal.ch/2012/02/micro-benchmark-apache-24-vs-
nginx-10.html)

------
etomer
Get your faces off of your articles' headers!

------
rplnt
3.0 would be major, 2.4 is minor.

~~~
robtoo
The headline is "major new version" not "new major version".

~~~
rplnt
Interesting difference. I've not noticed that. But when I think about it, what
does "major new version" mean?

~~~
kbutler
new "major version" is jargon - a term of art with a generally accepted
meaning of incrementing the most significant version number.

"major" new version is just English - it's a new version with significant
enhancements or impact.

~~~
lloeki
> new "major version" is jargon - a term of art with a generally accepted
> meaning of incrementing the most significant version number.

An example of which would be <http://semver.org/>

------
cmaxwell
Expecting to see some meaningless benchmarks soon.

~~~
victork2
You know you have a good software when people begin to procrastinate on your
software by comparing the number of requests / second that your server will
accept, knowing that 99.9% will never reach that.

Oh and ... Node.js is probably going to be mentioned.

~~~
redslazer
If a server can handle a larger number of requests that the same server with
different web server could this automatically means resource usage per
connection is lower.

This is good for everyone ranging from small site to large because it means
reduces costs etc.

~~~
gaius
Very relevant on VPS's.

------
chbrown
"While it seems unlikely that NGINX could overcome Apache’s commanding lead
..." Oh zdnet, don't you realize that actions like this release from Apache,
obviously under pressure from NGINX, are precisely the indicators that you
will be eating your words in a year or two?

~~~
recoiledsnake
IIS takes almost all the profit in web servers though. /Asymco

~~~
rbanffy
And people stay with it because it would be so much pain to migrate to
anything else. Just imagine rewriting all that VBScript code... That's mostly
why companies kept IE6 for so long.

edit: forgot the "burn, karma, burn" line...

~~~
cooldeal
Yes, those legacy servers went from 57 million in Feb 2011 to 88 million in
Feb 2012, all running VBScript.

VBScript must be the hottest programming language, right?

Netcraft confirms it.

~~~
rbanffy
You know how it works. You already have a shop full of people trained to work
your legacy apps, with their shiny MC* certifications, comfortable in their
safe lifetime dead-end jobs... What do you think they'll do? Use the tools
they have been using for a long time now or explain management (because they
really don't decide anything) they need to learn to use better tools?

Do you really think most MC* people are eager to move on to tools that make
their certifications worthless? When they move, they do along Microsoft's
designated path and rarely stray from it.

~~~
cooldeal
>Use the tools they have been using for a long time now or explain management
(because they really don't decide anything) they need to learn to use better
tools?

Better tools like what?

Maybe there are many people out there that think that ASP.NET/C#/MVC and
Visual Studio are actually better tools for them?

I know that could be an alien concept around these parts and for you but that
doesn't make it any less true.

Saying that they should discard their knowledge and move to Ruby/PHP/Node is
as idiotic as saying Ruby developers should ditch Ruby and move to Visual
Studio/C#/.NET since it might be one of the best platforms around.

>Do you really think most MC* people are eager to move on to tools that make
their certifications worthless? When they move, they do along Microsoft's
designated path and rarely stray from it.

Microsoft has been building up support for Python, PHP, Node and github.
Anyway, the reality is nothing close to the dystopian light that you paint
them in. The jobs are no more dead-end than Java or PHP or Ruby jobs.

And no, sorry, VBScript is barely around in maybe in around 5% of companies
running IIS, people have moved on to new technologies, unlike constant MS
bashers who seem to be stuck atleast a decade back in their criticisms.

~~~
rbanffy
> Ruby developers should ditch Ruby and move to Visual Studio/C#/.NET since it
> might be one of the best platforms around

Except that VS/C#/.NET isn't one of the best platforms around unless you code
for Windows. And that's one more reason not to move to other platforms -
because the tools they use don't support the alien technology as well as what
they've been using.

> The jobs are no more dead-end than Java or PHP or Ruby jobs.

You obviously have a different idea of what constitutes a dead-end job. I
imagine it's a job at a company that thinks of IT as a cost of doing business,
something competitive advantages are not to be derived from. Those companies
will not invest in new things until everybody else is doing it and hire the
same kinds of professional other companies hire. They use certifications
instead of interviews because then the whole hiring process can be done within
HR. I've seen a lot of them.

> VBScript is barely around in maybe in around 5% of companies running IIS

I know it's not a thorough review, but I see plenty of .asp URLs around within
corporate confines.

~~~
Sanddancer
File extensions are meaningless. My router uses .asp for file extensions, and
I know for a fact that it does not use vbscript, as it is running Linux.

~~~
rbanffy
That reminds me of a prank I did with a couple friends. We had a site running
on Zope and we decided to use every known extension for our URLs. I think we
got to a dozen different ones.

