101–110 of 112 posts
Earlier quoted context omitted.
jrockway is a PHP troll. There is most certainly a history here that goes way back. Personally aggressive? Maybe. Deservedly? Probably.
Even if you're right, the point is that it degrades the site for everybody if you engage in it.
Earlier quoted context omitted.
Even if you're right, the point is that it degrades the site for everybody if you engage in it.
I am not a PHP troll, I just point out its technical weaknesses when people claim that it is technically superior to other solutions.
And definitely not in this post. And, yes, you are a troll.
Earlier quoted context omitted.
> PHP is considered extremely weak performance-wise I don't know, it seems a lot of the very high trafficked sites (Facebook, Yahoo) run PHP. Yes benchmarks do show PHP doing poorly, but when was the last time anyone used PHP to crunch numbers? It's apparently fast at what it needs to be fast for. > There is poor to no support of multithreading That is not a flaw. PHP is a share nothing architecture; each request is…
Multithreading isn't at all appropriate for PHP and I can't think of a scenario where it would be needed. Not blocking the entire PHP process while waiting for database results, waiting for a file to download, waiting for memcached to respond, etc. I would (and do) use an event loop for this sort of things, but lightweight threads are technically a better abstraction. Web apps would use a lot less memory (and hardwar…
Earlier quoted context omitted.
> PHP is considered extremely weak performance-wise I don't know, it seems a lot of the very high trafficked sites (Facebook, Yahoo) run PHP. Yes benchmarks do show PHP doing poorly, but when was the last time anyone used PHP to crunch numbers? It's apparently fast at what it needs to be fast for. > There is poor to no support of multithreading That is not a flaw. PHP is a share nothing architecture; each request is…
Multithreading isn't at all appropriate for PHP and I can't think of a scenario where it would be needed. Not blocking the entire PHP process while waiting for database results, waiting for a file to download, waiting for memcached to respond, etc. I would (and do) use an event loop for this sort of things, but lightweight threads are technically a better abstraction. Web apps would use a lot less memory (and hardwar…
The thing is, I need those database results -- I can't do anything else until I have them. I received a single request from the user and I'm spitting out a single HTML response back. That's what PHP is all about. And mulithreading as optimization itself wouldn't improve performance because I'd be taking away CPU from other requests that are running concurrently.
> Web apps would use a lot less memory (and hardware) if people were not so afraid of threads.
Fundamentally I don't disagree; there's a lot of cool work going with event-based web servers. However, I think those designs are great for very specific tasks like chat servers and but require too much fiddling when doing traditional stateless web work. However, it may indeed be the future.
Earlier quoted context omitted.
Multithreading isn't at all appropriate for PHP and I can't think of a scenario where it would be needed. Not blocking the entire PHP process while waiting for database results, waiting for a file to download, waiting for memcached to respond, etc. I would (and do) use an event loop for this sort of things, but lightweight threads are technically a better abstraction. Web apps would use a lot less memory (and hardwar…
> Not blocking the entire PHP process while waiting for database results, waiting for a file to download, waiting for memcached to respond, etc. The thing is, I need those database results -- I can't do anything else until I have them. I received a single request from the user and I'm spitting out a single HTML response back. That's what PHP is all about. And mulithreading as optimization itself wouldn't improve perf…
You could start requesting the database results for a user that is now waiting in the tcp connect queue, cutting latency significantly.
Most people handle this with load balancing between processes, but your blocked-for-DB-results-process is sitting idle using system resources, like memory.
If you only have one user using your site at a time, then this isn't a concern. But for everyone else, blocked processes are wasteful.
but require too much fiddling when doing traditional stateless web work
Well, yeah, because you don't have threads. When you do, everything is handled by libraries for you; you can think you're blocking, but actually not block the process.
Earlier quoted context omitted.
I am not a PHP troll, I just point out its technical weaknesses when people claim that it is technically superior to other solutions.
I've never seen someone say it's technically superior. I don't think any PHP dev in their right mind would even think of making that claim and I've certainly never seen such claims on here. And definitely not in this post. And, yes, you are a troll.
Earlier quoted context omitted.
> Not blocking the entire PHP process while waiting for database results, waiting for a file to download, waiting for memcached to respond, etc. The thing is, I need those database results -- I can't do anything else until I have them. I received a single request from the user and I'm spitting out a single HTML response back. That's what PHP is all about. And mulithreading as optimization itself wouldn't improve perf…
The thing is, I need those database results -- I can't do anything else until I have them. You could start requesting the database results for a user that is now waiting in the tcp connect queue, cutting latency significantly. Most people handle this with load balancing between processes, but your blocked-for-DB-results-process is sitting idle using system resources, like memory. If you only have one user using your…
That's already how it works. If one process is blocked waiting for results, another process will get it's turn. Apache is one process per HTTP connection (when not running threaded).
> but your blocked-for-DB-results-process is sitting idle using system resources, like memory.
Either way it will need to use system resources. I can't throw away the resources of the user waiting for results, I need that once the results come in! Processes really don't take up that much memory and typically you're reusing a small number of them over and over anyway.
> If you only have one user using your site at a time, then this isn't a concern.
If somebody is blocked then someone else's request gets a turn at the CPU. Blocking a single process is completely inconsequential to multi-process web server serving multiple users.
Earlier quoted context omitted.
The thing is, I need those database results -- I can't do anything else until I have them. You could start requesting the database results for a user that is now waiting in the tcp connect queue, cutting latency significantly. Most people handle this with load balancing between processes, but your blocked-for-DB-results-process is sitting idle using system resources, like memory. If you only have one user using your…
> You could start requesting the database results for a user that is now waiting in the tcp connect queue, cutting latency significantly. That's already how it works. If one process is blocked waiting for results, another process will get it's turn. Apache is one process per HTTP connection (when not running threaded). > but your blocked-for-DB-results-process is sitting idle using system resources, like memory. Eith…
They take up several orders of magnitude more memory than lightweight threads. I did some benchmarks a few months ago showing this; check searchyc if you care. Edit: here you are: http://news.ycombinator.com/item?id=794409
Anyway, when you start thinking about "web applications" instead of "web pages", lightweight threads make a lot more sense. And, you'll find that treating a web application like it's just a bunch of web pages leads to many problems down the road. (Performance is the least of your worries.)
Finally, "I definitely don't need to know about this abstraction because my favorite language doesn't have it" is dangerous thinking.
Earlier quoted context omitted.
It greatly depends on what you compare PHP to, but to highlight a handful of disadvantages, * PHP is considered extremely weak performance-wise * There is poor to no support of multithreading * There is no eventing system * As a web framework, it sins in mixing code & design (opposed to e.g. Django-Python or Ruby on Rails) (If the term "framework" seems unfit, think of "web-targeted toolkits")
PHP is not a framework.
I come from 4+ years of using it professionally and most of the higher level frameworks I'm talking about (Kohana, Zend, CodeIgniter, etc...) really only exist to overcome a lot of PHP's more abstract weaknesses (even though they can't really do much about the interpreter implementation).
I can easily say that something written in Python, Scheme, or whatever-you-choose will run a lot better, take less time to build, and be easier to manage down the road.
The primary problem in this industry is that the majority of web application programmers grew upon PHP and are running their own IP Consulting shops or startups by now and have zero experience with other languages, therefore making them much less interested in trying to adopt a different web development paradigm when an aspiring web developer with Python/Erlang/Scheme/Ruby skills under their belt try to build something with that tool chain in their employ.
The less knowledge and/or experience with other languages you have, the more rooted in what you are comfortable with you are. Education is a good thing, that is what I love about Hacker News; the people here experiment with new languages and trying out new technologies for their projects/products - which is much more progressive than the enterprise situation.
Earlier quoted context omitted.
> You could start requesting the database results for a user that is now waiting in the tcp connect queue, cutting latency significantly. That's already how it works. If one process is blocked waiting for results, another process will get it's turn. Apache is one process per HTTP connection (when not running threaded). > but your blocked-for-DB-results-process is sitting idle using system resources, like memory. Eith…
Processes really don't take up that much memory and typically you're reusing a small number of them over and over anyway. They take up several orders of magnitude more memory than lightweight threads. I did some benchmarks a few months ago showing this; check searchyc if you care. Edit: here you are: http://news.ycombinator.com/item?id=794409 Anyway, when you start thinking about "web applications" instead of "web pa…
Premature optimization; when a 1st grader can count to the number of processes you need for large scale web application optimizing it any more is a waste of time and effort.
> You'll find that treating a web application like it's just a bunch of web pages leads to many problems down the road.
Really? I find it refreshingly helpful. Instead of your large application being a large application, it actually just a series of very small applications. If a page crashes, it's pretty much no harm at all. If your whole application crashes, you're screwed. You want to add some functionality, just add it on.
> Finally, "I definitely don't need to know about this abstraction because my favorite language doesn't have it" is dangerous thinking.
"Oooh shiny" is also dangerous thinking. Is it really better to waste your time using up as many threads as possible or actually solving real problems for a few hundred processes?
Sidebar: Why is always you, Jonathan Rockway? Just how many posts do you make on Hacker news in a day? :)