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

41–50 of 109 posts

Re: Show HN: A Better Log Service

#41

Post by hipadev23 »

that_guy_iain wrote: post #2

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 quite dated. Here are benchmarks for numerous Go (green) and PHP (blue) web frameworks: https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...

Re: Show HN: A Better Log Service

#42

Post by xinu2020 »

herbst wrote: post #27
that_guy_iain wrote: post #2

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…

On the other side some people (me) are happy to have an actual self hosting setup and not being forced to use a docker setup with unknown overhead.

Why not both? It's not much trouble to publish a Dockerfile while still documenting a normal installation.

Re: Show HN: A Better Log Service

#43

Post by mdaniel »

What in the world does this mean? https://txtlog.net/doc#:~:text=use%20your%20local%20time%20w... That's made twice as bad by the "we throw away Z because you were just kidding by including it". That leads me to believe that any RFC 3339 that isn't automatically Z (e.g. 1996-12-19T16:39:57-08:00 https://datatracker.ietf.org/doc/html/rfc3339#section-5.8>) is ... well, I don't know what it's going to do but it likely won't be good

It also appears that your documentation is currently a very verbose version of an OpenAPI spec, so you may save your readers some trouble by actually publishing one, with the added advantage that they come with a "Try it" button in the OpenAPI renders

That would allow you to save the natural language parts for describing things that are not API-centric (such as the "but WWWWHHHHYYY mysql AND clickhouse" that you alluded to elsewhere but wasn't mentioned at all in /doc nor /selfhost)

Re: Show HN: A Better Log Service

#44

Post by hipadev23 »

that_guy_iain wrote: post #12
withinboredom wrote: post #6

Earlier quoted context omitted.

PHP is arguably the best solution here. If a log ingestion process breaks everything, no other logs are harmed (a default shared-nothing architecture). Using something like Go, C#, etc, it might be "faster" but less resilient -- or more complex to handle the resiliency. > But for the log processor that's going to need to handle a high throughput which PHP just isn't good at. I'm sorry, but wut? PHP is probably one of…

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.

Re: Show HN: A Better Log Service

#46

Post by herbst »

xinu2020 wrote: post #42
herbst wrote: post #27

Earlier quoted context omitted.

On the other side some people (me) are happy to have an actual self hosting setup and not being forced to use a docker setup with unknown overhead.

Why not both? It's not much trouble to publish a Dockerfile while still documenting a normal installation.

It's not, but more often than not it's just a dockerfile

Re: Show HN: A Better Log Service

#47

Post by adriand »

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 know this is true of any open source project but it feels especially fraught when you are also hosting it and letting people sign up and pay for it. I’m wondering if you or others have experience with this and what approaches and practices mitigate this risk.

Re: Show HN: A Better Log Service

#48

Post by tyingq »

mdaniel wrote: post #43

What in the world does this mean? https://txtlog.net/doc#:~:text=use%20your%20local%20time%20w... That's made twice as bad by the "we throw away Z because you were just kidding by including it". That leads me to believe that any RFC 3339 that isn't automatically Z (e.g. 1996-12-19T16:39:57-08:00 https://datatracker.ietf.org/doc/html/rfc3339#section-5.8 >) is ... well, I don't know what it's going to do but it likely…

The date treatment isn't great, but the repo seems to indicate it's existed as a public thing for 22 days. So perhaps just an early compromise to get it working.

Re: Show HN: A Better Log Service

#49

Post by mdaniel »

tyingq wrote: post #48
mdaniel wrote: post #43

What in the world does this mean? https://txtlog.net/doc#:~:text=use%20your%20local%20time%20w... That's made twice as bad by the "we throw away Z because you were just kidding by including it". That leads me to believe that any RFC 3339 that isn't automatically Z (e.g. 1996-12-19T16:39:57-08:00 https://datatracker.ietf.org/doc/html/rfc3339#section-5.8 >) is ... well, I don't know what it's going to do but it likely…

The date treatment isn't great, but the repo seems to indicate it's existed as a public thing for 22 days. So perhaps just an early compromise to get it working.

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/datetimeimmutable.createfromfo...

I do love this, since it 100% squares with my mental model of PHP's approach to life: you're holding it wrong https://www.php.net/manual/en/function.date-parse-from-forma...

Re: Show HN: A Better Log Service

#50

Post by hk1337 »

It's a minor thing but I would remove the jQuery dependency. You're not doing much with that plain javascript couldn't do just as well if not better. Plain JS has come a long way since jQuery first came out.
Post reply on HN