Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A Better Log Service

txtlog.net

Post reply on HN
Print view View original

71–80 of 109 posts

Re: Show HN: A Better Log Service

#71

Post by Implicated »

mdaniel wrote: post #55
voytec wrote: post #52

Earlier quoted context omitted.

Off-topic, but thanks for the neat trick with url#:~:text=blah

It's actually a standard! https://developer.mozilla.org/en-US/docs/Web/Text_fragments It can do a bunch of awesome stuff, but the text= one is the one I use the most I finally started using it when it landed on Firefox release (although, in true Firefox fashion, they give no fucks about the UX forcing me to install an extension that is "create link to selection")

I too must thank you for this, I had no idea this existed and likely will be making regular use of it now :)

Re: Show HN: A Better Log Service

#72

Post by mrngm »

that_guy_iain wrote: post #39
axelthegerman wrote: post #29

Earlier quoted context omitted.

If that "bottleneck" is thousands of requests per second then it doesn't really matter for smaller deployments does it? (Which seems to be the target audience and not FAANG) I'm not a big fan when folks call out languages as bottlenecks when they have no proof on the actual overhead and how much faster it would be in another language.

To tweak a PHP deployment to handle hundreds of requests per second which is very very realistic for a basic logging for a mid-sized application you're looking at having a very beefy server setup. Most PHP deployments barely reach a hundred per server. And this is an open source project is should be designed to handle basic production workloads which it could but it'll cost you a bunch more than if you used the corre…

Well, looking at our bespoke logging system in PHP handling some 15-20+ million log entry's per day on a virtualized dual-core system... it's mostly disk I/O on the underlying MySQL database (currently duplicating to Clickhouse where we'll eventually store everything). And that is central application logging for about 100 servers (think syslog), some 400 "microservices" (parts of a larger application), and a handful of backend systems.

We're running out of disk space earlier than that PHP is a bottleneck here.

Re: Show HN: A Better Log Service

#73

Post by skeeter2020 »

adriand wrote: post #47

I’m curious about the open source nature of this and how you / people in general manage a project where you are hosting it and need to maintain its security, but are also presumably merging pull requests as people contribute to the project. I would be quite paranoid about this, ie concerned that someone might slip a line of code in with the intent of breaching the service that I would not catch during code review. I…

For users of OS projects, a very common approach is to clone into a private repo, then only pull upstream changes within your own timeline/process, and potentially open public PRs at some point after working in private, i.e. you do your business in private, and share in the public part as & when works. For the project maintainer people can open PRs whenever they want but you are under no obligation to accept them or use any of the code; they're doing this to help others but don't need to for their own scenario.

Re: Show HN: A Better Log Service

#74

Post by Implicated »

that_guy_iain wrote: post #58
hipadev23 wrote: post #41

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…

What you're talking about is generally not considered production-ready. While you can use these tools you will almost certainly run into problems. I know this because as an active PHP developer for over a decade I'm very much paying attention to that field of PHP. What we see here is a classic case of benchmarks saying one thing when the reality of production code says something else. Also, I used go as a generic exa…

> ... you can have Go doing thousands of requests per second vs PHP doing hundreds of requests per second.

> I know this because as an active PHP developer for over a decade I'm very much paying attention to that field of PHP.

As an active PHP developer as well it sounds like you have no idea what you're talking about.

> While you can use these tools you will almost certainly run into problems.

Which tools are "generally not considered production-ready"? From what I'm seeing on the linked list of benchmarks...

- vanilla php - workerman - ubiquity - webman - swoole

I'd venture to bet all of these are battle tested and production ready - years ago now.

As someone who has built a handful of services that ingest data in high volume through long-running PHP processes... it's stupidly easy and bulletproof. Might not be as fast as go, but to say these libraries or tech isn't production-ready is rather naive.

Re: Show HN: A Better Log Service

#75

Post by [deleted] »

p_ing wrote: post #56
hipadev23 wrote: post #41

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…

As soon as you add C#, ASP.NET Core shoots to the top of the Fortune stack.

[deleted]

Re: Show HN: A Better Log Service

#76

Post by hipadev23 »

that_guy_iain wrote: post #58
hipadev23 wrote: post #41

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…

What you're talking about is generally not considered production-ready. While you can use these tools you will almost certainly run into problems. I know this because as an active PHP developer for over a decade I'm very much paying attention to that field of PHP. What we see here is a classic case of benchmarks saying one thing when the reality of production code says something else. Also, I used go as a generic exa…

Nobody is suggesting PHP beats compiled. We’re arguing with you about your utter lack of expertise in the language, knowledge of the ecosystem and “production-ready” status of the many options, and your overall coding ability when it comes to PHP.

Re: Show HN: A Better Log Service

#78

Post by nesarkvechnep »

lukevp wrote: post #65
nesarkvechnep wrote: post #51

Some people praised Go as a better language for the use case than PHP. I’d say Elixir is even better. It can handle massive concurrency easy, can be made distributed easy, has a built-in, in-memory, key-value store (ETS), and is probably the best high-level language for anything that’s facing the network.

I've really been interested in learning more about Elixir and how it accomplishes these things, because I constantly hear the same opinions from others. Do you have some good resources you'd recommend for getting started with Elixir for a principal engineer that wants to understand these at-scale issues and how Elixir solves them better than other languages?

Yes, two books. To get a feel for the language - “Elixir in Action” by Sasa Juric. To discover how Elixir and the platform it’s built on excel in scalability and fault-tolerance - “Designing for Scalability with Erlang/OTP” by Francesco Cesarini.

Re: Show HN: A Better Log Service

#79

Post by Implicated »

that_guy_iain wrote: post #39
axelthegerman wrote: post #29

Earlier quoted context omitted.

If that "bottleneck" is thousands of requests per second then it doesn't really matter for smaller deployments does it? (Which seems to be the target audience and not FAANG) I'm not a big fan when folks call out languages as bottlenecks when they have no proof on the actual overhead and how much faster it would be in another language.

To tweak a PHP deployment to handle hundreds of requests per second which is very very realistic for a basic logging for a mid-sized application you're looking at having a very beefy server setup. Most PHP deployments barely reach a hundred per server. And this is an open source project is should be designed to handle basic production workloads which it could but it'll cost you a bunch more than if you used the corre…

> To tweak a PHP deployment to handle hundreds of requests per second which is very very realistic for a basic logging for a mid-sized application you're looking at having a very beefy server setup.

There's just no way that you're at all familiar with PHP of the last 10 years to think this is true.

> It could be easily proven by doing a bunch of work but obviously there is no point in me proving it.

Prove it. Please, show me the context and environment you think PHP would struggle to serve "hundreds of requests per second". I'd venture a bet that a plain Laravel installation on the cheapest digital ocean droplet would top this and Laravel is "slow" in relation to vanilla PHP.

Post reply on HN