81–90 of 109 posts
Earlier quoted context omitted.
It uses Clickhouse, though, which should be xtremelly fast for this.
Yes. But PHP still needs to process it before it goes to Clickhouse. PHP is the bottleneck.
The author writes that Clickhouse takes 0.1s for an example request: https://news.ycombinator.com/item?id=42666703
PHP would need to be adding 0.1s CPU time for processing the request for the PHP code to become the bottleneck. That seems unlikely.
Earlier quoted context omitted.
I'm sure you've heard of PHP's opcache by now. That's not experimental and actually caches the interpreted code in memory for faster subsequent execution.
Yes, it makes it faster but does not deal with the core performance issues which is why Roadrunner, Frankenphp, etc exist.
Earlier quoted context omitted.
I'm going to have to also reply with, sorry but what?! PHP is one of the fastest-interpreted languages. But compiled are going to be faster than interpreted pretty much everytime. It loses benchmarks against every language. That's not to mention it's slowed down by the fact it have to rebuild everything per request. As a PHP developer for 15+ years, I can tell you what PHP is good at and what PHP is not good at. High…
How have you worked with PHP for 15 years and have absolutely no idea how it works or even baseline performance metrics.
Earlier quoted context omitted.
No, it's because I've got productive things to do that do benchmarks that have already been done repeatedly. The only way to get PHP to the same speed as compiled languages for web requests is to use experimental tooling. I notice your benchmarks are over 10 runs?! That's not a good sample size. And even more importantly, it's not in the same context. Sure once you compile PHP and have it running it'll run fast. But…
> That's not a good sample size. Like I said in the blog post, if I tell you the sky is blue and you don't believe me; run them yourself. FWIW, C# is faster now for that particular use case. Also, like I mentioned in a previous blog post ... which one would you rather maintain: - https://github.com/TheAlgorithms/C-Sharp/blob/master/Algorit... -- merge sort in C# 130 lines - https://www.w3resource.com/php-exercises/se…
Earlier quoted context omitted.
No, it's because I've got productive things to do that do benchmarks that have already been done repeatedly. The only way to get PHP to the same speed as compiled languages for web requests is to use experimental tooling. I notice your benchmarks are over 10 runs?! That's not a good sample size. And even more importantly, it's not in the same context. Sure once you compile PHP and have it running it'll run fast. But…
> That's not a good sample size. Like I said in the blog post, if I tell you the sky is blue and you don't believe me; run them yourself. FWIW, C# is faster now for that particular use case. Also, like I mentioned in a previous blog post ... which one would you rather maintain: - https://github.com/TheAlgorithms/C-Sharp/blob/master/Algorit... -- merge sort in C# 130 lines - https://www.w3resource.com/php-exercises/se…
This looks very interesting! My suggestion for the self-hosting is to create docker images and use docker-compose. The self-hosting currently is a bit of effort to setup. I also wonder if PHP is a good language for this. For the UI, yea that's fine and makes sense. But for the log processor that's going to need to handle a high throughput which PHP just isn't good at. For the same resources, you can have Go doing tho…
> PHP doing hundreds of requests per second. You may want to update your understanding of PHP and Go's speed . Both of your estimates are off by a couple orders of magnitude on commodity hardware. There are also numerous ways to make PHP extremely fast today (e.g. swoole, ngx_php, or frankenphp) instead of the 1999 best practice of apache with mod_php. Go is absolutely an excellent choice, but your opinion on PHP is…
In a different PHP project, we have a bunch of background jobs which process large amounts of data, and they routinely go OOM because PHP stores data in a very inefficient way compared to Go. In Go, it's trivial to load hundreds of thousands objects into memory to quickly process them, but PHP already starts falling apart before we hit 100k. So we have to have smaller batches (= make more API calls), and the processing itself is much slower as well. And you can't easily parallelize without lots of complex tricks or additional daemons (which you need to set up and maintain). It's just more effort, more waste of time and more RAM/CPU for no particular gain.
Earlier quoted context omitted.
> PHP doing hundreds of requests per second. You may want to update your understanding of PHP and Go's speed . Both of your estimates are off by a couple orders of magnitude on commodity hardware. There are also numerous ways to make PHP extremely fast today (e.g. swoole, ngx_php, or frankenphp) instead of the 1999 best practice of apache with mod_php. Go is absolutely an excellent choice, but your opinion on PHP is…
Sure, PHP can process logs of any volume, but it would require 5–10 times more servers to handle the same workload as something like Go. Not to say Go just works out of the box while for PHP you must set up all those additional daemons you listed and make sure they work -- more machinery to maintain, and usually they have quite a lot of footguns, too. Like, recently our website went down with just 60 RPS because of a…
Earlier quoted context omitted.
> PHP doing hundreds of requests per second. You may want to update your understanding of PHP and Go's speed . Both of your estimates are off by a couple orders of magnitude on commodity hardware. There are also numerous ways to make PHP extremely fast today (e.g. swoole, ngx_php, or frankenphp) instead of the 1999 best practice of apache with mod_php. Go is absolutely an excellent choice, but your opinion on PHP is…
Sure, PHP can process logs of any volume, but it would require 5–10 times more servers to handle the same workload as something like Go. Not to say Go just works out of the box while for PHP you must set up all those additional daemons you listed and make sure they work -- more machinery to maintain, and usually they have quite a lot of footguns, too. Like, recently our website went down with just 60 RPS because of a…
I'm not going to argue that PHP is _better_ than Go. Just starting off with that.
But if your background jobs are going OOM when processing large amounts of data it's likely that there's better ways to do what you're trying to do. It is true that it's easy to be lazy with memory/resources with PHP due to the assumption that it'll be used in a throwaway fashion (serve request -> die -> serve request -> die) - but it's also perfectly capable of long-running/daemonized processes that aren't memory issues rather trivially.
Earlier quoted context omitted.
Sure, PHP can process logs of any volume, but it would require 5–10 times more servers to handle the same workload as something like Go. Not to say Go just works out of the box while for PHP you must set up all those additional daemons you listed and make sure they work -- more machinery to maintain, and usually they have quite a lot of footguns, too. Like, recently our website went down with just 60 RPS because of a…
This isn't a PHP problem, this is a configuration problem. You shouldn't be using the filesystem to handle your sessions in a production application.
In contrast, Go can efficiently manage thousands of such blocked goroutines without issue. Sure, you can address this problem in PHP, but you need:
- understand PHP-FPM (or whatever you use) configs and their footguns
- understand NGINX configs and their footguns
- fiddle with PHP configs/optimizing your code to fit within PHP's maximum limits
- rent larger servers to have the same throughput