Re: [PHP] mysql_connect noob question

[Richard Quadling]

Completely different function call().

mysql_connect() - the port is part of the host.

*server*

The MySQL server. It can also include a port number. e.g. "hostname:port"
or a path to a local socket e.g. ":/path/to/socket" for the localhost.

If the PHP directive
mysql.default_hostis
undefined (default), then the default value is 'localhost:3306'. In
SQL
safe mode , this parameter
is ignored and value 'localhost:3306' is always used.


mysqli_connect() - the port is a parameter.



I think you got the answers to the question you asked.




On 23 April 2013 18:14, Jim Giner  wrote:

> On 4/23/2013 10:39 AM, Glob Design Info wrote:
>
>> Well all, it turns out the *correct* answer to my question, which no one
>> answered, and which only degenerated into a kindergarten-like argument is:
>>
>> "You need to add the port # to the *end* of the mysql_connect() call".
>>
>> i.e.:
>>
>> $link = mysqli_connect( $host, &user, pass, $database, $port );
>>
>> Glad to see the maturity level of posters on this list, as in most of IT
>> these days is that of a bunch of squabling 5-year olds.
>>
>> On 4/23/13 5:47 AM, Tedd Sperling wrote:
>>
>>> On Apr 21, 2013, at 3:33 PM, Glob Design Info 
>>> wrote:
>>>
>>>  What question did I not answer?

>>>
>>> That proves that you're not listening -- you are total waste of time
>>> for anyone trying to help.
>>>
>>> Welcome to my ignore file.
>>>
>>> tedd
>>>
>>> _
>>> tedd.sperl...@gmail.com
>>> http://sperling.com
>>>
>> Tedd - you got off easy on this post.  You should have seen the shouting
> tirade I received offline from this guy.  What a putz!
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY

[PHP] IE 10 bug?

[Jim Giner]

I know - it sounds OT, but listen.

I have a form that has a "sign in " button which attempts to sent the 
user to a form in a password-protected folder.  In order to get there 
the user must provide credentials.  Once there the receiving script 
simply sets a session var and does a header() back to the calling 
script, where because of the session var that was set, a new group of 
buttons are visible for the user to click.


Well, M$ did an update last week on me and now IE10 is acting 
differently in the above scenario.  Instead of my screen showing me back 
on my original menu screen it shows some other application window, 
probably the next one in z-order sequence.(?)  It looks like my app 
crashed or something since my IE is now behind the other appls sometimes.


Has anyone else seen this, and if so, how does one counter it?

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

[PHP] Updated PHP breaks processing-intense Procedure

[Ken Kixmoeller]

Hey - --

I have a huge screen -- to make it simple for the user, it does 100s of
calls to MySQL and has 1,000s (literally) of POST variables.

We have done extensive research and see that upgrading from php 5.1.6-27 to
5.1.6-39 is the thing that caused it to break. All other issues (Apache,
PHP and MySQL configuration and Versions) have been methodically ruled out.


Anybody experience this? Heard of it? Suggest a repair (other than changing
my screen)?

*** Please don't tell me to redesign the screen -- this may come, but now
is an urgent situation.***

Worked fine in prior versions for the last 3 years.

Thanks,

Ken

Re: [PHP] Updated PHP breaks processing-intense Procedure

[David OBrien]

On Wed, Apr 24, 2013 at 5:09 PM, Ken Kixmoeller  wrote:

> Hey - --
>
> I have a huge screen -- to make it simple for the user, it does 100s of
> calls to MySQL and has 1,000s (literally) of POST variables.
>
> We have done extensive research and see that upgrading from php 5.1.6-27 to
> 5.1.6-39 is the thing that caused it to break. All other issues (Apache,
> PHP and MySQL configuration and Versions) have been methodically ruled out.
>
>
> Anybody experience this? Heard of it? Suggest a repair (other than changing
> my screen)?
>
> *** Please don't tell me to redesign the screen -- this may come, but now
> is an urgent situation.***
>
> Worked fine in prior versions for the last 3 years.
>
> Thanks,
>
> Ken
>

Looks like they fixed the bug that allowed that to work...
php-common-5.1.6-32.el5.x86_64
 [153 KiB]*Changelog* by Joe Orton (2012-02-02): - add security fix for
CVE-2012-0830 (#786756)
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0830

Re: [PHP] Updated PHP breaks processing-intense Procedure

[Ken Kixmoeller]

>From the link: "The php_register_variable_ex function in php_variables.c in
PHP 5.3.9 allows remote attackers to execute arbitrary code via a request
containing a large number of variables, related to improper handling of
array variables. NOTE: this vulnerability exists because of an incorrect
fix"

===

I wondered if it was memory handling, but what is it (I wonder out loud)
that could be "improper" about my array handling. No error messages are
thrown.

Ken


On Wed, Apr 24, 2013 at 4:14 PM, David OBrien  wrote:

> On Wed, Apr 24, 2013 at 5:09 PM, Ken Kixmoeller wrote:
>
>> Hey - --
>>
>> I have a huge screen -- to make it simple for the user, it does 100s of
>> calls to MySQL and has 1,000s (literally) of POST variables.
>>
>> We have done extensive research and see that upgrading from php 5.1.6-27
>> to
>> 5.1.6-39 is the thing that caused it to break. All other issues (Apache,
>> PHP and MySQL configuration and Versions) have been methodically ruled
>> out.
>>
>>
>> Anybody experience this? Heard of it? Suggest a repair (other than
>> changing
>> my screen)?
>>
>> *** Please don't tell me to redesign the screen -- this may come, but now
>> is an urgent situation.***
>>
>> Worked fine in prior versions for the last 3 years.
>>
>> Thanks,
>>
>> Ken
>>
>
> Looks like they fixed the bug that allowed that to work...
> php-common-5.1.6-32.el5.x86_64
>  [153 KiB] *Changelog* by Joe Orton (2012-02-02): - add security fix for
> CVE-2012-0830 (#786756)
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0830
>
>
>

Re: [PHP] Updated PHP breaks processing-intense Procedure

[David OBrien]

On Wed, Apr 24, 2013 at 5:14 PM, David OBrien  wrote:

> On Wed, Apr 24, 2013 at 5:09 PM, Ken Kixmoeller wrote:
>
>> Hey - --
>>
>> I have a huge screen -- to make it simple for the user, it does 100s of
>> calls to MySQL and has 1,000s (literally) of POST variables.
>>
>> We have done extensive research and see that upgrading from php 5.1.6-27
>> to
>> 5.1.6-39 is the thing that caused it to break. All other issues (Apache,
>> PHP and MySQL configuration and Versions) have been methodically ruled
>> out.
>>
>>
>> Anybody experience this? Heard of it? Suggest a repair (other than
>> changing
>> my screen)?
>>
>> *** Please don't tell me to redesign the screen -- this may come, but now
>> is an urgent situation.***
>>
>> Worked fine in prior versions for the last 3 years.
>>
>> Thanks,
>>
>> Ken
>>
>
> Looks like they fixed the bug that allowed that to work...
> php-common-5.1.6-32.el5.x86_64
>  [153 KiB] *Changelog* by Joe Orton (2012-02-02): - add security fix for
> CVE-2012-0830 (#786756)
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0830
>
>
>

*I looked around google some more and found there is a hard limit of 1000
post variables in 5.1.6*

After weeks of using it, a problem was reported about just one function of
the app that would sometimes return a blank screen. It took me hours of
debugging (read: echo) to figure out what's going on, digging through some
old PHP code (fun!): It appeared that only 1000 post variables arrived on
the server. (Well, 1006 actually, but 2 were added by PHP, and that sounded
like a PHP-style limitation of 1000.) A quick google lookup revealed that
PHP introduced a new feature where it would limit the number of post
variables. For safety reasons.

The variable is called "max_input_vars" with a default of 1000. PHP states
that this feature was introduced in 5.3.9, but I'm running 5.1.6 and the
limit is enforced.

Because the server is for production, it was running with on-screen
warnings turned off. PHP says that it "prints a warning and cuts". For me,
that's a real WTF. A post request should be processed as all-or-nothing.
It should instead refuse the request completely. But for a technology named
"personal home page" the priorities are different.

Re: [PHP] Updated PHP breaks processing-intense Procedure

[Ken Kixmoeller]

Thanks so much. Yes, we found that because PHP threw an error that said
that explicitly. A bit of research led us to add a line to php.ini to set
the "max_input_vars" to a higher level.

At first, that appeared to fix it (on the development machine). The
appearance is wrong; it is still broken. No errors are being thrown. We are
baffled.

Ken


On Wed, Apr 24, 2013 at 4:23 PM, David OBrien  wrote:

> On Wed, Apr 24, 2013 at 5:14 PM, David OBrien  wrote:
>
>> On Wed, Apr 24, 2013 at 5:09 PM, Ken Kixmoeller wrote:
>>
>>> Hey - --
>>>
>>> I have a huge screen -- to make it simple for the user, it does 100s of
>>> calls to MySQL and has 1,000s (literally) of POST variables.
>>>
>>> We have done extensive research and see that upgrading from php 5.1.6-27
>>> to
>>> 5.1.6-39 is the thing that caused it to break. All other issues (Apache,
>>> PHP and MySQL configuration and Versions) have been methodically ruled
>>> out.
>>>
>>>
>>> Anybody experience this? Heard of it? Suggest a repair (other than
>>> changing
>>> my screen)?
>>>
>>> *** Please don't tell me to redesign the screen -- this may come, but now
>>> is an urgent situation.***
>>>
>>> Worked fine in prior versions for the last 3 years.
>>>
>>> Thanks,
>>>
>>> Ken
>>>
>>
>> Looks like they fixed the bug that allowed that to work...
>> php-common-5.1.6-32.el5.x86_64
>>  [153 KiB] *Changelog* by Joe Orton (2012-02-02): - add security fix for
>> CVE-2012-0830 (#786756)
>> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0830
>>
>>
>>
>
> *I looked around google some more and found there is a hard limit of 1000
> post variables in 5.1.6*
>
> After weeks of using it, a problem was reported about just one function of
> the app that would sometimes return a blank screen. It took me hours of
> debugging (read: echo) to figure out what's going on, digging through some
> old PHP code (fun!): It appeared that only 1000 post variables arrived on
> the server. (Well, 1006 actually, but 2 were added by PHP, and that sounded
> like a PHP-style limitation of 1000.) A quick google lookup revealed that
> PHP introduced a new feature where it would limit the number of post
> variables. For safety reasons.
>
> The variable is called "max_input_vars" with a default of 1000. PHP states
> that this feature was introduced in 5.3.9, but I'm running 5.1.6 and the
> limit is enforced.
>
> Because the server is for production, it was running with on-screen
> warnings turned off. PHP says that it "prints a warning and cuts". For me,
> that's a real WTF. A post request should be processed as all-or-nothing.
> It should instead refuse the request completely. But for a technology
> named "personal home page" the priorities are different.
>
>
>

Re: [PHP] Updated PHP breaks processing-intense Procedure

[Jim Lucas]

On 04/24/2013 02:40 PM, Ken Kixmoeller wrote:

Thanks so much. Yes, we found that because PHP threw an error that said
that explicitly. A bit of research led us to add a line to php.ini to set
the "max_input_vars" to a higher level.

At first, that appeared to fix it (on the development machine). The
appearance is wrong; it is still broken. No errors are being thrown. We are
baffled.

Ken


If you have the Suhosin patch installed, it also introduces other limits 
to GET and POST variable counts within PHP.


--
Jim Lucas

http://www.cmsws.com/
http://www.cmsws.com/examples/

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

Re: [PHP] Updated PHP breaks processing-intense Procedure

[Ken Kixmoeller]

Thanks, Jim ---

Is this different from the "max_input_vars" discussion above? (from David
OBrien)

Ken


On Wed, Apr 24, 2013 at 5:06 PM, Jim Lucas  wrote:

> On 04/24/2013 02:40 PM, Ken Kixmoeller wrote:
>
>> Thanks so much. Yes, we found that because PHP threw an error that said
>> that explicitly. A bit of research led us to add a line to php.ini to set
>> the "max_input_vars" to a higher level.
>>
>> At first, that appeared to fix it (on the development machine). The
>> appearance is wrong; it is still broken. No errors are being thrown. We
>> are
>> baffled.
>>
>> Ken
>>
>
> If you have the Suhosin patch installed, it also introduces other limits
> to GET and POST variable counts within PHP.
>
> --
> Jim Lucas
>
> http://www.cmsws.com/
> http://www.cmsws.com/examples/
>

Re: [PHP] Updated PHP breaks processing-intense Procedure

[Jim Lucas]

On 04/24/2013 03:24 PM, Ken Kixmoeller wrote:

Thanks, Jim ---

Is this different from the "max_input_vars" discussion above? (from David
OBrien)


yes.  For example...

php.ini:[suhosin]
php.ini:;suhosin.log.syslog =
php.ini:;suhosin.log.syslog.facility =
php.ini:;suhosin.log.syslog.priority =
php.ini:;suhosin.log.sapi =
php.ini:;suhosin.log.script =
php.ini:;suhosin.log.phpscript = 0
php.ini:;suhosin.log.script.name =
php.ini:; variables registered in the current scope: SUHOSIN_ERRORCLASS and
php.ini:; SUHOSIN_ERROR. The first one is the alert class and the second 
variable is

php.ini:;suhosin.log.phpscript.name =
php.ini:;suhosin.log.phpscript.is_safe = Off
php.ini:;suhosin.log.use-x-forwarded-for = Off
php.ini:;suhosin.executor.max_depth = 0
php.ini:;suhosin.executor.include.max_traversal = 0
php.ini:;suhosin.executor.include.whitelist =
php.ini:;suhosin.executor.include.blacklist =
php.ini:;suhosin.executor.func.whitelist =
php.ini:;suhosin.executor.func.blacklist =
php.ini:;suhosin.executor.eval.whitelist =
php.ini:;suhosin.executor.eval.blacklist =
php.ini:;suhosin.executor.disable_eval = Off
php.ini:;suhosin.executor.disable_emodifier = Off
php.ini:; by default in Suhosin >= 0.9.6. Allowing symlink() while 
open_basedir is used

php.ini:;suhosin.executor.allow_symlink = Off
php.ini:; If you fear that Suhosin breaks your application, you can 
activate Suhosin's
php.ini:; simulation mode with this flag. When Suhosin runs in 
simulation mode,

php.ini:;suhosin.simulation = Off
php.ini:; first. It always uses resource slot 0. If Suhosin got this 
slot assigned APC
php.ini:; will overwrite the information Suhosin stores in this slot. 
When this flag is
php.ini:; set Suhosin will request 2 Slots and use the second one. This 
allows working

php.ini:;suhosin.apc_bug_workaround = Off
php.ini:;suhosin.sql.bailout_on_error = Off
php.ini:;suhosin.sql.user_prefix =
php.ini:;suhosin.sql.user_postfix =
php.ini:;suhosin.multiheader = Off
php.ini:suhosin.mail.protect = 1
php.ini:; memory_limit to whatever value they want. Suhosin changes this 
fact and
php.ini:; that Suhosin will disallows scripts setting the memory_limit 
to a value above

php.ini:;suhosin.memory_limit = 0
php.ini:suhosin.session.encrypt = Off
php.ini:;suhosin.session.cryptkey =
php.ini:;suhosin.session.cryptua = On
php.ini:;suhosin.session.cryptdocroot = On
php.ini:;suhosin.session.cryptraddr = 0
php.ini:; session. The difference to suhosin.session.cryptaddr is, that 
the IP is not

php.ini:;suhosin.session.checkraddr = 0
php.ini:;suhosin.cookie.encrypt = 0
php.ini:;suhosin.cookie.cryptkey =
php.ini:;suhosin.cookie.cryptua = On
php.ini:;suhosin.cookie.cryptdocroot = On
php.ini:;suhosin.cookie.cryptraddr = 0
php.ini:; cookie. The difference to suhosin.cookie.cryptaddr is, that 
the IP is not

php.ini:;suhosin.cookie.checkraddr = 0
php.ini:;suhosin.cookie.cryptlist =
php.ini:;suhosin.cookie.plainlist =
php.ini:; Defines the reaction of Suhosin on a filter violation.
php.ini:;suhosin.filter.action =
php.ini:;suhosin.cookie.max_array_depth = 50
php.ini:;suhosin.cookie.max_array_index_length = 64
php.ini:;suhosin.cookie.max_name_length = 64
php.ini:;suhosin.cookie.max_totalname_length = 256
php.ini:;suhosin.cookie.max_value_length = 1
php.ini:;suhosin.cookie.max_vars = 100
php.ini:;suhosin.cookie.disallow_nul = 1
php.ini:;suhosin.get.max_array_depth = 50
php.ini:;suhosin.get.max_array_index_length = 64
php.ini:;suhosin.get.max_name_length = 64
php.ini:;suhosin.get.max_totalname_length = 256
php.ini:;suhosin.get.max_value_length = 512
php.ini:;suhosin.get.max_vars = 100
php.ini:;suhosin.get.disallow_nul = 1
php.ini:;suhosin.post.max_array_depth = 50
php.ini:;suhosin.post.max_array_index_length = 64
php.ini:;suhosin.post.max_name_length = 64
php.ini:;suhosin.post.max_totalname_length = 256
php.ini:suhosin.post.max_value_length = 2048000
php.ini:suhosin.post.max_vars = 500
php.ini:;suhosin.post.disallow_nul = 1
php.ini:;suhosin.request.max_array_depth = 50
php.ini:;suhosin.request.max_array_index_length = 64
php.ini:;suhosin.request.max_totalname_length = 256
php.ini:suhosin.request.max_value_length = 2048000
php.ini:;suhosin.request.max_vars = 200
php.ini:;suhosin.request.max_varname_length = 64
php.ini:;suhosin.request.disallow_nul = 1
php.ini:;suhosin.upload.max_uploads = 25
php.ini:;suhosin.upload.disallow_elf = 1
php.ini:;suhosin.upload.disallow_binary = 0
php.ini:;suhosin.upload.remove_binary = 0
php.ini:;suhosin.upload.verification_script =
php.ini:;suhosin.session.max_id_length = 128
php.ini:; Undocumented: Controls if suhosin coredumps when the optional 
suhosin patch

php.ini:;suhosin.coredump = Off
php.ini:;suhosin.protectkey = 1
php.ini:; Controls if suhosin loads in stealth mode when it is not the only
php.ini:;suhosin.stealth = 1
php.ini:; Controls if suhosin's ini directives are changeable per directory
php.ini:;suhosin.perdir = "0"




Ken


On Wed, Apr 24, 2013 at 5:06 PM, Jim Lucas  wrote:


On 04/24/2013 02:40 PM, Ken Kixmoeller

Re: [PHP] Updated PHP breaks processing-intense Procedure

[Ken Kixmoeller]

Thank you very much, Jim ---


On Wed, Apr 24, 2013 at 5:34 PM, Jim Lucas  wrote:

> On 04/24/2013 03:24 PM, Ken Kixmoeller wrote:
>
>> Thanks, Jim ---
>>
>> Is this different from the "max_input_vars" discussion above? (from David
>> OBrien)
>>
>
> yes.  For example...
>
> php.ini:[suhosin]
> php.ini:;suhosin.log.syslog =
> php.ini:;suhosin.log.syslog.**facility =
> php.ini:;suhosin.log.syslog.**priority =
> php.ini:;suhosin.log.sapi =
> php.ini:;suhosin.log.script =
> php.ini:;suhosin.log.phpscript = 0
> php.ini:;suhosin.log.script.**name  =
> php.ini:; variables registered in the current scope: SUHOSIN_ERRORCLASS and
> php.ini:; SUHOSIN_ERROR. The first one is the alert class and the second
> variable is
> php.ini:;suhosin.log.**phpscript.name =
> php.ini:;suhosin.log.**phpscript.is_safe = Off
> php.ini:;suhosin.log.use-x-**forwarded-for = Off
> php.ini:;suhosin.executor.max_**depth = 0
> php.ini:;suhosin.executor.**include.max_traversal = 0
> php.ini:;suhosin.executor.**include.whitelist =
> php.ini:;suhosin.executor.**include.blacklist =
> php.ini:;suhosin.executor.**func.whitelist =
> php.ini:;suhosin.executor.**func.blacklist =
> php.ini:;suhosin.executor.**eval.whitelist =
> php.ini:;suhosin.executor.**eval.blacklist =
> php.ini:;suhosin.executor.**disable_eval = Off
> php.ini:;suhosin.executor.**disable_emodifier = Off
> php.ini:; by default in Suhosin >= 0.9.6. Allowing symlink() while
> open_basedir is used
> php.ini:;suhosin.executor.**allow_symlink = Off
> php.ini:; If you fear that Suhosin breaks your application, you can
> activate Suhosin's
> php.ini:; simulation mode with this flag. When Suhosin runs in simulation
> mode,
> php.ini:;suhosin.simulation = Off
> php.ini:; first. It always uses resource slot 0. If Suhosin got this slot
> assigned APC
> php.ini:; will overwrite the information Suhosin stores in this slot. When
> this flag is
> php.ini:; set Suhosin will request 2 Slots and use the second one. This
> allows working
> php.ini:;suhosin.apc_bug_**workaround = Off
> php.ini:;suhosin.sql.bailout_**on_error = Off
> php.ini:;suhosin.sql.user_**prefix =
> php.ini:;suhosin.sql.user_**postfix =
> php.ini:;suhosin.multiheader = Off
> php.ini:suhosin.mail.protect = 1
> php.ini:; memory_limit to whatever value they want. Suhosin changes this
> fact and
> php.ini:; that Suhosin will disallows scripts setting the memory_limit to
> a value above
> php.ini:;suhosin.memory_limit = 0
> php.ini:suhosin.session.**encrypt = Off
> php.ini:;suhosin.session.**cryptkey =
> php.ini:;suhosin.session.**cryptua = On
> php.ini:;suhosin.session.**cryptdocroot = On
> php.ini:;suhosin.session.**cryptraddr = 0
> php.ini:; session. The difference to suhosin.session.cryptaddr is, that
> the IP is not
> php.ini:;suhosin.session.**checkraddr = 0
> php.ini:;suhosin.cookie.**encrypt = 0
> php.ini:;suhosin.cookie.**cryptkey =
> php.ini:;suhosin.cookie.**cryptua = On
> php.ini:;suhosin.cookie.**cryptdocroot = On
> php.ini:;suhosin.cookie.**cryptraddr = 0
> php.ini:; cookie. The difference to suhosin.cookie.cryptaddr is, that the
> IP is not
> php.ini:;suhosin.cookie.**checkraddr = 0
> php.ini:;suhosin.cookie.**cryptlist =
> php.ini:;suhosin.cookie.**plainlist =
> php.ini:; Defines the reaction of Suhosin on a filter violation.
> php.ini:;suhosin.filter.action =
> php.ini:;suhosin.cookie.max_**array_depth = 50
> php.ini:;suhosin.cookie.max_**array_index_length = 64
> php.ini:;suhosin.cookie.max_**name_length = 64
> php.ini:;suhosin.cookie.max_**totalname_length = 256
> php.ini:;suhosin.cookie.max_**value_length = 1
> php.ini:;suhosin.cookie.max_**vars = 100
> php.ini:;suhosin.cookie.**disallow_nul = 1
> php.ini:;suhosin.get.max_**array_depth = 50
> php.ini:;suhosin.get.max_**array_index_length = 64
> php.ini:;suhosin.get.max_name_**length = 64
> php.ini:;suhosin.get.max_**totalname_length = 256
> php.ini:;suhosin.get.max_**value_length = 512
> php.ini:;suhosin.get.max_vars = 100
> php.ini:;suhosin.get.disallow_**nul = 1
> php.ini:;suhosin.post.max_**array_depth = 50
> php.ini:;suhosin.post.max_**array_index_length = 64
> php.ini:;suhosin.post.max_**name_length = 64
> php.ini:;suhosin.post.max_**totalname_length = 256
> php.ini:suhosin.post.max_**value_length = 2048000
> php.ini:suhosin.post.max_vars = 500
> php.ini:;suhosin.post.**disallow_nul = 1
> php.ini:;suhosin.request.max_**array_depth = 50
> php.ini:;suhosin.request.max_**array_index_length = 64
> php.ini:;suhosin.request.max_**totalname_length = 256
> php.ini:suhosin.request.max_**value_length = 2048000
> php.ini:;suhosin.request.max_**vars = 200
> php.ini:;suhosin.request.max_**varname_length = 64
> php.ini:;suhosin.request.**disallow_nul = 1
> php.ini:;suhosin.upload.max_**uploads = 25
> php.ini:;suhosin.upload.**disallow_elf = 1
> php.ini:;suhosin.upload.**disallow_binary = 0
> php.ini:;suhosin.upload.**remove_binary = 0
> php.ini:;suhosin.upload.**verification_script =
> php.ini:;suhosin.se

Re: [PHP] Load testing an app

[tamouse mailing lists]

On Tue, Apr 23, 2013 at 8:04 AM, Andrew Ballard  wrote:
> On Tue, Apr 23, 2013 at 2:29 AM, Adam Richardson  wrote:
>> On Mon, Apr 22, 2013 at 10:41 PM, Andrew Ballard  wrote:
>>> The other developer in our office spent some time profiling the site with
>>> xdebug and found that an exec() call to netsh used on a couple pages seems
>>> to take 2-4 seconds to complete. Unfortunately, those exec() calls are the
>>> one function that we cannot test in our development environment.

I'm wondering if it would be possible to carve out the part doing the
netsh calls so they're not part of your web application's stack, and
make them an asynchronous part?

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

Re: [PHP] Load testing an app

[Andrew Ballard]

On Apr 24, 2013 9:46 PM, "tamouse mailing lists" 
wrote:
>
> On Tue, Apr 23, 2013 at 8:04 AM, Andrew Ballard 
wrote:
> > On Tue, Apr 23, 2013 at 2:29 AM, Adam Richardson 
wrote:
> >> On Mon, Apr 22, 2013 at 10:41 PM, Andrew Ballard 
wrote:
> >>> The other developer in our office spent some time profiling the site
with
> >>> xdebug and found that an exec() call to netsh used on a couple pages
seems
> >>> to take 2-4 seconds to complete. Unfortunately, those exec() calls
are the
> >>> one function that we cannot test in our development environment.
>
> I'm wondering if it would be possible to carve out the part doing the
> netsh calls so they're not part of your web application's stack, and
> make them an asynchronous part?

Possibly, but it needs to be as close as possible to real time. We've been
looking into caching the results for a short time (15sec?) so concurrent
requests can share results. The problem right now is that we can't seem to
duplicate the issue we were having, so it's impossible to know for sure
whether any solution we try actually solves the problem.

Andrew