Quantcast
Channel: Serverphorums.com
Viewing all 23908 articles
Browse latest View live

Re: x-real-ip issue

$
0
0
That was it! I added "set_real_ip_from 127.0.0.1/32;" and now I'm getting
the results I expected. Thank you!


On Mon, Aug 28, 2017 at 4:27 PM, Richard Stanway <r1ch+nginx@teamliquid.net>
wrote:

> You're connecting to localhost (127.0.0.1) and your set_real_ip_from only
> accepts X-Forwarded-For from 172.0.0.0/8.
>
> On Mon, Aug 28, 2017 at 8:25 PM, CJ Ess <zxcvbn4038@gmail.com> wrote:
>
>> I've been struggling all day with this, I'm missing something, hoping
>> someone can point out what I'm doing wrong w/ the realip module:
>>
>> nginx.conf:
>> ...
>> log_format xyz '$remote_addr - $remote_user [$time_iso8601] '
>> '"$request" $status $body_bytes_sent '
>> '"$http_referer" "$http_user_agent"
>> "$http_x_forwarded_for" $http_x_real_ip';
>>
>> access_log /var/log/nginx/access.log xyz;
>> ...
>> real_ip_header X-Forwarded-For;
>> real_ip_recursive on;
>> set_real_ip_from 172.0.0.0/8;
>> ...
>>
>>
>> Test command I'm running:
>> curl -v -v -v -H "Host: www.test.com" -H "X-Forwarded-For: 9.1.2.3,
>> 172.16.9.92" http://127.0.0.1/cheese
>>
>>
>> What I see in the error log:
>> 127.0.0.1 - - [2017-08-28T14:20:38-04:00] "GET /cheese HTTP/1.1" 502 166
>> "-" "curl/7.29.0" "9.1.2.3, 172.16.9.92" -
>>
>>
>> I'm expecting that either $remote_addr or $http_x_real_ip be 9.1.2.3, but
>> the former is 127.0.0.1 and the latter is null.
>>
>> I've tried two versions of Nginx including the latest, so pretty sure its
>> an issue with my config. The config test is successful, no errors in the
>> error log (level debug), the 502 status code is expected and shouldn't
>> impact the realip module.
>>
>>
>> _______________________________________________
>> nginx mailing list
>> nginx@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

$
0
0
Hi Sara, hi Frederik,



Thinking more about this I came to change my vote (and for that reason I’ll take back the suggestion to include it into 7.2):


The array API is the better API and allows for healthier future growth so we should pursue that option
There is a (very ugly) workaround to set a same site policy by misusing the “session.cookie_path” or “session.cookie_domain” setting (e.g. set it to “/; SameSite=Strict”, you are welcome, Internet).


cu,

Lars





On 28.08.17, 18:20, "Sara Golemon" <php@golemon.com on behalf of pollita@php.net> wrote:



On Mon, Aug 28, 2017 at 12:10 PM, Frederik Bosch | Genkgo <f.bosch@genkgo.nl> wrote:

Little misunderstanding then. I agree we can better have this PHP 7.3 and take some time for it. Current votes also suggest that we should go for the array argument implementation. Since there is only a PR for the extra argument implementation, it will also take time to have the PR for the array argument implementation ready. Taken that into account, we should not want this in 7.2.

Indeed, yes. Assuming the votes continue on this sharp lean towards the array option, we should just forget all notions of trying to sneak this into 7.2.



Direct calls in 7.2 and earlier can easily fall back on calling header('Set-Cookie: ...'); manually, while sessions support is slightly more complex, but still doable from userspace. I expect if need is deemed high for this, a drop-in composer package can do 90% of the work automatically.

-Sara

Re: AW: [PHP] Hello

$
0
0
Excuse me for top-posting but my email client is stupid.

Memory stacks are definitely stacks and that is a very appropriate use
of the term.

> Alan Feuerbacher <mailto:alanf00@comcast.net>
> Monday, August 28, 2017 1:01 PM
> On 8/28/2017 12:34 PM, Sam Hobbs wrote:
>>
>>> What is a Stack?
>>
>> I have been programming since 1971
>
> So you're an old guy like me.
>
>> and I have seen the term "stack" but never taken the time to look it
>> up. I assume it is another of many words that are used just to be
>> different and that other terms (such as library or API) would also work.
>
> Having read some of the later replies, now I get it.
>
> Until now, "stack" in computer context to me meant "memory stack".
>
> Alan
>
> Sam Hobbs <mailto:Sam@SimpleSamples.info>
> Monday, August 28, 2017 11:34 AM
>
>
>
>
> I have been programming since 1971 and I have seen the term "stack"
> but never taken the time to look it up. I assume it is another of many
> words that are used just to be different and that other terms (such as
> library or API) would also work.
>
> Alan Feuerbacher <mailto:alanf00@comcast.net>
> Monday, August 28, 2017 11:15 AM
> On 8/28/2017 11:49 AM, Tobias Fichtner wrote:
>
> Hi Tobias,
>
>> PHP is maintained in different versions (5.6, 7, 7.1.)
>>
>> Mainpage for information is under https://php.net/
>
> Yes, I've looked at that a lot.
>
>> There are many Stacks for Web development for different Platforms, my
>> personal favourite for windows is wpn-xm (https://wpn-xm.org) with a
>> mass (if u need) extensions.
>
> What is a Stack?
>
> I'm not going to be doing Web development (at least, not for the
> foreseeable future), and I'm getting away from Windows into Linux.
>
>> You can use PHP as CLI Version too, a GTK (outdated) version is also
>> available.
>
> I've been using PHP exclusively in the CLI version, as a language much
> like C but with a lot of special features like XMLReader. It's also
> higher-level than C, which makes many tasks easier.
>
> Alan
>
> Tobias Fichtner <mailto:info@tobiasfichtner.com>
> Monday, August 28, 2017 10:49 AM
> Hi Alan,
>
> PHP is maintained in different versions (5.6, 7, 7.1.)
>
> Mainpage for information is under https://php.net/
>
> There are many Stacks for Web development for different Platforms, my
> personal favourite for windows is wpn-xm (https://wpn-xm.org) with a
> mass (if u need) extensions.
>
> You can use PHP as CLI Version too, a GTK (outdated) version is also
> available.
>
>
> Regards,
> Tobias
>
>
> -----Ursprüngliche Nachricht-----
> Von: Alan Feuerbacher [mailto:alanf00@comcast.net]
> Gesendet: 28 August 2017 19:40
> An: php-general@lists.php.net
> Betreff: Re: [PHP] Hello
>
> Just champing at the bit, eh? :-)
>
> Well here's one: Is PHP actively maintained, or going into obsolescence?
>
> Alan
>
> --
> PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
> http://www.php.net/unsub.php
>
>
>
> Alan Feuerbacher <mailto:alanf00@comcast.net>
> Monday, August 28, 2017 10:40 AM
>
>
> Just champing at the bit, eh? :-)
>
> Well here's one: Is PHP actively maintained, or going into obsolescence?
>
> Alan
>

Re: AW: [PHP] Hello

$
0
0
On Mon, 2017-08-28 at 15:55 -0500, Larry Garfield wrote:
> On 08/28/2017 01:15 PM, Alan Feuerbacher wrote:
> > On 8/28/2017 11:49 AM, Tobias Fichtner wrote:
> >
> > Hi Tobias,
> >
> > > PHP is maintained in different versions (5.6, 7, 7.1.)
> > >
> > > Mainpage for information is under https://php.net/
> >
> > Yes, I've looked at that a lot.
> >
> > > There are many Stacks for Web development for different
> > > Platforms, my
> > > personal favourite for windows is wpn-xm (https://wpn-xm.org)
> > > with a
> > > mass (if u need) extensions.
> >
> > What is a Stack?
> >
> > I'm not going to be doing Web development (at least, not for the
> > foreseeable future), and I'm getting away from Windows into Linux.
> >
> > > You can use PHP as CLI Version too, a GTK (outdated) version is
> > > also
> > > available.
> >
> > I've been using PHP exclusively in the CLI version, as a language
> > much
> > like C but with a lot of special features like XMLReader. It's also
> > higher-level than C, which makes many tasks easier.
> >
> > Alan
>
> PHP is alive and well, runs about 80% of the web, and has new
> versions
> of the language released regularly every fall.  There's PHP community
> conferences just about every month or more somewhere in the world and
> Meetup groups in almost every major city, plus some minor ones.
>
> I work at a hosting company, Platform.sh, and people launch new PHP
> sites with us on a daily basis.  Most are built on some existing
> application or framework -- Drupal, Symfony, Magneto, WordPress,
> Laravel, etc. -- as is typical of PHP these days.  We also host Node,
> Ruby, Python, and Go, but PHP is by far the biggest business driver.
>
> Our CLI tool is written in PHP.  Most of our backend software Python,
> with a bit of Go thrown in.  At some point we'll probably move the
> CLI
> to Go to make it easier to install for our non-PHP users, but for now
> it
> works quite well.
>
> PHP isn't the right tool for every job by any means, but if you're
> working on the web it's absolutely a viable and popular tool.  If
> you're
> doing strictly command line work, PHP can certainly do the job but
> Python or Go are equally viable, I'd say; that decision should be
> made
> based on what you find comfortable to work with and what your other
> systems are using.  (If you have 15 services written in Ruby, use
> Ruby
> for your CLI tools, not PHP.  If you have 12 PHP apps running, a PHP
> CLI
> tool makes total sense.)  If you want a background daemon PHP can do
> that but it's not ideal; I'd personally look toward Go at that point
> but
> there are other plenty of options. 
>
> If you're doing web work, PHP should almost always be a consideration
> as
> it's still the #1 language out there by a wide margin; those "cool
> kids"
> doing "cool things" in Node or Ruby or whatever are a tiny fraction
> of
> the market in comparison. :-)
>
> --Larry Garfield
>
>

Going on from what you've said, PHP isn't always the best choice, but
it can really be used for anything. Couple of the craziest things I've
used it for is to communicate over sockets with an Arduino, and to
process images captured from a webcam to detect the position of an
object. Certainly not the best choice for those tasks, but it just
shows it can be used for really anything!


-- 
Thanks,
Ash

http://www.ashleysheridan.co.uk

Re: [PHP] Hello

$
0
0
Alan Feuerbacher wrote:
> Thanks for the tip. I've hit upon Stackoverflow many times when
> searching for an answer to a problem. Many of the replies are
> unnecessarily testy and terse, but often there's useful information.

And if you try to help others in Stackoverflow then you will get voted
down for no good reason. A tip is, don't try to post a better answer
after a thread is a couple months old. It won't get votes. Yet they
don't want the same question to be posted more than once. So that
creates a contradiction. I read an article written by the creator of
Stack Exchange http://stackexchange.com/ and he sure is judgmental.

Re: Removed health check in combination with load-server-state-from-file (Bug)

$
0
0
Hi Julien and Tim,

Le 28/08/2017 à 10:32, Julien Laffaye a écrit :
> Hello,
>
> I am experiencing the same problem.
> Is this the expected behaviour ? Or is it a bug ?

Yes, it's expected.
One use case is to start all servers in a DOWN state then
programmatically set one or several of them UP once everything is
initialized in the architecture, using the CLI command "set server
<backend>/<server> health up".

>
> Regards,
> Julien
>
> On Sat, Aug 26, 2017 at 2:55 AM, Tim Düsterhus <tim@bastelstu.be
> <mailto:tim@bastelstu.be>> wrote:
>
> Hi
>
> as I did not receive any reply at all to my email from Aug 13 I thought
> I resend it (Quoted below). Can anyone at least verify that my bug
> report is valid? :-)
>
> Tim
>
> Am 13.08.2017 um 13:19 schrieb Tim Düsterhus:
> > Hi
> >
> > I run haproxy with 'load-server-state-from-file'. Before reloading
> > haproxy I dump the state using:
> >
> > echo show servers state |nc -U admin.sock > /etc/haproxy/state/global
> >
> > I noticed a buggy behaviour with this:
> >
> > 1. Check that the backend is 'DOWN'.
> > 2. Dump the state using the command above (the 'DOWN' state is
> written
> > into the file).
> > 3. Remove the health check of the backend.
> > 4. Reload haproxy.
> > 5. The backend will now be 'DOWN' forever, as the initial state taken
> > from the file is 'DOWN' and no health checks are running.
> >
> > I attached an example configuration and an example state file. To
> > reproduce the issue:
> >
> > 1. Start haproxy.
> > 2. Open the Stats page.
> > 3. Place the state file.
> > 4. Remove the 'check' from the configuration.
> > 5. Reload haproxy.
> > 6. Start the backend.
> > 7. Reload the Stats page and notice that the backend still is 'DOWN'.
> >
> > Tim
> >
>
>


--
Cyril Bonté

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2017-08-27

$
0
0
Results for project PHP master, build date 2017-08-27 19:23:36-07:00
commit: a06ba4b
previous commit: a02cbb9
revision date: 2017-08-27 14:13:55+02:00
environment: Haswell-EP
cpu: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB
mem: 128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

-------------------------------------------------------------------------------------------
benchmark relative change since change since current rev run
std_dev* last run baseline with PGO
-------------------------------------------------------------------------------------------
:-| Wordpress 4.2.2 cgi -T10000 0.19% 0.19% 4.16% 9.07%
:-| Drupal 7.36 cgi -T10000 0.14% 0.20% 3.49% 5.73%
:-| MediaWiki 1.23.9 cgi -T5000 0.17% -0.21% 3.90% 4.82%
:-| bench.php cgi -T100 0.00% -0.04% 45.30% -0.44%
:-| micro_bench.php cgi -T10 0.02% 0.12% 28.47% 3.16%
:-| mandelbrot.php cgi -T100 0.01% 0.04% 42.77% 4.54%
-------------------------------------------------------------------------------------------

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2017-08-27/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at:
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

HTTP/1.0 with compression enabled broken again in v1.7.9

$
0
0
Hi!


It seems that a similar issue to the one I originally reported against v1.7.2 is now present in v1.7.9 (the same setup worked fine with v1.7.8):
https://www.mail-archive.com/haproxy@formilux.org/msg24830.html

After upgrading to v1.7.9, requests from a client using HTTP/1.0 with compression enabled in HAProxy now always hang. Usually they hang after receiving 3905 bytes of data, but sometimes also after 11145 bytes (the full response is much larger). After hanging for "timeout client" seconds the rest of the response is received and the request finishes successfully.

Using HTTP/1.1 or turning off compression fixes the issue as before. My backend server is still the same etcd v2.3.7 and the client is a custom application using HTTP/1.0. Issue was confirmed with curl in HTTP/1.0 mode.

I'll be happy to provide additional information if needed.


--
Kristjan

Re: disable request body buffering for file upload

$
0
0
Hi, Reinis has probably covered this but the default php.ini file has a
'File Upload section' with...

; Temporary directory for HTTP uploaded files (will use system default if
not
; specified).
; upload_tmp_dir =

I just uncommented the attribute and set it to a location on our main disk
e.g.

upload_tmp_dir = /opt/tmp


--

The complete solution involved using the http_auth_request_module. So in our
nginx configuration file for big file upload url...

# PHP - file upload - bigf
location /api/bigf/analysis/upload {
auth_request /bigf/auth;
error_page 403 =413 /bigfLowDiskSpace.html;
error_page 413 /bigfTooBigError.html;

fastcgi_request_buffering off; # pass the request straight to php
without buffering
fastcgi_read_timeout 1h;
fastcgi_pass unix:/opt/tmp/php-fpm.sock;

include fastcgi_params;

# Command specific parameters
fastcgi_param PERMITTED_FILETYPE "bigf";
fastcgi_param HOME_FOLDER "/home/instrument";
fastcgi_param DEST_FOLDER "Analysis/Filters";
fastcgi_param SCRIPT_FILENAME $document_root/PHP/uploadFile.php;
}

# from the auth_request directive in the above block

location /bigf/auth {
internal;

fastcgi_pass_request_body off;
fastcgi_pass unix:/opt/tmp/php-fpm.sock;
fastcgi_intercept_errors on;

include fastcgi_params;
fastcgi_param BIGF_UPLOAD_SIZE $content_length;
fastcgi_param BIGF_UPLOAD_MARGIN_BYTES 10737418240; # reject if < 10GB
free after upload
fastcgi_param HOME_FOLDER "/home/instrument";
fastcgi_param DEST_FOLDER "Analysis/Filters";
fastcgi_param CONTENT_LENGTH "";
fastcgi_param SCRIPT_FILENAME $document_root/PHP/bigfAuthUpload.php;
}

# Custom error pages for the error_page directives specified above

location /bigfLowDiskSpace.html {
root /opt/lib/webapp/errorPages;
allow all;
}

location /bigfTooBigError.html {
root /opt/lib/webapp/errorPages;
allow all;
}


---

The bigfAuthUpload.php script just checks the space available on the
destination drive and if the space available minus the approximate incoming
file size (as it includes some bytes from the request header) breaks the
allowed margin (10G in this case) we reject the upload by calling
http_response_code(403). If there is enough space http_response_code(200) is
set which 'authorizes' the upload and allows the uploadFile.php script to be
called.

The error_page 403 =413 redirect allows us to return an error page specific
to the rejected bigfAthUpload.php call.
The error_page 413 redirect allows us to intercept the nginx file size
restriction (we set the directive 'client_max_body_size' to 5G in the server
configuration block of our nginx configuration file), i believe the use of
'fastcgi_intercept_errors on;' in our auth block facilitates this.

By using the fastcgi_pass_request_body off; directive in the 'bigf/auth'
location block the bigfAuthUpload.php script is passed the request header
without the body so we can reject the upload before the request body is
written to /opt/tmp.

The uploadFile.php script effectively copies the file from /opt/tmp to the
destination location. It allows us to handle different $_FILES content
(dependent on the client used to call our upload service we need to cope
with $_FILES['upload'], $_FILES['Data'] and $_FILES['file'] variants to
extract the file name) and to rename the file to cope with duplicates.

The fastcgi_params file we include in the above location blocks include the
lines

Hope this helps someone else out, thanks to everyone who contributed!

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,275567,276176#msg-276176

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Downloading large ( + 5GB ) files in a multipart fashion from S3

$
0
0
Original Problem domain:

Rails/Rack send_data method attempts downloading whole file onto the server
in memory, to then send to the client. This would fail with large files
because the server ran out of memory.

Original Solution:

Use Passenger NGINX to create a proxy_pass between the client and the S3
bucket in a secure way (the client never sees the actual S3 bucket URL -
opted for this over timed URLs, because the clients might need the URL
indefinitely).

New Problem domain:

NGINX handles the download properly, but then once the download gets to
about 5 GB, the download "fails" in Chrome and needs to be "retried" in
order to continue downloading the file. This is due to a restriction S3 has
with downloading files larger than 5 GB.

What I'm hoping to have answered:

Is there a way to initiate a multipart-like download using only NGINX? I
know that there is such thing as a multipart upload, but I would like a
multipart download, of some sort. Because Rails makes a single response to a
request (without doing some very clunky magic to make it do otherwise) I'd
like to use something like the Range header with NGINX, except I don't want
to specify the exact range, because that means I have to make several
responses (which is the case with the header, it looks like, and forces me
into the clunky rails issue).

Thanks for any and all help!

-Stu

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,276177,276177#msg-276177

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: disable request body buffering for file upload

Re: [PHP-DEV] Re: [VOTE] Same Site Cookie RFC

$
0
0
Hi Theodore,

Theodore Brown wrote:
> On Monday, August 28, 2017 4:24 AM Andrea Faulds wrote:
>
>> Correct me if I'm wrong, but wasn't the RFC only put to internals a week
>> ago? That's not a long enough discussion period before opening voting,
>> https://wiki.php.net/rfc/howto says it should be at least 2 weeks.
>
> The current RFC was put to internals on July 24, over a month ago
> (in the "[RFC] samesite cookie implementation" thread).

Ah, you're right of course, my apologies to everyone. I was quite tired
yesterday and I think I misread “2017-07-17” as “2017-08-17”.

--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: HTTP/1.0 with compression enabled broken again in v1.7.9

$
0
0
Le 29/08/2017 à 10:13, Kristjan Koppel a écrit :
> Hi!
>
>
> It seems that a similar issue to the one I originally reported against v1.7.2 is now present in v1.7.9 (the same setup worked fine with v1.7.8):
> https://www.mail-archive.com/haproxy@formilux.org/msg24830.html
>
> After upgrading to v1.7.9, requests from a client using HTTP/1.0 with compression enabled in HAProxy now always hang. Usually they hang after receiving 3905 bytes of data, but sometimes also after 11145 bytes (the full response is much larger). After hanging for "timeout client" seconds the rest of the response is received and the request finishes successfully.
>
> Using HTTP/1.1 or turning off compression fixes the issue as before. My backend server is still the same etcd v2.3.7 and the client is a custom application using HTTP/1.0. Issue was confirmed with curl in HTTP/1.0 mode.
>
> I'll be happy to provide additional information if needed.
>
>

Hi Kristjan,

Damn ! I was pretty sure to have test this use-case when I fixed the
HTTP parser few weeks ago. But clearly not, because the bug is back.

Could you check if the attached patch fixes the bug ?

For my part, I will recheck everything to be sure. This will be my
punishment.

Thanks,
--
Christopher Faulet

[PHP] opcache.dups_fix

$
0
0
Greetings,

Does anyone know much about the opcache option opcache.dups_fix? The
documentation states "This hack should only be enabled to work around
"Cannot redeclare class" errors." We are seeing said errors that can
really only be attributed to an opcache problem. It happens after
deployments, for 1-2 seconds, and the error log will list two different
version of files. We have opcache.revalidate_freq set to 0, so every
request should generate a check on the file.

I'm mainly curious in the potential side effects of enabling the
dups_fix option. Sounds like the solution to our problem, but the
wording in the documentation isn't real encouraging...

Thanks,

--
Joe Koenig
Brecht's Database Solutions
888-437-9326
joe@poweriep.com
http://www.poweriep.com/


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: HTTP/1.0 with compression enabled broken again in v1.7.9

$
0
0
On Tue, Aug 29, 2017 at 04:40:46PM +0200, Christopher Faulet wrote:
> Damn ! I was pretty sure to have test this use-case when I fixed the HTTP
> parser few weeks ago. But clearly not, because the bug is back.
>
> Could you check if the attached patch fixes the bug ?
>
> For my part, I will recheck everything to be sure. This will be my
> punishment.

For your defence I'd admit that this part is one of the most complex if
not the most complex of the whole code, with a number of combinations of
cases which goes beyond imagination and which is not always easy to
automatically reproduce. I feared 1.7 would take 1 year to stabilize,
it will be excellent once 1.8 is released (and this one will take its
role, gnark gnark :-))

willy

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2017-08-28

$
0
0
Results for project PHP master, build date 2017-08-28 19:23:48-07:00
commit: ebb3396
previous commit: a06ba4b
revision date: 2017-08-28 16:56:47+03:00
environment: Haswell-EP
cpu: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB
mem: 128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

-------------------------------------------------------------------------------------------
benchmark relative change since change since current rev run
std_dev* last run baseline with PGO
-------------------------------------------------------------------------------------------
:-| Wordpress 4.2.2 cgi -T10000 0.29% -0.08% 4.08% 8.63%
:-| Drupal 7.36 cgi -T10000 0.21% -0.02% 3.47% 5.68%
:-| MediaWiki 1.23.9 cgi -T5000 0.07% -0.03% 3.87% 4.03%
:-| bench.php cgi -T100 0.06% -0.03% 45.28% -0.38%
:-| micro_bench.php cgi -T10 0.02% 0.01% 28.48% 3.26%
:-| mandelbrot.php cgi -T100 0.01% -0.01% 42.77% 4.56%
-------------------------------------------------------------------------------------------

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2017-08-28/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at:
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] What is the reason that sqlite with icu cannot coexist with intl shared under Windows?

$
0
0
I tried to compile sqlite3 extension with icu for php, but found a comment in ext/pdo_sqlite/config.m4, that is "As long as intl is not shared we can have ICU support". When i tried to compile intl to statical, and found another comment in ext/intl/config.w32, that is "always build as shared - zend_strtod.c/ICU type conflict".
I don't know where the conflict is, can this problem be fixed? Is the sqlite extension in php not support icu?
Expect any replies, Thank you very much!
The snippet in ext/pdo_sqlite/config.m4:
if test "$PHP_INTL" = "yes" && test "$PHP_INTL_SHARED" != "yes"; then
other_flags="$other_flags -DSQLITE_ENABLE_ICU=1"
fi

RE: Removed health check in combination with load-server-state-from-file (Bug)

$
0
0
Hello Cyril,


This also can be achieved by using 'disabled' keyword on server, and update CLI to enable it. Are you sure that using server-state file to keep server DOWN from previous health check is the expected behaviour ?

May be i'm wrong, but when i have a server in DOWN state because of health check, if a disable health check on it, i expected the server to be UP.



________________________________
De : Cyril Bonté <cyril.bonte@free.fr>
Envoyé : mardi 29 août 2017 00:12
À : Julien Laffaye; Tim Düsterhus
Cc : haproxy@formilux.org
Objet : Re: Removed health check in combination with load-server-state-from-file (Bug)

Hi Julien and Tim,

Le 28/08/2017 à 10:32, Julien Laffaye a écrit :
> Hello,
>
> I am experiencing the same problem.
> Is this the expected behaviour ? Or is it a bug ?

Yes, it's expected.
One use case is to start all servers in a DOWN state then
programmatically set one or several of them UP once everything is
initialized in the architecture, using the CLI command "set server
<backend>/<server> health up".

>
> Regards,
> Julien
>
> On Sat, Aug 26, 2017 at 2:55 AM, Tim Düsterhus <tim@bastelstu.be
> <mailto:tim@bastelstu.be>> wrote:
>
> Hi
>
> as I did not receive any reply at all to my email from Aug 13 I thought
> I resend it (Quoted below). Can anyone at least verify that my bug
> report is valid? :-)
>
> Tim
>
> Am 13.08.2017 um 13:19 schrieb Tim Düsterhus:
> > Hi
> >
> > I run haproxy with 'load-server-state-from-file'. Before reloading
> > haproxy I dump the state using:
> >
> > echo show servers state |nc -U admin.sock > /etc/haproxy/state/global
> >
> > I noticed a buggy behaviour with this:
> >
> > 1. Check that the backend is 'DOWN'.
> > 2. Dump the state using the command above (the 'DOWN' state is
> written
> > into the file).
> > 3. Remove the health check of the backend.
> > 4. Reload haproxy.
> > 5. The backend will now be 'DOWN' forever, as the initial state taken
> > from the file is 'DOWN' and no health checks are running.
> >
> > I attached an example configuration and an example state file. To
> > reproduce the issue:
> >
> > 1. Start haproxy.
> > 2. Open the Stats page.
> > 3. Place the state file.
> > 4. Remove the 'check' from the configuration.
> > 5. Reload haproxy.
> > 6. Start the backend.
> > 7. Reload the Stats page and notice that the backend still is 'DOWN'.
> >
> > Tim
> >
>
>


--
Cyril Bonté

Re: HTTP/1.0 with compression enabled broken again in v1.7.9

$
0
0
---- On Tue, 29 Aug 2017 17:40:46 +0300 Christopher Faulet <cfaulet@haproxy.com> wrote ----
> Damn ! I was pretty sure to have test this use-case when I fixed the
> HTTP parser few weeks ago. But clearly not, because the bug is back.
>
> Could you check if the attached patch fixes the bug ?
>
> For my part, I will recheck everything to be sure. This will be my
> punishment.

Hi Christopher,

S*** happens.. :)
This patch does fix my issue. Thanks for all your hard work on this project!


--
Kristjan

Re: Removed health check in combination with load-server-state-from-file (Bug)

$
0
0
> De: "Arnaud Jost" <arnaud@jost.me>
> À: haproxy@formilux.org
> Envoyé: Mercredi 30 Août 2017 10:01:37
> Objet: RE: Removed health check in combination with load-server-state-from-file (Bug)
>
>
>
>
> Hello Cyril,
>
>
> This also can be achieved by using 'disabled' keyword on server, and
> update CLI to enable it. Are you sure that using server-state file
> to keep server DOWN from previous health check is the expected
> behaviour ?

I am sure ;-)

> May be i'm wrong, but when i have a server in DOWN state because of
> health check, if a disable health check on it, i expected the server
> to be UP.

Well health checks or not, the state file reflects the state you want.
You can absolutely imagine cases where health checks were never activated, and someone used the CLI to set a server DOWN. If you save the servers state and reload haproxy, You'd certainly want to have that server still DOWN (which is a different state than DOWN for maintenance, the one set by the "disabled" keyword).

Please avoid top posting ;-)

>
>
>
>
>
>
>
>
> De : Cyril Bonté <cyril.bonte@free.fr>
> Envoyé : mardi 29 août 2017 00:12
> À : Julien Laffaye; Tim Düsterhus
> Cc : haproxy@formilux.org
> Objet : Re: Removed health check in combination with
> load-server-state-from-file (Bug)
>
> Hi Julien and Tim,
>
> Le 28/08/2017 à 10:32, Julien Laffaye a écrit :
> > Hello,
> >
> > I am experiencing the same problem.
> > Is this the expected behaviour ? Or is it a bug ?
>
> Yes, it's expected.
> One use case is to start all servers in a DOWN state then
> programmatically set one or several of them UP once everything is
> initialized in the architecture, using the CLI command "set server
> <backend>/<server> health up".
>
> >
> > Regards,
> > Julien
> >
> > On Sat, Aug 26, 2017 at 2:55 AM, Tim Düsterhus <tim@bastelstu.be
> > < mailto:tim@bastelstu.be >> wrote:
> >
> > Hi
> >
> > as I did not receive any reply at all to my email from Aug 13 I
> > thought
> > I resend it (Quoted below). Can anyone at least verify that my bug
> > report is valid? :-)
> >
> > Tim
> >
> > Am 13.08.2017 um 13:19 schrieb Tim Düsterhus:
> > > Hi
> > >
> > > I run haproxy with 'load-server-state-from-file'. Before
> > > reloading
> > > haproxy I dump the state using:
> > >
> > > echo show servers state |nc -U admin.sock >
> > > /etc/haproxy/state/global
> > >
> > > I noticed a buggy behaviour with this:
> > >
> > > 1. Check that the backend is 'DOWN'.
> > > 2. Dump the state using the command above (the 'DOWN' state is
> > written
> > > into the file).
> > > 3. Remove the health check of the backend.
> > > 4. Reload haproxy.
> > > 5. The backend will now be 'DOWN' forever, as the initial state
> > > taken
> > > from the file is 'DOWN' and no health checks are running.
> > >
> > > I attached an example configuration and an example state file. To
> > > reproduce the issue:
> > >
> > > 1. Start haproxy.
> > > 2. Open the Stats page.
> > > 3. Place the state file.
> > > 4. Remove the 'check' from the configuration.
> > > 5. Reload haproxy.
> > > 6. Start the backend.
> > > 7. Reload the Stats page and notice that the backend still is
> > > 'DOWN'.
> > >
> > > Tim
> > >
> >
> >
>
>
> --
> Cyril Bonté
>
>
Viewing all 23908 articles
Browse latest View live




Latest Images