I'm currently developing a PHP application that is going to use websockets for client-server communication. I've heard numerous times that PHP shouldn't be used for server applications because of the lack of threading mechanisms, its memory-management (cyclic references) or the unhandy socket library.
So far, everything is working quite well. I'm using phpws as the websocket library and the Doctrine DBAL to access different database systems; PHP is version 5.3.8 . The server should serve a maximum of 30 clients. Yet especially in the last days I've read several articles stating the ineffectiveness of PHP for long running applications.
Now I'm not aware whether I should continue using websockets with PHP or rebuild the entire serverside application. I've tried Python with Socket.IO, though I did not get the results I expected.
I guess I have the following options:
Keep everything as it is.
Make the application use Ajax in combination with Socket.IO - e.g. run a serverside script that invokes the client's ajax calls when data is submitted to the server.
The last point sounds quite interesting, though it would require some work .. Would it be a problem for servers to execute all the clients requests at one time?
What would you recommend? Is the problem with PHP's memory management (I'm using gc_collect each time a client sends data to the server) still valid? Are there other reasons beside the obvious reasons (no threading, ...) for not using PHP as a server?
You can try running your socket.io on a node server on another port on your server (that is if you are not using a hosting plan like goDaddy).
I am using it and the performances are really satisfying.
I have an apache server on the port 80 serving my php files, and my server-client communications are done using a Node.js server running socket.io on the port 8080 (dev) or 843 (prod).
Node.js is really light and has great performance, but you need to run it as a server. Nodejitsu.com is a hosting solution that has the websocket protocol available and is on beta, so it is still free for now. Just note that you need to listen on the port 80 with socket.io, this is a limitation from theyr network.
If you want your pages all to be accessed on the port 80 then you will need a reverse proxy like varnish .
I hope that helps! Have a nice day.
Are there other reasons beside the obvious reasons (no threading, ...)
for not using PHP as a server?
Yep, lots of socketfunctions are incompatible with each other and it's a hell to debug.
i tried something similar myself and quit frustrated sind every function i thought would make sense didnt do what i expected
Related
I am working on a site that is hosted on
goDaddy, through cPanel
The client wants to transition from their old PHP server to a node.js system.
They would like to implement new code in phases while leaving the old site up and running. The old and new code would be running on the same server.
I have a good break point for phase 1, but am not sure how to allow the PHP and node code to run simultaneously and listening for requests on the same server. I am familiar with node, but not as much with PHP.
In short- Can I have PHP and Node.js running simultaneously on the same server? If so, what considerations need to be made?
Thank you in advance!
You will most likely want to make it to where you migrate to the node.js service one endpoint at a time. That way you can test, debug, and fix things quickly without too much work. I recommend you use express for your router and whatever database connector you want. You will want to canary test between the two as well.
So I just watched this little tutorial on WebSockets and it makes sense, but for it to work, the websockets server file has to always be running, then users connect and messages are delivered to each other. However, I am confused on how this would be done on a website hosted with some hosting company, like Bluehost. As far as I know, you can't have a file always running on Bluehost, so how would this be accomplished? Or instead of having a file always running, for something like a chat where messages were saved into a database, would it be better to use something like long polling? Thanks!
Your observation is correct that the server must be running continuously to support live webSocket connections.
As such, you have to select a hosting company that allows and supports that particular configuration. Many of the cheapest shared hosting situations do not support that because their economics is based on the fact that your server isn't going to be running most of the time.
Here are some other answers on the topic:
PHP Websocket on Bluehost
php script Bluehost Websocket server
I don't know specifically about Bluehost, but some other similar companies require you to have a VPS (virtual private server) before you can run a the continuous server process needed to support long lived webSocket connections.
I want to implement a faceted search for a project of mine. I'm using PHP5, Mysql and Symfony 1.4. Apparently the commnunity points to Apache Solr which seems to do exactly what I want to accomplish.
The problem is that the website is going to be live on a hosting provider that doesn't allow me to setup Solr (it is a shared hosting environment and neither allows Tomcat nor Solr to be up-and-running).
So could you please give me directions on possible alternatives or if there is a way to setup Solr in such an environment?
EDIT
My hosting provider neither supports SOLR nor solutions as opensolr. In general I can't use my environment to connect to a process on the same server or a remote one. It seems the only available option is to use Zend_Search_Lucene. So does this support faceted searching? Or if you have another option in mind please share it! I feel being in the middle of nowhere!
EDIT 2
As this question is opened for about a week from the answers given so far I am surprised (and disappointed) that there is no library (not service) available in PHP to implement faceted search. It seems that either this needs to be implemented manually or use solutions provided below
Change hosts, or host the Solr index elsewhere - for example, a quick search revealed http://www.opensolr.com/ provide Solr hosting, there are no doubt many others.
Performance won't be great and don't discuss scaling, but you can always create a reverse HTTP tunnelling over HTTP. Basically, instead of the web server opening an outbound connection to the Solr server, it's the Solr server connecting to the web server to request jobs and to post job results.
What you'll need to do:
The browser post a search query, the query is simply queued in the database.
The reverse proxy periodically connects to the web server (over plain ol' port 80) to fetch a list of queries from the job queue, pass the queries to the Solr server, and POST the results back to the web server.
The browser periodically polls the web server for finished search result.
Bonus marks: if your server allows concurrent request processing, use long polling to improve latency.
In short, bite the bullet and move to a decent host.
Try to avoid Zend_Search_Lucene, it's not really fast. (Well it's pretty good given that it's implemented in Php and doesn't run as daemon)
Hosted Solr as Paul suggested sounds like a good alternative - if you are not willing to change host.
I have searched it in Google and here in stackoverflow there are some questions about it.
The problem is that many of them are old, so I guess that they use older and deprecated protocols instead of RFC 6455. I don't know if it is because of that or if I am doing something wrong, but when I try it it doesn't work.
So...
If I understand well, I can implement Websockets with aproppiate client (Javascript) and server (PHP) code, without needing to configure my Apache server. I am right?
Why the hell all examples I have found require me to go to command line and do
php -q C:\path\to\file\Websocket\Server.php
In the implementations I have found, there are a default server and port. Must I change them to the server (localhost) and port which I use for normal webpages? Or should I tell my server to listen to another port and use it for websocket communication?
Where can I find a good PHP implementation of Websockets (RFC 6455)?
Yes, that is correct.
Because the Websocket server doesn't use your web daemon to serve data. In this case, you're writing a server daemon completely in PHP.
You need to choose a port, since you're not using the web daemon to serve your websockets. Any port that's not in use will do.
Try Ratchet (main site here). We've been using the dev-master branch for a couple months in production now and we haven't had any problems. It's the only solution we found that out of the box will work with both Firefox clients and iPhones.
I used to have a small chat app(which was almost working), that uses PHP, jQuery and MySQL. The volume of users is very small (only my friends uses it). I used long polling method for this.
And now, I am thinking about using HTML5 Websockets for this, because it is a lot more efficient. And also most of my friends are using Google Chrome(which already supports HTML5). I have gone through some tutorials that talks about HTML5 websockets. And I have downloaded the phpWebSocket from github. I have gone through the code. But the readme file says that the PHP page that listens to incoming connections should be run using "PHP -q" from commandline. So, I have searched what this "q" flag would do. And I found that it runs the page in quiet mode. So, when I run this in quiet mode what is happened ? It would run endlessly ? Will this running process affect the system resources ?
This PHP page should run the entire time. Then only the connections could be accepted. Isn't it ?
I am having a shared hosting package with HostGator. And they allow cron jobs too. And my present chat app(that uses long polling method) inserts all the messages to database. When the user polls, it would search for any new messages from the database and then output them (if any).
So, I am bit stuck here. :(
It should be run from the command line because as you suspected, it is intended to run endlessly. It binds to a socket on the server and listens for incoming connections. It can't be reliably run from the browser.
The "-q" option tells it not to output any browser headers such as X-Powered-By: PHP or Content-Type: text/html
It will consume as much memory as PHP requires as long as its running. Your memory footprint on startup with no clients will vary between configurations. The more connected clients, the more cpu, memory and socket descriptors you will use. It uses select so it is efficient socket handling.
Also, since you're on shared hosting, you probably won't be able to use it because your user will most likely not have the ability to bind to a port and listen for connections.
As you can see in the demo, the URL to connect the WebSocket to is ws://localhost:12345/websocket/server.php. Unless you have a webserver capable of using WebSockets, you will have to run something like phpWebSocket that acts as a server and listens on a port other than 80.
Hope that helps.
The shared hosting package for HostGator does not allow clients to bind to local ports for incoming. This might be part of the problem.
http://support.hostgator.com/articles/pre-sales-policies/socket-connections