php-general Digest 13 Aug 2012 07:01:20 -0000 Issue 7919

Topics (messages 318672 through 318678):

Re: PHP session variables
        318672 by: Marco Behnke
        318674 by: Tedd Sperling

Is PHP unsuitable for HTML5 WebSockets?
        318673 by: BRIAN M. FITZPATRICK
        318678 by: Jim Lucas

Re: Too many open files
        318675 by: Al
        318676 by: Matijn Woudt

How to best set per-site PHP session storage under suPHP/WordPress?
        318677 by: Philip Amadeo Saeli

Administrivia:

To subscribe to the digest, e-mail:
        php-general-digest-subscr...@lists.php.net

To unsubscribe from the digest, e-mail:
        php-general-digest-unsubscr...@lists.php.net

To post to the list, e-mail:
        php-gene...@lists.php.net


----------------------------------------------------------------------
--- Begin Message ---
Am 09.08.12 23:16, schrieb Jim Lucas:
> On 08/09/2012 01:45 PM, Tedd Sperling wrote:
>> On Aug 8, 2012, at 5:41 PM, Jim Giner<jim.gi...@albanyhandball.com> 
>> wrote:
>>
>>> On 8/8/2012 11:24 AM, Ansry User 01 wrote:
>>>> I am setting the _SESSION variables in one of my file, but whenever
>>>> I leave the php page session variables are not accessible. Not sure
>>>> what I need to do additionally other then defining _SESSION[].
>>>> Any pointer.
>>>>
>>> You must make it a habit to start each script with
>>>
>>> session_start();
You should definitely not make that a habbit!
Why create/open a session and send a cookie everytime script call even
if you won't need it? Why access a hard disk to create/open a session
file even if there is no use for it?

Only call session_start() if you need it and call session_write_close()
as early as possible to avoid write locks on the users session file.

And up from PHP 5.4 you can use

http://de2.php.net/manual/de/function.session-status.php

to check a session status.

-- 
Marco Behnke
Dipl. Informatiker (FH), SAE Audio Engineer Diploma
Zend Certified Engineer PHP 5.3

Tel.: 0174 / 9722336
e-Mail: ma...@behnke.biz

Softwaretechnik Behnke
Heinrich-Heine-Str. 7D
21218 Seevetal

http://www.behnke.biz


Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---
--- Begin Message ---
On Aug 10, 2012, at 1:21 PM, Ege Sertçetin <sertce...@itu.edu.tr> wrote:

> Hi. My question will maybe out of topic, I'm sorry.
> How can you know that one way will be much slower than other one? I mean, how 
> can I learn which function is faster before I test it?

Ege:

No your question is on topic.

This question should be asked on the list, so I'll present Q:A instead of 
answering privately

http://www.webbytedd.com/b/timed1/

The code is there -- if you have questions, please post them to the list.

Cheers,

tedd


_____________________
t...@sperling.com
http://sperling.com

--- End Message ---
--- Begin Message ---
I've looked all over the net and I have been unable to find a concrete answer 
to this question. I am about to start development on a web application that 
will need to provide real-time updates of data to user's browsers. WebSockets 
are ideal for this task.

I have read in some places on the net that PHP is not suitable for WebSockets 
due to it's nature. That WebSockets are designed for long running 
threads/processes which each maintain multiple event-driven connections, 
whereas PHP was designed around the short-lived single process procedural 
paradigm.

Yet on the other hand I see lots of guides and libraries (such as 
http://socketo.me/) on the net that deal with PHP WebSockets. So I don't know 
what to think at this stage. Is PHP a suitable platform for developing a web 
application that requires WebSockets?

--- End Message ---
--- Begin Message ---
On 8/12/2012 12:06 PM, BRIAN M. FITZPATRICK wrote:
I've looked all over the net and I have been unable to find a concrete answer 
to this question. I am about to start development on a web application that 
will need to provide real-time updates of data to user's browsers. WebSockets 
are ideal for this task.

I have read in some places on the net that PHP is not suitable for WebSockets 
due to it's nature. That WebSockets are designed for long running 
threads/processes which each maintain multiple event-driven connections, 
whereas PHP was designed around the short-lived single process procedural 
paradigm.

Yet on the other hand I see lots of guides and libraries (such as 
http://socketo.me/) on the net that deal with PHP WebSockets. So I don't know 
what to think at this stage. Is PHP a suitable platform for developing a web 
application that requires WebSockets?



Back in 2007, I wrote a cli php script to run as a socket server for a game I was playing at the time. It has been running on every server I've put together since then. To say that PHP isn't suited to this type of service is wrong.

Give it a shot.  Can't hurt to try.

Jim

--- End Message ---
--- Begin Message ---


On 8/10/2012 12:02 PM, Daniel Brown wrote:
On Fri, Aug 10, 2012 at 10:22 AM, Robert Cummings <rob...@interjinn.com> wrote:
On 12-08-09 08:01 PM, Al wrote:
I can't find a way to see what files could be open or what the limit is.

Site is on a shared server, cPanel.

                ^^^^^^^^^^^^^
THIS is probably your problem. Too many open files indicates that either the
user OR the OS has reached its limit of allowed open file handles. Open
files are those used by the OS and every user on the shared server. The
setting can be changed but you'll need an administrator to increase the
number of allowed open files. I suspect it's at the OS level if indeed you
only have 100 files open (though you likely have more due to files opened
for you by the OS or whatnot.

     Rob is exactly right.  This is managed via the kernel and ulimit,
to prevent excessive resource usage.  Often it's a temporary problem,
but if it consistently occurs, your host may either be improperly
configured or, more likely, overselling resources.


I've checked carefully and my code does not have any open files, I obviously can't check the OS, etc.

I'm using Pear Mail_mime()to batch send emails. The problem is created when my batch exceeds about 36 sends. I have several mail functions which all iterate this function for each recipient.
emailPearSend($mime, $headers, $bodyText, $attachedFile = null, $imgFile = null)

I did have the $mime = new Mail_mime("\r\n"); in emailPearSend(), which meant it was called for every recipient. I tried moving it out of the calling function so it would only be called one time for each batch, and I send the $mime as a function arg. Didn't help.

I'm off to get the host to check and fix the open files limit.

Off the subject a bit. What does PHP do with repeated new classes, e.g.
$mime = new Mail_mime Are they simply ignored or are additional new instances created. PHP won't let you duplicate function names.





--- End Message ---
--- Begin Message ---
On Fri, Aug 10, 2012 at 6:02 PM, Daniel Brown <danbr...@php.net> wrote:
> On Fri, Aug 10, 2012 at 10:22 AM, Robert Cummings <rob...@interjinn.com> 
> wrote:
>> On 12-08-09 08:01 PM, Al wrote:
>>> I can't find a way to see what files could be open or what the limit is.
>>>
>>> Site is on a shared server, cPanel.
>>
>>                ^^^^^^^^^^^^^
>> THIS is probably your problem. Too many open files indicates that either the
>> user OR the OS has reached its limit of allowed open file handles. Open
>> files are those used by the OS and every user on the shared server. The
>> setting can be changed but you'll need an administrator to increase the
>> number of allowed open files. I suspect it's at the OS level if indeed you
>> only have 100 files open (though you likely have more due to files opened
>> for you by the OS or whatnot.
>
>     Rob is exactly right.  This is managed via the kernel and ulimit,
> to prevent excessive resource usage.  Often it's a temporary problem,
> but if it consistently occurs, your host may either be improperly
> configured or, more likely, overselling resources.
>

It's not uncommon for shared hosters to host over a 1000 websites on a
single host, so reaching the limits is not that hard anymore. Best
solution in this case (though your hosting provider might not like
it), is just retry until the open succeeds and only then continue with
the next file.

- Matijn

--- End Message ---
--- Begin Message ---
I'm administering WordPress sites under suPHP on a CentOS LAMP server
and would like to know how I can set PHP to keep the session files under
the WP user's dir without having do duplicate the entire php.ini file
for each WP site while still maintaining adequate security.  The
problems I'm encountering are that, AFAICT, I have basically two
choices:

 1. Use the suPHP "suPHP_ConfigPath" to set the path to a
    per-site php.ini file containing a "session.save_path"
    directive.

 2. Put php.ini files with the "session.save_path" directive
    within the WP dir hier.

The problems with the above two options (I have found no other options
so far) are that, for the former, the system php.ini file is not read so
the per-site php.ini file(s) have to duplicate most if not all of what's
in the system php.ini file; this is for each WP site (if not a WP Net
(AKA WPMU) install); and for the latter, -any-and-every- subdir in the
WP dir hier that has code that may reference the PHP session must have
its own php.ini file in it.  Either way it becomes a significant
maintenance problem, especially once there are more than one or two
such sites.

I have not been able to find much documentation on this, either in the
PHP site or in the various help forums.  I've searched quite extensively
and have run some tests of my own using phpinfo.php to see how things
are set.

I do not desire to open up file permissions to bypass this PHP settings
issue altogether due to security concerns (though I do wish an answer
could be so simple).

What's canonical in such a case?  If nothing, are there any other
alternatives?  My desired solution would be to be able to put one
php.ini (or equivalent) file per site that would contain the needed
directive which would be merged with the settings from the system
php.ini, overriding only the session.save_path, but, AFAICT, PHP does
not seem to allow this.  Any other ideas?

Thanks!

--Phil


-- 
Philip Amadeo Saeli
openSUSE, RHEL, CentOS
psa...@zorodyne.com

--- End Message ---

Reply via email to