Re: [PHP] Re: PHP as Application Server
to Matijn Woudt: you are right there should be something like: public void synchronized increment(), but that is not the point. Sure there are disadvantages and other problems but what Alessando is saying is I would not use cure for cancer even if it existed because it can introduce other problems like overpopulation. There are cases when application server adds much overhead that is not needed and there are cases when it simplifies your tasks a lot. So from his mail the only problem I can see is memory leaks, and I am not talking about leaks in application because they can be caught in tests and fixed, but mostly leaks in poorly wriiten PHP core and modules. Other like session hijacking are not real problems (other languages somehow managed it to work) or not so big in face of some other advantages (like restarting application after change). Robert Williams points that the main problem is with PHP programmers who tend to ignore many aspects of multithreaded programming and PHP helps them in that by hiding all threading aspects. There are still people who can understand that and take profit from this knowlege. The memory is also not such problem. I did some quite large PHP projects and whole source code event if it were loaded in memory use only few megabytes (event 100mb is not a problem). And am talking about holding parsed structures in memory not the source files. Applications I am talking about are mostly targeted to maximize throughput and they are the only ones on server. In such cases *any* speed improvement is worth attention. I am not forcing anybody to use application server approach, but rather like Robert said - good to have choice and decide on my own if I want to write simple scripts or stateful application. The only problem is that I do not have that choice not considering changing language... at least I do not have such choice for now :) 2012/9/26 Robert Williams rewilli...@thesba.com: 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.
[PHP] Re: PHP as Application Server
Il Thu, 27 Sep 2012 12:28:00 +0200, Maciej Liżewski ha scritto: Sure there are disadvantages and other problems but what Alessando is saying is I would not use cure for cancer even if it existed because it can introduce other problems like overpopulation. Uhm, no. I see it as I would not use chemio if I could remove the cancer with laser therapy. They are two ways to solve the same problem, and I think the non- application-server way is the best. It is similar to the Unix way: many small pieces tied together to reach a goal. The application server is more like the Windows way: one big piece to reach a goal. I understand sometimes the application server can be easier or fit better, but I think most of the times it is the wrong solution, expecially in PHP, but not exclusively. Bye. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP as Application Server
Hi, Once again I didn't read it completely (maybe I will do so), but my 2ct: I recently played with Ruby and Python and of course with their application server (at least a little bit). My experience was, that it is less fun as it sounds in the first place compared to a well designed webserver-interpreter-stack (and of course common OS-specific stuff for CLI). In my eyes it is good the way it is: Let PHP do it's job and let more intelligent tools do the other things, like spawning request-handling processes. Not saying, that I'm against an application, but I currently don't miss it :) On the other side someone must maintain it and someone must make sure, that it is secure and efficient. This resources should not taken from the core-team. Regards, Sebastian 2012/9/27 Alessandro Pellizzari a...@amiran.it Il Thu, 27 Sep 2012 12:28:00 +0200, Maciej Liżewski ha scritto: Sure there are disadvantages and other problems but what Alessando is saying is I would not use cure for cancer even if it existed because it can introduce other problems like overpopulation. Uhm, no. I see it as I would not use chemio if I could remove the cancer with laser therapy. They are two ways to solve the same problem, and I think the non- application-server way is the best. It is similar to the Unix way: many small pieces tied together to reach a goal. The application server is more like the Windows way: one big piece to reach a goal. I understand sometimes the application server can be easier or fit better, but I think most of the times it is the wrong solution, expecially in PHP, but not exclusively. Bye. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
[PHP] Re: PHP as Application Server
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
Re: [PHP] Re: PHP as Application Server
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP as Application Server
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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP as Application Server
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?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP as Application Server
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP as Application Server
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). -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
