PHP Servlet Engine?

Quote:

---

Originally Posted by BDKR

I am talking about only one (an ideal of course) connection to the database.

---

If you mean one persistent connection per user (per instance of the application), then I see where you are going, but one single connection to the database full stop seems like a waste of the ability of the DB to handle multiple connections (as yuo may have multiple users).

I still don't see how this is going to be much benifit: you still have to associate a request with a user, which is more of a bother than whether the PHP files are loaded from memory or from files - hell, why not just use the Zend Encoder and have the encoded files stored in memory? Seems much easier to do with the benifit that it will speed up any PHP application. Infact, I can hardly see why the servlet hosting code overhead is going to make anything faster than this anyway!

Douglas

Quote:

---

Originally Posted by Mike Borozdin

I think arborint is right, you said you want a container for enterprise-level application, but if you develop such application, I think you can easily install an app server and use JSP/Servlet instead of PHP.

---

I don't want to use Java. I'm asking about PHP. It's a framework-level construct, not a language-level feature. In any hypothetical application, I want to use PHP, and I'm wondering if any servlet-style engine for PHP exists. I obviously know about the Java Servlet engine, and I don't want to use it.

Quote:

---

Originally Posted by Mike Borozdin

But can you tell me if this way has any advantages over JSP/Servlet, except for dynamic types that I can't name as an advantage?

---

Loose typing is a huge advantage for those who want to use it. Not being Java is yet another (some folks just don't like it). Using PHP, an easy-to-write language, is another. Having server-level and application-level data stay in memory for the lifecycle of the app and having session-level data handled in many ways is another.

I'm not sure why there's such a resistance to this idea. The implementation would be tough, sure, but the model is proven to work very well, and writing a PHP servlet app could be almost as easy as writing a plain PHP script.

Quote:

---

Originally Posted by arborint

Actually my point was that it is WHY existing tools do the job that matters. Perl started as a better shell script. Java as a run anywhere C++. PHP as a easy to use CGI. And that is still pretty much where they still excel.

---

It's worth noting that although PHP started as CGI, it's (optionally) not CGI any more. The in-server module method is an innovation that is not unique to PHP but is a good option for those who want to use it.

Quote:

---

Originally Posted by arborint

Off course the OO guys whine for the same stuff everywhere and hence the confusion because languages start to look the same.

---

Who are these "OO guys" you refer to and what do they have to do with this discussion? I use both in different circumstances, but OO/procedural programming has nothing--zilch--zip--nada to do with this. I'm talking about an execution model, basically--one that is different from the current one. It has nothing to do with one's choice to use OO or procedural programming.

Quote:

---

Originally Posted by arborint

But the systems those languages live in are very different. Everything may have the same possibilities but it is the choices that make the difference.

---

Interesting. I don't lump together languages and the systems they exist in. I use PHP because of language features. I use the Apache module because of execution features. Together I end up with a nice script that performs well. I'm merely trying to find a way to write my script in a different execution model.

Quote:

---

Originally Posted by arborint

I think you are not really clear about what you are asking for. At the top you wanted " (only interpreting it once but executing many times)" (i.e. compiled) and at the end you like 'is more fun than writing in a compiled language."

---

I wrote the first thing (I think), but I did not write the second. In any case, the opinion that PHP is "more fun than writing in a compiled language" is a reason, however subjective, some people use PHP instead of CGI in C, for example.

Quote:

---

Originally Posted by arborint

If you are looking for speed then use an accelerator and put your sesson files in a RAM disk. That wil achieve your goals of compile once and memory resident application data without having to turn PHP into Java.

---

No, this does not really solve the problem. It's a workaround, sure, but it's not elegant, IMO.

Quote:

---

Originally Posted by arborint

I guess it comes down to if you are interested in a specific method in achieving your goal, use a system that implements that method. If you are interested in achieving your goal using PHP, then find the PHP way to do it.

---

There is no "PHP way" to do anything, other than to write PHP. To contrast with Java, I could write a web application in Java as CGI or as a servlet. The decision has nothing to do with the language but with the execution model.

Quote:

---

Originally Posted by deanpence

There is no "PHP way" to do anything, other than to write PHP. To contrast with Java, I could write a web application in Java as CGI or as a servlet. The decision has nothing to do with the language but with the execution model.

---

Sure there's a "PHP way" to do things. And it's doing thats that PHP is capable of, or capable of being extended to do. But just because PHP is capable of something, doesn't mean it's the way it should be done.

In my opinion PHP is a tool, just like Java is a tool, .NET is a tool, PERL is a tool, etc. The true strength of any programmer is knowing when to use what tool. Trying to shoe-horn PHP into an execution model (as you put it) that it was never designed to handle, is not using the tools effectively. If object persistence and "compile once" are must-have features for your applications, then choose the tool that is designed to solve the problem (ie Java or .NET).

Have any of you guys any experience with nanoweb ?

I really need to figure out how to get this board to email when there are posts to this thread. :blush:

Quote:

---

Originally Posted by otnemem

Are you sure about this? Having only one connection shared between every request could cause a bunch of requests waiting for a single query to be executed.

---

Yes, but I'm speaking within the context of only one application. However, I see your point. Only one connection could easily become swamped.

But let's also remember that if the queries are that intensive and the server is poorly tuned, then every new connection will be affected as well. The present paradigm isn't exempt from this.

For everybody:

My thrust is that we should be able to get away from the 'connect-query-dis-connect' routine that many PHP applications use now. So if that means a php application server should itself maintain a connection pool (I clearly wasnt thinking here) to overcome the issues some of you spoke of, then great, as long as it's transparent to the developer or the executing script. In other words, from the veiw of the executing script or request, there is still just 'a connection'.

Cheers

You just subscribe to the therad (under "Thread Tools" top of the thread on the right). :)

Anyway. Isn't the easiest way to do a servlet engine just to have a servlet server running with PHP on port 12345 and then use an iframe to pass a file to it? I could scrap something like that together, though I don't see the purpose.

Quote:

---

Originally Posted by deanpence

... writing a PHP servlet app could be almost as easy as writing a plain PHP script.

---

I don't think so. In a Servlet container objects might live beyond a request and could be accessed by a lot of other objects at the same time. This means you will have to handle concurrency problems which is not a trivial issue.

Quote:

---

I don't think so. In a Servlet container objects might live beyond a request and could be accessed by a lot of other objects at the same time. This means you will have to handle concurrency problems which is not a trivial issue.

---

I agree, I think this will really change the way you write scripts. You have to be less sloppy to avoid having your script eat up all memory after 10 minutes, and your way of accessing data changes because your script is persistent.

Quote:

---

Originally Posted by Captain Proton

I agree, I think this will really change the way you write scripts. You have to be less sloppy to avoid having your script eat up all memory after 10 minutes, and your way of accessing data changes because your script is persistent.

---

*sighs* You should be coding less sloppily anyway... Memory consumption, CPU consumption - few PHP developers actually care about it even though they should.

Actually I didn't talk about problems resolving from sloppy coding, but problems of concurrency.

You don't have to care about concurrency in PHP because your script is executed only per request.

Imagine you'd have an object that exists beyond a request (for example stored in application context to speak in Java). Now two or more servlet scripts could manipulate this object at the same time (concurrently) and weird problems could occur, like lost updates (overwritten changes) for example. So you would have to synchronize access to this object (e.g. "lock" and "unlock" it).

That's all stuff that you don't have to care about in conventional PHP development (the only concurrency occurs within database access, but your rdbms will handle this for you).

I doubt concurrency in PHP would be very hard to implement (although a little tedious). An 'application scope' variable would be great - like the $_SESSION variable, but accessable to all PHP applications running on the same server. for exaxample:

application_register ('users');
$_APPLICATION['users']++; // When the session starts
// TODO: implement logic
$_APPLICATION['users']--; // And again when it ends

To deal with concurrency, you'd have to register variables independantly so that you you can assign a mutex to it, which solves the concurrency issue. I'm not sure how you'd be able to keep track of a mutex accross multiple processes (e.g. apache prefork), but it'd be trivial for the multi-threaded apache mode.

This could open up a large number of possibilities, like initializing a class that would normally take a long time to do (e.g. keeping oftenly used data from a database, or a list of concurrent clients). I'll experement & see if I can hackup a quick implementation (dont expect anything soon).

Just my $0.02

Quote:

---

Originally Posted by HarryR

application_register ('users');
$_APPLICATION['users']++; // When the session starts
// TODO: implement logic
$_APPLICATION['users']--; // And again when it ends

---

ArrayAcces interface onto the Semaphore extension perhaps?

Something like..

Code:

---

class SharedMemoryArray implements ArrayAccess
{
        protected $shm;

        function __construct($pathname, $project) { $this->shm = ftok($pathname, $project); }

        function offsetGet($key) { return shm_get_var($this->shm, $key); }
        function offsetSet($key, $value) { return shm_put_var($this->shm, $key, $value); }
        function offsetUnset($key) { return shm_remove_var($this->shm, $key); }
       
        function offsetExists($key) { return @shm_get_var($this->shm, $key) !== FALSE && ...something...; }
               
        function __destruct() { @shm_detach($this->shm); }
}

class Application extends SharedMemoryArray
{
        function __construct() { parent::__construct($_SERVER['DOCUMENT_ROOT'], ..something..); }
}

$_APPLICATION = new Application();

---

Haven't tried it, not sure it how well (if at all) it would work.

Would have some problems with offsetGet() not returning a reference I think.
And offsetExists() doesnt seem to have a natural equivalent shm_ function()
shm_get_var() returns FALSE and a warning when a $key doesnt exist.

Quote:

---

Originally Posted by Ren

ArrayAcces interface onto the Semaphore extension perhaps?

---

Quote:

---

Originally Posted by php.net

Remember, that shared memory is NOT safe against simultaneous access.

---

It isn't going to help with the concurrency problems, though may be a start.

Douglas

What about shm_aquire, that could help with concurrency issues

Quote:

---

Originally Posted by php.net

sem_acquire() blocks (if necessary) until the semaphore can be acquired. A process attempting to acquire a semaphore which it has already acquired will block forever if acquiring the semaphore would cause its maximum number of semaphore to be exceeded

---

Unless i've mis-read the description, it seems to do the job.

Although tmpfs could be considered a viable option... serializing/deserializing the $_APPLICATION variable to the file (ala file based sessions) but with file locking?

Quote:

---

Originally Posted by HarryR

What about shm_aquire, that could help with concurrency issues



Unless i've mis-read the description, it seems to do the job.

Although tmpfs could be considered a viable option... serializing/deserializing the $_APPLICATION variable to the file (ala file based sessions) but with file locking?

---

Wouldn't tmpfs be slower than using semaphores?

Another possibility could be sqlite using in memory (':memory:') database, with the queries pre-prepared (turned into sqlites' bytecode).

Quote:

---

Originally Posted by hantu

Actually I didn't talk about problems resolving from sloppy coding, but problems of concurrency.

You don't have to care about concurrency in PHP because your script is executed only per request.

Imagine you'd have an object that exists beyond a request (for example stored in application context to speak in Java). Now two or more servlet scripts could manipulate this object at the same time (concurrently) and weird problems could occur, like lost updates (overwritten changes) for example. So you would have to synchronize access to this object (e.g. "lock" and "unlock" it).

That's all stuff that you don't have to care about in conventional PHP development (the only concurrency occurs within database access, but your rdbms will handle this for you).

---

While true, that doesn't mean you should go ahead and do something that's going to use huge amounts of CPU, just because it's not concurrent. Sloppyness still needs to be cleaned up.

Quote:

---

Originally Posted by HarryR

I doubt concurrency in PHP would be very hard to implement (although a little tedious). An 'application scope' variable would be great - like the $_SESSION variable, but accessable to all PHP applications running on the same server. for exaxample:

application_register ('users');
$_APPLICATION['users']++; // When the session starts
// TODO: implement logic
$_APPLICATION['users']--; // And again when it ends

To deal with concurrency, you'd have to register variables independantly so that you you can assign a mutex to it, which solves the concurrency issue. I'm not sure how you'd be able to keep track of a mutex accross multiple processes (e.g. apache prefork), but it'd be trivial for the multi-threaded apache mode.

This could open up a large number of possibilities, like initializing a class that would normally take a long time to do (e.g. keeping oftenly used data from a database, or a list of concurrent clients). I'll experement & see if I can hackup a quick implementation (dont expect anything soon).

Just my $0.02

---

PHP-GTK is concurrent and client side, makes perfect sense. Unfortunately it doesn't make sense to run concurrent scripts on a server, as you have no idea when the person closes the application (browser). You'd be left with many open leads. DDoS'ing would be made that much easier.

I believe that's exactly what this project is trying to do:

http://phplet.sourceforge.net/

Although their project had a bunch of activity for about a month just over a year ago and appears to have stalled since then. Looked promising though.

I'm thinking of undertaking such an endeavor as the next phase of my new project (phpBeans, see the sig for details), as I think it would be very beneficial for PHP's perception in the higher-end of businesses. I think it could also simplify several aspects of writing web apps in PHP, including installation (no Apache config any more), app writing, and interoperability between apps. It could also have big performance gains, as DB connections and other objects could be instantiated only once and reused for multiple requests.

Because of that last step though, writing an app for a servlet container would be a little different than for an "ordinary" framework.

Anyway, hope my $0.02 were worth it. ;)

Cheers,

Lux

The main difference between Java and PHP, imo, is that you can squeeze OO model whenever you want and obtain a result with PHP and it's easier to install. You can do everything like the old-C manner : the famous procedural evil-noob manner.

If you do PHP code without using classes (or only for your DB access) ... then you code like my old-father and you're code will be difficult to maintain without your personal knowledge (this is the master flaw of all imo).

Look at productivity frameworks like Symfony or Zend. Everything is Object like in Java.

Servlet is not only abstractions and a bunch of Objects to make OO dev happy. It helps implementing maintainable and configurable code (trough XML or INI files for PHP).

To be very simplistic (passing by threading, application scope, etc...) servlets can be seen as a framework that makes relations between website paths like /index.php and an object class that implements everything your request need to do.

With that kind of architecture, MVC implementation is doable very very easily.

Last thing about the application scope. It's like if you're using a PECL extension like memcache to reduce Object instantations on every request. And doing things like this can make you save a lot of IO resources.

Hi.

Quote:

---

Originally Posted by sgissinger

The main difference between Java and PHP, imo, is that you can squeeze OO model whenever you want and obtain a result with PHP and it's easier to install. You can do everything like the old-C manner : the famous procedural evil-noob manner.

---

You are replying to a thread which is more than 73 months old. If you want to start a new discussion, start a new topic ;)

It's Christmastime, not Halloween. Thread Necromancy is evil.

Arise foul thread and haunt the living... Mwa ha ha ha !!!