On Tue, Jun 1, 2010 at 9:04 AM, William A. Rowe Jr. wrote:
[...]
> Plus deflate may provide no benefit, and degrade performance, if the CPU
> utilization is a greater concern than bandwidth utilization.
The CPU utilization is an interesting topic for me because I've been
working on a related type
All,
I was once offered money to provide a high-performance Apache configuration
file for a website. When I pointed out that I would need to come in, analyze
their app and its performance, and then iteratively tune the config
accordingly, I was given to understand that this was not necessary.
On Tue, Jun 1, 2010 at 10:28 AM, Matthew Steele wrote:
> I went ahead and created a bug entry/patch to make the (trivial)
> change to mod_deflate to make it conform to the "Guide to writing
> output filters":
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49369
>
> Brian, does this patch
Let me preface ALL the remarks below with TWO statements...
1. I haven't done any research on these HTTP based Client/Server compression
topics in quite some time. It is all, essentially, 'ancient history' for me
but it still amazes me that some of the issues are, so many years later,
still bei
On Tue, Jun 1, 2010 at 16:25, Sergey Chernyshev
wrote:
> This sounds scary! How do large companies enable gzip then? How many hoops
> do they jump through? sounds like those hoops are in thousands!
> And I don't understand how one company's setup would be different from
> another still, even if si
On Tue, Jun 1, 2010 at 6:17 PM, wrote:
>> There is zero reason for us to avoid putting deflate into the default
>> configuration.
>
> Sorry. There ARE (good) reasons to avoid doing so.
>
> I'm the one who wrote the FIRST mod_gzip module for Apache 1.x series
> so you would think I'd be a strong a
> Sergey wrote...
> That's new to me that browsers don't cache stuff that has Vary only on
> Accept-Encoding - can you post some statistics or describe the test you ran?
Test results and statistics...
Apache DEV forum...
http://www.pubbs.net/200908/httpd/55434-modcache-moddeflate-and-vary-user-a
> web sites are loading too slow for pipes and web-server power that we have.
The key phrase there is 'that WE have'.
YOU need to tune YOUR configs to match what YOU have.
ANYONE who uses Apache can/should/must do that.
That's how that works.
The discussion at this moment is what 'default' confi
>> Don't forget the ongoing issue that if you ONLY vary on 'Accept-Encoding'
>> then almost ALL browsers will then refuse to cache a response entity LOCALLY
>
> Really? That sounds bizarre! Do you have a reference for it?
>
> Nick Kew
Apache DEV forum...
http://www.pubbs.net/200908/httpd/55434-
>
> It's not 'broken'.
> Why change it?
>
Please don't think that old configurations and practices are not broken -
web sites are loading too slow for pipes and web-server power that we have.
And situation is getting worse year after year - here's analysis by Patrick
Meanan of WebPageTest.org's o
This sounds scary! How do large companies enable gzip then? How many hoops
do they jump through? sounds like those hoops are in thousands!
And I don't understand how one company's setup would be different from
another still, even if situation is that bad as you describe it.
What kind of trade-off
That's new to me that browsers don't cache stuff that has Vary only on
Accept-Encoding - can you post some statistics or describe the test you ran?
As for *all* content types, I don't think we're talking about compressing
images and it's relatively easy to create a white-list to have gzip on for
b
> There is zero reason for us to avoid putting deflate into the default
> configuration.
Sorry. There ARE (good) reasons to avoid doing so.
I'm the one who wrote the FIRST mod_gzip module for Apache 1.x series
so you would think I'd be a strong advocate of 'auto-enablement' by default,
but I am
On Tue, 01 Jun 2010 17:44:41 -0400
toki...@aol.com wrote:
>
> Don't forget the ongoing issue that if you ONLY vary on 'Accept-Encoding'
> then almost ALL browsers will then refuse to cache a response entity LOCALLY
Really? That sounds bizarre! Do you have a reference for it?
--
Nick Kew
Don't forget the ongoing issue that if you ONLY vary on 'Accept-Encoding'
then almost ALL browsers will then refuse to cache a response entity LOCALLY
and the pain factor moves directly to the Proxy/Content Server(s).
If you vary on 'User-Agent' ( No longer reasonable because of the abuse
of tha
On Tue, Jun 1, 2010 at 9:08 AM, Jim Jagielski wrote:
> Considering that 2.3/trunk is back to limbo-land, I'd like
> to propose that we be more "aggressive" is backporting some
> items. Even if under experimental, it would be nice if slotmem
> and socache were backported. I also like the refactorin
Yeah, it should only Vary on Accept-encoding (already does). It's still not
perfect, but at least it doesn't blow up proxies too much.
The question to people with statistics - are there any other issues with
gzip/proxy configurations?
Sergey
On Tue, Jun 1, 2010 at 11:01 AM, Eric Covener
I went ahead and created a bug entry/patch to make the (trivial)
change to mod_deflate to make it conform to the "Guide to writing
output filters":
https://issues.apache.org/bugzilla/show_bug.cgi?id=49369
Brian, does this patch to mod_deflate fix your problem?
Nick, does this change seem reaso
On 25.05.2010 15:09, "Plüm, Rüdiger, VF-Group" wrote:
-Original Message-
From: Joe Orton
Sent: Dienstag, 25. Mai 2010 14:46
To: dev@httpd.apache.org
Subject: RFC: drop support for OpenSSL< 1.0 in trunk/2.3?
I'd like to drop support for versions of OpenSSL older than
1.0 in the
trunk mod
Considering that 2.3/trunk is back to limbo-land, I'd like
to propose that we be more "aggressive" is backporting some
items. Even if under experimental, it would be nice if slotmem
and socache were backported. I also like the refactoring of
the providers for proxy in trunk as compared to 2.2, but
On 6/1/2010 7:05 AM, Eric Covener wrote:
>> Typically, you
>> would want to front a mod_deflate with an HTTP cache, such as mod_cache (or
>> equivalent). Here mod_cache only makes sense if you have the disk space to
>> support it, and there is no real one-size-fits-all cache setup.
>
>> This said,
On 1 Jun 2010, at 15:53, Bryan McQuade wrote:
> According to this, mod_deflate should not pass the empty brigade
> along, and your module also should not be passing and empty brigade to
> mod_deflate.
>
> Eric, others, should we submit a patch to mod_deflate to change its
> behavior to be consis
> Deprecating obsolete libraries is a good thing, especially if there is
> a compelling replacement.
>
> I think this goes hand in hand with what operating system versions we
> will be targeting for 2.4. We should inventory which versions of the
> libraries are offered on each and then make th
On Tue, Jun 1, 2010 at 11:02 AM, "Plüm, Rüdiger, VF-Group"
wrote:
>> The guide to writing output filters says:
>>
>> https://httpd.apache.org/docs/trunk/developer/output-filters.h
>> tml#invocation
>>
>> "An output filter should never pass an empty brigade down the filter
>> chain. But, for good d
> -Original Message-
> From: Bryan McQuade
> Sent: Dienstag, 1. Juni 2010 16:54
> To: dev@httpd.apache.org
> Cc: mdste...@google.com
> Subject: Re: mod_deflate handling of empty initial brigade
>
> The guide to writing output filters says:
>
> https://httpd.apache.org/docs/trunk/devel
IIUC, the vary: user-agent to accomodate Netscape 4 is a pain for
caches because obviously they can only vary on the entire user-agent.
http://httpd.apache.org/docs/2.2/mod/mod_deflate.html
Is it time to move this aspect of the snippet into a separate note or
some historical trivia section, to re
The guide to writing output filters says:
https://httpd.apache.org/docs/trunk/developer/output-filters.html#invocation
"An output filter should never pass an empty brigade down the filter
chain. But, for good defensive programming, filters should be prepared
to accept an empty brigade, and do not
On Tue, Jun 1, 2010 at 10:39 AM, Brian Pane wrote:
> In a filter module I'm writing, it's possible for the first pass
> through the output filter to end up calling:
> ap_pass_brigade(f->next, an_empty_brigade)
>
> If mod_deflate's output filter appears later in the output filter
> chain, bad th
On Tue, Jun 1, 2010 at 8:40 AM, Greg Stein wrote:
> Geez, Eric. No wonder people don't want to contribute to httpd, when they
> run into an attitude like yours. That dismissiveness makes me embarressed
> for our community.
Congeniality lesson noted, but not in the way you probably intended.
> Th
In a filter module I'm writing, it's possible for the first pass
through the output filter to end up calling:
ap_pass_brigade(f->next, an_empty_brigade)
If mod_deflate's output filter appears later in the output filter
chain, bad things happen:
1. On the first trip through the output filter ch
- "Eric Covener" wrote:
> > here's a patch to mod_disk_cache.h to set the defaults as
> recommended by:
> > http://httpd.apache.org/docs/trunk/mod/mod_disk_cache.html
>
> I might be crazy, but I can't spot the recommendation you refer to in
> the doc.
No, you're not crazy. I supplied the w
On Tue, Jun 1, 2010 at 5:38 AM, Graham Leggett wrote:
> On 01 Jun 2010, at 2:30 AM, Bryan McQuade wrote:
>
>> I had a conversation with a well known hosting provider recently and
>> they told me they use the default Apache configuration for their
>> shared hosting service. When I asked if they pro
> here's a patch to mod_disk_cache.h to set the defaults as recommended by:
> http://httpd.apache.org/docs/trunk/mod/mod_disk_cache.html
I might be crazy, but I can't spot the recommendation you refer to in the doc.
--
Eric Covener
cove...@gmail.com
Hi folks,
here's a patch to mod_disk_cache.h to set the defaults as recommended by:
http://httpd.apache.org/docs/trunk/mod/mod_disk_cache.html
This is quite a complex patch, and I'm not sure it'll pass any reviews.
Index: mod_disk_cache.h
I repeatedly inserted millisecond or microsecond timestamps as well as
PID and thread ID information into the ErrorLog when trying to diagnose
problems, most often in combination with additional log lines.
Due to the increased load and capability of systems and increasing
amount of concurrency
From: Greg SteinSent: Dienstag, 1. Juni 2010 14:40
To: dev@httpd.apache.org
Subject: Re: Fast by default
Geez, Eric. No wonder people don't want to contribute to httpd, when
they run into an attitude like your
Geez, Eric. No wonder people don't want to contribute to httpd, when they
run into an attitude like yours. That dismissiveness makes me embarressed
for our community.
There is zero reason for us to avoid putting deflate into the default
configuration.
It is also very arguable that we should leave
> Typically, you
> would want to front a mod_deflate with an HTTP cache, such as mod_cache (or
> equivalent). Here mod_cache only makes sense if you have the disk space to
> support it, and there is no real one-size-fits-all cache setup.
> This said, our default config is 15 years old, and attempt
- "Graham Leggett" wrote:
> The very definition of "tuned" means "tailored for your local setup".
It's actually quite hard to get this thought accross. I think we should
put it in a reboot of the performance ``optimization'' documentation.
> The default httpd configuration works reasona
Situation: worker or event MPM. Process shutdown due to:
- MaxRequestsPerChild
- MaxSpareThreads
- Graceful stop or graceful restart
When an httpd child process shuts down due to the above conditions, it
doesn't respect existing Keep-Alive connections. When the previous
response signalled keep
Hi,
First of all, hi to the Apache developers, I'm new to this list - nice
to meet you all.
I'm wondering if it's possible for an Apache module to change global
config structures.
What I want to achieve is injecting new vhosts without Apache restart.
Of course I'm aware that the changes would fu
On 01 Jun 2010, at 2:30 AM, Bryan McQuade wrote:
I had a conversation with a well known hosting provider recently and
they told me they use the default Apache configuration for their
shared hosting service. When I asked if they provide gzip as an option
for their users, they said no, since it wa
On 01.06.2010 07:19, Jerome Renard wrote:
In 2010, IMO there is no good reason to have gzip disabled by default.
Almost all websites enable it. There are a handful of prominent
websites that do not. I've had conversations with a few of these
sites. Most of them have not turned it on because they
On 6/1/2010 3:30 AM, Bryan McQuade wrote:
I had a conversation with a well known hosting provider recently and
they told me they use the default Apache configuration for their
shared hosting service. When I asked if they provide gzip as an option
for their users, they said no, since it was not en
44 matches
Mail list logo
