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

91–100 of 109 posts

Re: Show HN: A Better Log Service

#91

Post by withinboredom »

neonsunset wrote: post #84
withinboredom wrote: post #66

Earlier quoted context omitted.

> 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…

You do realize that you are comparing two different implementations with different type systems that use different abstractions? Clearly you can't be serious. So, unless you are being intentionally misleading, this raises questions about the quality of "PHP solution" that is being worked on.

I'm being serious in using it as an example of maintainability/expressiveness. The difference is deliberate, not accidental. I've written 15 PHP lines that would be hundreds of lines in C#, and I've written 15 lines of Go that would be hundreds of lines of PHP. Every language has its own strengths and weaknesses and levels of complexity. PHP fits into a sweet spot (IMHO) of low-levelness and high-levelness, but it is often not seriously considered due to its reputation in the 00's.

Re: Show HN: A Better Log Service

#92

Post by Implicated »

kgeist wrote: post #90
Implicated wrote: post #87

Earlier quoted context omitted.

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.

Anything that unexpectedly blocks a process can bring down your entire PHP server because you will run out of worker processes. For example, imagine you experience a spike in requests while another server you're trying to call is timing out. You can't set the maximum worker count to a very high value because the operating system has an upper limit. Since the limit must remain low enough, you can quickly run out of yo…

True. I stand corrected.

This is a footgun, regardless of if it's a block from file systems or remote requests or whatever.

My claim that it's a configuration problem is just a 'fix' and there are ultimately an unlimited list of ways this same thing can come up to bite you. Well, outside of aggressive timeouts - and even then, with enough volume of requests that's even not going to save you :D

Re: Show HN: A Better Log Service

#93

Post by piterrro »

> there are many log services available and this is my attempt at a better one.

Out of curiosity, can you describe how your service is better than others?

>I hope my application fixes most of these issues

Do you care to elaborate on the "how"?

Re: Show HN: A Better Log Service

#94

Post by [deleted] »

withinboredom wrote: post #91
neonsunset wrote: post #84

Earlier quoted context omitted.

You do realize that you are comparing two different implementations with different type systems that use different abstractions? Clearly you can't be serious. So, unless you are being intentionally misleading, this raises questions about the quality of "PHP solution" that is being worked on.

I'm being serious in using it as an example of maintainability/expressiveness. The difference is deliberate, not accidental. I've written 15 PHP lines that would be hundreds of lines in C#, and I've written 15 lines of Go that would be hundreds of lines of PHP. Every language has its own strengths and weaknesses and levels of complexity. PHP fits into a sweet spot (IMHO) of low-levelness and high-levelness, but it is…

[deleted]

Re: Show HN: A Better Log Service

#96

Post by giraffe_lady »

TripleChecker wrote: post #77

It looks like that's a PHP codebase. I'm curious why one should use this solution instead of more performant Go/Rust log backends? Also, one of the login links takes you to a 404 page: https://triplechecker.com/s/jDTmQa/txtlog.net

They said

> Most of my development career has been with C#, NodeJS and PHP

and then

> The architecture is very scalable, but I've only tested up to a few billion logs.

Re: Show HN: A Better Log Service

#97

Post by tyingq »

Implicated wrote: post #70
mdaniel wrote: post #49

Earlier quoted context omitted.

For all the folks championing how awesome PHP is in this thread, one would surely hope it has rfc3339 aware date parsing, no? But I guess that https://www.php.net/manual-lookup.php?pattern=rfc%203339&sco... > and https://www.php.net/manual-lookup.php?pattern=iso8601&scope=... > both being :shruggle: doesn't do it any favors. However, it seems it is just a search stupidity because https://www.php.net/manual/en/datetim…

Given the tone and wording of your comments I hesitated to even reply but, alas, my love for PHP was strong enough to push me through. You are, actually, doing it wrong. https://carbon.nesbot.com/docs/ I forgive you, being that you're clearly not familiar with modern PHP and it's incredibly mature and diverse library ecosystem and first class package manager. > However, it seems it is just a search stupidity ... You'…

Pretty sure that doesn't handle the 'Z' timezone offset, as I saw the same with various PHP built-ins. Some ignore offsets, some don't...but handle only specific formats and not others, including the Z. So you still need some kind of wrapper.

Re: Show HN: A Better Log Service

#98

Post by [deleted] »

kgeist wrote: post #86
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…

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…

[deleted]

Re: Show HN: A Better Log Service

#99

Post by [deleted] »

kgeist wrote: post #90
Implicated wrote: post #87

Earlier quoted context omitted.

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.

Anything that unexpectedly blocks a process can bring down your entire PHP server because you will run out of worker processes. For example, imagine you experience a spike in requests while another server you're trying to call is timing out. You can't set the maximum worker count to a very high value because the operating system has an upper limit. Since the limit must remain low enough, you can quickly run out of yo…

[deleted]

Re: Show HN: A Better Log Service

#100

Post by thunky »

robocat wrote: post #81
that_guy_iain wrote: post #13

Earlier quoted context omitted.

Yes. But PHP still needs to process it before it goes to Clickhouse. PHP is the bottleneck.

Are you sure 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.

That 0.1s is to write 4k rows to clickhouse, not per (log write) request.
Post reply on HN