php-general Digest 26 Sep 2012 19:43:53 -0000 Issue 7981
Topics (messages 319257 through 319267):
Re: Vulnerability Announced in phpMyAdmin
319257 by: Daniel Fenn
Re: output compression when host has disabled mod_deflate, mod_gzip and
php_value auto_prepend_file
319258 by: tamouse mailing lists
PHP as Application Server
319259 by: Maciej Li¿ewski
319260 by: shiplu
319261 by: Daniel Brown
319262 by: Jim Giner
319263 by: Maciej Li¿ewski
319264 by: Alessandro Pellizzari
319265 by: Jim Giner
319266 by: Matijn Woudt
319267 by: Robert Williams
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 ---
Thank you for the heads up.
On 9/26/12, tamouse mailing lists <tamouse.li...@gmail.com> wrote:
> On Tue, Sep 25, 2012 at 3:20 PM, Daniel Brown <danbr...@php.net> wrote:
>> Just a three-list cross-post to bring it to everyone's attention
>> at once, in case you weren't already aware. It was announced today
>> that a compromised SourceForge mirror was distributing a malicious
>> file with the phpMyAdmin package that allows an attacker to
>> arbitrarily execute code on a server hosting the exploitable package.
>> Obligatory (not intentionally self-serving) social media link here:
>>
>> https://twitter.com/oidk/status/250688002005811200
>>
>
> Signal boosting...
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Regards,
Daniel Fenn
--- End Message ---
--- Begin Message ---
Crikey, forgot to include the list.
---------- Forwarded message ----------
From: tamouse mailing lists <tamouse.li...@gmail.com>
Date: Wed, Sep 26, 2012 at 1:57 AM
Subject: Re: [PHP] output compression when host has disabled
mod_deflate, mod_gzip and php_value auto_prepend_file
To: edward eric pedersson <cpsmadn...@googlemail.com>
On Fri, Sep 21, 2012 at 9:50 AM, edward eric pedersson
<cpsmadn...@googlemail.com> wrote:
> I want to compress the css and javascript external files as well but
> without the apache options available I am wondering what other options
> I have. The files are not massive, all but one less than 20k. Not sure
> how much of a performance gain I will get but I thought it is worth
> while asking the question.
>
> One solution I have on my mind is to call a php script that pulls in
> the css and js files and compresses the output e.g
You need to ensure that the browser you are sending to has the
capability to accept compressed input streams as well. Some don't
still, including some screen readers. This may not be as huge a
consideration with CSS or JS, but should still be considered, I think.
> <link rel="stylesheet" type="text/css"
> href="http://my.domain.com/stylesheet.php?file=/path/to/stylesheet.css";
> />
>
> stylesheet.php
> ------------------
> <?php
>
> // initialize ob_gzhandler function to send and compress data
> ob_start ("ob_gzhandler");
>
> // send the requisite header information and character set
> header ("content-type: text/css; charset: UTF-8");
>
> // check cached credentials and reprocess accordingly
> header ("cache-control: must-revalidate");
>
> // set variable for duration of cached content
> $offset = 60 * 60;
>
> // set variable specifying format of expiration header
> $expire = "expires: " . gmdate ("D, d M Y H:i:s", time() + $offset) . "
> GMT";
I am pretty sure the header needs to be capitalized: "Expires:". Also,
you can simplify the format string a bit:
$expire = "Expires: " . gmdate (DATE_RFC1123, time() + $offset);
as that is the standard form the Expires header takes.
>
> // send cache expiration header to the client broswer
> header ($expire);
>
> //read and echo the file
> $file = readfile($_GET["file"]);
You want to be careful here and validate that you are sending a real
file that contains what *you* want to send. *Always* untaint input.
>
> echo $file;
>
> ?>
>
> ------------------
>
> Similar code for javascript with different content-type.
>
>
> A few questions:
>
> 1) Will apache cache the full url or the url minus the query parameter?
Generally, it will cache the full url.
> 2) Are there any performance benefits as there is an overhead in
> calling the PHP file?
This entirely depends on the size of the file. If your css or js is
small (<1000 bytes, maybe?) it's not going to be worthwhile. You say
yours are mostly > 20000, so it might very well be worthwhile. Also,
it sort of depends on how heavily your server is loaded. Live
performance tests would probably be worthwhile to guage your
particular implementation.
> 3) If the PHP call is cached is it cached with the file query parameter?
Is this a different question than #1?
Something similar was discussed previously, only in the realm of
someone wanting to serve static pages. You can cache the compressed
version of the file and serve if up if it is newer than the
uncompressed version, which might also speed things up, although
probably not a great deal in this case since there's basically no PHP
processing happening here.
p.s. - somehow the OM wound up in my SPAM folder so I didn't see it
for a few days.
--- End Message ---
--- Begin Message ---
Hi,
Maybe this topic have been already on board, but I could not find nothing
in google, so my question to PHP maintaneers (and other users too) is:
Why there is no possibility to run PHP in "application server" way among
other SAPI modules and other possibilities to run PHP? PHP would encounter
great performance boost and became more "enterprise" :) Just look at Ruby
which is slow as hell compared even with PHP.
By "application server" I mean scenario when there is statefull application
on server side not only by session mechanizms but all classes definitions
maintained in memory (no need to load class definition on every request),
static class members (and their changes) persistent, background threads,
etc. This way any op-code cachers won't be necessary...
sounds great, huh? others have it already, so why doesn't PHP? are there
any cons? problems too hard to solve (one can be memory leaks, thread safe
coding, etc)? I mean it - I am realy curious why there is no such
possibility and is there any hope we could get it?
TIA for any answers on this topic.
--- End Message ---
--- Begin Message ---
My recent experience is PHP eats more memory. But it matters when you are
running it under memory constraint device. For a high end server its not a
matter.
I built an chat server using socket functions which was intended to run on
embedded device. I didn't want to load apache. So I wrote it in plain PHP
(as I am good at it). The server was working good until I my memory runs
out. My memory requirement was really low, about 32M. Thats the total
memory for everything. I ran a heavy RIA chat application with. Later I
change the language to non-PHP (name of that language might start
flame-war). Now its working well so far.
One thing I know is, If you want to do it, you can do it. It'll need some
effort but still doable. Performance optimization comes after development.
So you can have your high performance enterprise application server.
--
Shiplu.Mokadd.im
ImgSign.com | A dynamic signature machine
Innovation distinguishes between follower and leader
--- End Message ---
--- Begin Message ---
On Wed, Sep 26, 2012 at 5:58 AM, Maciej Liżewski
<maciej.lizew...@gmail.com> wrote:
>
> Why there is no possibility to run PHP in "application server" way among
> other SAPI modules and other possibilities to run PHP? PHP would encounter
> great performance boost and became more "enterprise" :) Just look at Ruby
> which is slow as hell compared even with PHP.
>
> By "application server" I mean scenario when there is statefull application
> on server side not only by session mechanizms but all classes definitions
> maintained in memory (no need to load class definition on every request),
> static class members (and their changes) persistent, background threads,
> etc. This way any op-code cachers won't be necessary...
>
> sounds great, huh? others have it already, so why doesn't PHP? are there
> any cons? problems too hard to solve (one can be memory leaks, thread safe
> coding, etc)? I mean it - I am realy curious why there is no such
> possibility and is there any hope we could get it?
While there are no real plans to incorporate a full-fledged
application server at this time, PHP 5.4 does have an embedded
server[1] for development and such. It's certainly not advisable to
use it for production, but the fact is, it's there.
With regard to an actual production-worthy application server,
you might be interested in HipHop[2], which was developed by some of
the engineers over at Facebook.
^1: http://php.net/manual/en/features.commandline.webserver.php
^2:
https://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php--move-fast/
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
On 9/26/2012 5:58 AM, Maciej Liżewski wrote:
Hi,
Maybe this topic have been already on board, but I could not find nothing
in google, so my question to PHP maintaneers (and other users too) is:
Why there is no possibility to run PHP in "application server" way among
other SAPI modules and other possibilities to run PHP? PHP would encounter
great performance boost and became more "enterprise" :) Just look at Ruby
which is slow as hell compared even with PHP.
By "application server" I mean scenario when there is statefull application
on server side not only by session mechanizms but all classes definitions
maintained in memory (no need to load class definition on every request),
static class members (and their changes) persistent, background threads,
etc. This way any op-code cachers won't be necessary...
sounds great, huh? others have it already, so why doesn't PHP? are there
any cons? problems too hard to solve (one can be memory leaks, thread safe
coding, etc)? I mean it - I am realy curious why there is no such
possibility and is there any hope we could get it?
TIA for any answers on this topic.
Thirty+ years as a professional application designer, developer and
manager and I don't have a clue about what you are proposing. I must
have been in a different world. :)
--- End Message ---
--- Begin Message ---
Well.. many things changed during last 30 years. Cobol is not
mainstream, we have got OOP, Java, Python, Ruby, Google and other
great things :)
I am talking about stateful application server. There are plenty
examples in other programming languages: Java has Jetty, Tomcat, Ruby
On Rails, Python and Passenger WSGI.
All of them have one common thing: application persist in memory
between requests. Even for interpreted languages (such Ruby) - this
has advantage of loading sources only once, parse it only once and
initialize memory structures for those definitions only once. On the
opposite - PHP loads EVERY single resource on every request. This is
why it needs op-code cachers, accelerators etc.
Another advantage of using stateful application servers is that you
can simply keep gloabal state of your application (global variables,
static object properties) in memory. It simplifies many tasks which in
PHP require sessions, writing files with serialized data and
deserialize them on every request...
Just imagine such scenarios:
now PHP acts like this on every request:
1. locate resources (source files in this case), parse and load them
(possibly with op-code cache)
2. initialize global context ($_SERVER, $GLOBALS, $_POST, $_GET, etc)
3. run code
4. destroy all resource and free memory for next request
persistent application servers load resources only on startup (or when
needed) and keep them in memory until programatically freed or until
end of application (server shutdown). So every request looks like
this:
1. initialize global context
2. run already parsed code
is that makes whole thing clear?
Another nice example - simple counter. In PHP you have to:
1. read file with counter
2. increment value
3. write serialized value to file
...on every request.
in Java (for example) you just write class:
class Counter {
static private counter = 0;
public void increment() {
this.counter++;
}
}
and because class definition persists in application server - static
member is maintained between requests and whole things works as
expected...
2012/9/26 Jim Giner <jim.gi...@albanyhandball.com>:
> On 9/26/2012 5:58 AM, Maciej Liżewski wrote:
>>
>> Hi,
>>
>> Maybe this topic have been already on board, but I could not find nothing
>> in google, so my question to PHP maintaneers (and other users too) is:
>>
>> Why there is no possibility to run PHP in "application server" way among
>> other SAPI modules and other possibilities to run PHP? PHP would encounter
>> great performance boost and became more "enterprise" :) Just look at Ruby
>> which is slow as hell compared even with PHP.
>>
>> By "application server" I mean scenario when there is statefull
>> application
>> on server side not only by session mechanizms but all classes definitions
>> maintained in memory (no need to load class definition on every request),
>> static class members (and their changes) persistent, background threads,
>> etc. This way any op-code cachers won't be necessary...
>>
>> sounds great, huh? others have it already, so why doesn't PHP? are there
>> any cons? problems too hard to solve (one can be memory leaks, thread safe
>> coding, etc)? I mean it - I am realy curious why there is no such
>> possibility and is there any hope we could get it?
>>
>> TIA for any answers on this topic.
>>
> Thirty+ years as a professional application designer, developer and manager
> and I don't have a clue about what you are proposing. I must have been in a
> different world. :)
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
Il Wed, 26 Sep 2012 17:23:35 +0200, Maciej Liżewski ha scritto:
> persistent application servers load resources only on startup (or when
> needed) and keep them in memory until programatically freed or until end
> of application (server shutdown).
You don't mention the downsides:
- every application must be structured to not overwrite session data (you
risk saving one user's data in another user's space)
- when changing even a single line in your code, you must restart
(shutdown and start up) the whole app, closing all user connections and
possibly losing all session data, forcing users to relogin.
- memory leaks are much more problematic
- you must manage threads, somehow, sometime.
Application servers have (IMHO) very little advantages (counters, and?)
and a lot of disadvantages.
All (or nearly all) the advantages of application server have been
superseded in PHP (precompiled caches, memcache, gearman, ... nodephp :)
without losing its advantages (you can change a single file in the app
and the precompiled cache auto-updates. You risk less with memory leaks,
etc.)
Yes, some things are easier in Java (threading, syncronizing, etc.) but
you can always write abstraction classes to do that for you.
I don't think I would use a PHP application server, even if it existed.
Bye.
--- End Message ---
--- Begin Message ---
On 9/26/2012 11:23 AM, Maciej Liżewski wrote:
Well.. many things changed during last 30 years. Cobol is not
mainstream, we have got OOP, Java, Python, Ruby, Google and other
great things :)
I am talking about stateful application server. There are plenty
examples in other programming languages: Java has Jetty, Tomcat, Ruby
On Rails, Python and Passenger WSGI.
All of them have one common thing: application persist in memory
between requests. Even for interpreted languages (such Ruby) - this
has advantage of loading sources only once, parse it only once and
initialize memory structures for those definitions only once. On the
opposite - PHP loads EVERY single resource on every request. This is
why it needs op-code cachers, accelerators etc.
Another advantage of using stateful application servers is that you
can simply keep gloabal state of your application (global variables,
static object properties) in memory. It simplifies many tasks which in
PHP require sessions, writing files with serialized data and
deserialize them on every request...
Just imagine such scenarios:
now PHP acts like this on every request:
1. locate resources (source files in this case), parse and load them
(possibly with op-code cache)
2. initialize global context ($_SERVER, $GLOBALS, $_POST, $_GET, etc)
3. run code
4. destroy all resource and free memory for next request
persistent application servers load resources only on startup (or when
needed) and keep them in memory until programatically freed or until
end of application (server shutdown). So every request looks like
this:
1. initialize global context
2. run already parsed code
is that makes whole thing clear?
Another nice example - simple counter. In PHP you have to:
1. read file with counter
2. increment value
3. write serialized value to file
...on every request.
in Java (for example) you just write class:
class Counter {
static private counter = 0;
public void increment() {
this.counter++;
}
}
and because class definition persists in application server - static
member is maintained between requests and whole things works as
expected...
2012/9/26 Jim Giner <jim.gi...@albanyhandball.com>:
On 9/26/2012 5:58 AM, Maciej Liżewski wrote:
Hi,
Maybe this topic have been already on board, but I could not find nothing
in google, so my question to PHP maintaneers (and other users too) is:
Why there is no possibility to run PHP in "application server" way among
other SAPI modules and other possibilities to run PHP? PHP would encounter
great performance boost and became more "enterprise" :) Just look at Ruby
which is slow as hell compared even with PHP.
By "application server" I mean scenario when there is statefull
application
on server side not only by session mechanizms but all classes definitions
maintained in memory (no need to load class definition on every request),
static class members (and their changes) persistent, background threads,
etc. This way any op-code cachers won't be necessary...
sounds great, huh? others have it already, so why doesn't PHP? are there
any cons? problems too hard to solve (one can be memory leaks, thread safe
coding, etc)? I mean it - I am realy curious why there is no such
possibility and is there any hope we could get it?
TIA for any answers on this topic.
Thirty+ years as a professional application designer, developer and manager
and I don't have a clue about what you are proposing. I must have been in a
different world. :)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Sounds to me like you'd need more hardware to support such a concept. I
realize that memory can be mapped to disk to avoid the need to have HUGE
amounts of ram in your server(S!) but with ever-increasing processor
speed, is it really necessary to go this route?
--- End Message ---
--- Begin Message ---
On Wed, Sep 26, 2012 at 5:23 PM, Maciej Liżewski
<maciej.lizew...@gmail.com> wrote:
> in Java (for example) you just write class:
> class Counter {
> static private counter = 0;
>
> public void increment() {
> this.counter++;
> }
> }
>
And here's where things go wrong.. You assume ++ is an atomic
operation, but in Java that's not true for static variables (it is for
local, but what does it matter?)
So you might end up with a race condition here where the counter will
only be incremented once when there are two or more threads. You need
a mutex or semaphore to make sure there's only one thread
reading/writing the counter at the same time (though volatile would
work here too probably).
Writing scripts for an application server requires a much deeper
understanding of threads and computer internals,so as a result it
probably increases error rate.
I think Alessandro explained the rest of the downsides pretty clearly.
- Matijn
Ps. Please bottom-post on this mailing list
--- End Message ---
--- Begin Message ---
On 9/26/12 10:18, "Matijn Woudt" <tijn...@gmail.com> wrote:
>Writing scripts for an application server requires a much deeper
>understanding of threads and computer internals,so as a result it
>probably increases error rate.
Well... yes and no. PHP's architecture pretty much keeps you from having
to mess with thread management, but it does so by shifting the burden to a
higher level, either process management of multiple PHP processes or
thread management within the context of the HTTP server. If your
application is sufficiently simple, that shift may be enough to keep you
from having to worry about the problem. For most applications, however,
it's still a concern. In some ways, this can make things worse, simply
because PHP programmers tend to be oblivious of the potential problems,
whereas the typical C# or Java programmer has at least some awareness of
the various traps that await them.
As an example, I see PHP code *all the time* that is wide open to
concurrency issues with the database. Most code just assumes it's the only
code doing updates, but unless the server is set up to serialize requests,
that's an invalid assumption. Recently, more folks have started to address
this by using database transactions, but this is often done in ignorance
of what isolation level is being used and what the impact of that is upon
the code - which can just make things worse. Even when there is that
awareness, there are database concurrency issues with which transactions
can't help. (Of course, people who are aware of isolation levels also tend
to be aware of other concurrency issues.) The point is, if you have
multiple things running in parallel, whether that be threads within your
application or entirely separate physical servers running multiple copies
of your application, you have to deal with concurrency issues. It's a
necessary evil of parallel programming, and no mere technological solution
(language, database, whatever), now or in the future, can fully overcome
it. Well, maybe an AI engine somewhere in the chain, but that's about it,
and that's not coming anytime soon.
Incidentally, another advantage of PHP's share-nothing approach that
hasn't been mentioned is relatively easy scalability. In a shared pool
architecture, the easiest way to scale is typically vertically, that is,
adding RAM, faster drives, etc. This is fine, but you can only scale
vertically to a certain point, which you can usually hit pretty quickly.
With PHP's share-nothing approach, you can still scale vertically, but you
can almost as easily scale horizontally by adding more servers that each
run merrily in their own worlds, with the primary added coordination logic
being in the areas of communicating with the database and the data cache,
something the application should be designed with, anyway. In contrast,
the shared approach requires added logic, somewhere, to coordinate the
sharing amongst the pools of all that data that the application takes for
granted is always available at low cost.
Having said all that, there are many advantages and disadvantages to both
approaches. And honestly, I would love to have the option of a shared
approach with PHP, since that architecture simply works better as a
solution to certain problems. Assuming the shared-nothing model continues
on, it would make PHP that much more well-rounded. In that respect, the
added option isn't that different from the addition of OOP: we now have
the great ability to use procedural code where it makes sense, and to use
OOP code where it makes sense. Where neither is a perfect fit, you can
choose the one that creates the least personal pain. It's a wonderful
choice to have.
Regards,
Bob
--
Robert E. Williams, Jr.
Associate Vice President of Software Development
Newtek Businesss Services, Inc. -- The Small Business Authority
https://www.newtekreferrals.com/rewjr
http://www.thesba.com/
Notice: This communication, including attachments, may contain information that
is confidential. It constitutes non-public information intended to be conveyed
only to the designated recipient(s). If the reader or recipient of this
communication is not the intended recipient, an employee or agent of the
intended recipient who is responsible for delivering it to the intended
recipient, or if you believe that you have received this communication in
error, please notify the sender immediately by return e-mail and promptly
delete this e-mail, including attachments without reading or saving them in any
manner. The unauthorized use, dissemination, distribution, or reproduction of
this e-mail, including attachments, is prohibited and may be unlawful. If you
have received this email in error, please notify us immediately by e-mail or
telephone and delete the e-mail and the attachments (if any).
--- End Message ---
