Jump to content

PHP Socket Server vs *


Alex

Recommended Posts

Because PHP, being an interpreted language, will always be slower than a compiled language such as C++ or C#, I'm wondering what's a bigger factor in determining how many connections a server can handle: The Speed of the language (Interpreted vs. Compiled) or the processing power of the computer and the ability of the internet connection of the server.

 

In short, is it feasible to make a socket server using PHP CLI that can maintain a large amount of connections, or would it be more practical to go with a compiled language?

Link to comment
Share on other sites

(In the following post, I basically ignore C# since I know very little about it.  Also, I realize C and C++ are not the same, but they are the same base, and they are very comparable in speed [assuming the coding style is the same... {in particular if OOP is used or not}].)

 

 

This day in age when computers do billions of operations per second, the speed of language is really quite negligible.

 

 

It's worth noting, by the way, that most of the slow down of PHP is actually the interpretation of it which only happens once (so for a script that would run indefinitely it wouldn't matter much).  The core of PHP is written in C which gets transfered down to byte code (everything of course goes to byte code in the end).

 

 

But, although C and PHP both end up in byte code (ignore interpretation time), PHP is still very, very slightly slower.  (Basically because things can't be optimized as much as they could be if written in C because the variables used behind PHP have to be flexible and whatnot.)

 

 

Anyway, when it comes down to it, unless it's something that .001% run time (probably even less) whether it's written in PHP or C will not make much of a difference.

 

 

 

But, I advise against PHP in this particular case because of 1 important thing...  Socket queuing.  PHP is single threaded, which means that you can only have 1 thing going on at a time in the program.

 

 

In other words, let's say you have 2 connections (assume the connection speed of your server is something high enough to handle both connections).  Connection A is 10KB/s up and down, and Connection B is a 10MB/s up/down conn.  Client A has to send your program 1MB, and client B has to send 1MB also.  Only one socket can be read at a time in PHP (due to only having 1 thread), so client B will not be able to send his/her content until client A's is done sending (unless client B's socket gets read first).

 

 

Anyway, that was a horribly worded example, but what I mean is each socket has to wait on the one in front of it, so the waiting time can add up VERY quickly (especially if a super slow connection is thrown into the mix).

 

 

Also, more than 1 task can't be processed at a time.

 

 

 

 

 

 

So, my tl;dr for you is as follows:

 

Use a language that has threading.  Yes, threading brings up entirely new issues of locking and queue management, but the gained efficiency is well worth the added complexity.

 

 

 

 

As for answering your abstract question instead of the specific example:

 

 

"I'm wondering what's a bigger factor in determining how many connections a server can handle: The Speed of the language (Interpreted vs. Compiled) or the processing power of the computer and the ability of the internet connection of the server."

 

Think of it like bottlenecks.  Of course which ever one is the bigger (metaphorically bigger, smaller in the sense of liquid passing through ;p) bottleneck will be the one that matters the most.

 

The important of the speed of the language really depends on how much efficiency is needed, and how fast the computer is.  The internet connection speed can vary in how much it matters.  For 10 clients, 1MB/s and 100MB/s won't make much of a difference depending on what's going on, but with 1000 users, that can make HUGE difference even if throughput is fairly small.

 

tl;dr:  It entirely depends on the situation: how much data is going through, how slow the language is, so on.

Link to comment
Share on other sites

Typically I would go with C++ and make it multi-threaded, but in this case the amount of information being sent and received will be very limited. I can't imagine that it would be more than .5KB at a time. I was just worried about the processing speed of PHP.

 

Thanks for shedding some light on this, it's really appreciated  :)

Link to comment
Share on other sites

PHP is single threaded, which means that you can only have 1 thing going on at a time in the program.

 

PHP is capable of forking new processes when used outside of a web server environment, couldn't this be used to work around the entire threading issue?

 

There are web servers written in php. I actually used nanoweb to host my blog for over 12 months a while back. Mind you, I didn't get more than a few dozen hits per day.

Link to comment
Share on other sites

True....  I didn't think about forking.  (Forking would only be an option if the server is linux, but I would guess that it is.)

 

Not sure why I entirely forgot about forking lol (probably because I develop on Windows 99% of the time ;p).

 

 

Dang now I'm curious how the performance of an application using forking would compare to something that uses threads.  Might have to test that later lol.

Link to comment
Share on other sites

That's interesting, I read about forking processes in PHP to replicate threading a while ago, but there didn't seem to be a whole lot of material on it. I'm gonna have to mess around with that  :P

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.