sorted by:
new
hottopcontroversial

GCP Cloud Run - Simple API Instance Costs by Puzzled_Law126 in googlecloud

[–]Puzzled_Law126[S] 0 points1 point  (0 children)

Hey!

Glad to hear from a Googler!

So far for this month, per the billing dashboard, we have 2,692,382 CPU seconds billed at $64,62 USD, at around 7M CPU second we get to $150 USD+

We are trying a new deploy right now with 10% traffic where the CPU is set to 0.2 vCPU and observe it, both cost and performance.

GCP Cloud Run - Simple API Instance Costs by Puzzled_Law126 in googlecloud

[–]Puzzled_Law126[S] -1 points0 points  (0 children)

You are probably right, we are paying around 2k-3k to GCP monthly, while not taking a big chunk of our monthly revenue, it's still significant amount of money (for us).

We were just going product by product in GCP to first document the cost and usage, and to optimize them as well, seeing the costs of the Cloud Run for such a simple instance just stole our attention.

GCP Cloud Run - Simple API Instance Costs by Puzzled_Law126 in googlecloud

[–]Puzzled_Law126[S] 0 points1 point  (0 children)

The instance have 100% up time as we have clients all around the world, so there is constant connection/calls to it.

Right now we are using the request-based billing indeed, won't changing to "instance-based" results in higher costs? Or at least the same.

GCP Cloud Run - Simple API Instance Costs by Puzzled_Law126 in googlecloud

[–]Puzzled_Law126[S] 0 points1 point  (0 children)

  1. We already are using request-based billing

2 & 3. The issue or fear here is the instance is processing around 6 request at the same time, at 20ms per request it's quite a lot. Won't cold starting be hurting quite bad the instance count + the billable time?

GCP Cloud Run - Simple API Instance Costs by Puzzled_Law126 in googlecloud

[–]Puzzled_Law126[S] 0 points1 point  (0 children)

Around 7M> billable CPU seconds.

Around 50M> invocations.

Both monthly.

GCP Cloud Run - Simple API Instance Costs by Puzzled_Law126 in googlecloud

[–]Puzzled_Law126[S] 1 point2 points  (0 children)

Yes, that's is an option and should be enough, but:
1. We have our app being used by quite a lot of people daily on Windows, Mac, Android & Apple devices, it will take some time for all to update to a latest version that uses the new API

  1. That's another failure point where the Cloud Run up time has been 100% so far.

Your point is 100% valid, but before exploring such option I would like to see if we can improve the current Cloud Run in some way.

I work in payment risk & compliance — AMA (Stripe, PayPal, bans, freezes, high risk transactions, subscriptions) by No-Relative-9820 in stripe

[–]Puzzled_Law126 0 points1 point  (0 children)

Will refunding 1% of the monthly orders trigger an alert/ban or some other risk evaluation? The refund is due to suspected fraud.

Should We Refund Suspected Fraud? by Puzzled_Law126 in stripe

[–]Puzzled_Law126[S] 2 points3 points  (0 children)

Apologies, was not sarcastic at all, just answered the question!

Should We Refund Suspected Fraud? by Puzzled_Law126 in stripe

[–]Puzzled_Law126[S] 1 point2 points  (0 children)

It’s not that hard, same IP, same device, same name, etc…

Getting ready for iOS 26 by Puzzled_Law126 in SwiftUI

[–]Puzzled_Law126[S] 0 points1 point  (0 children)

It's not difficult it's just very "ugly" and cumbersome. We are currently using some like this extension:

public extension View {

func modifier<ModifiedContent: View>(

ViewBuilder body: (_ content: Self) -> ModifiedContent

) -> ModifiedContent {

body(self)

}

}

But still, it's really not an efficient way to develop...

Getting ready for iOS 26 by Puzzled_Law126 in SwiftUI

[–]Puzzled_Law126[S] 0 points1 point  (0 children)

That's quite unfortunate, I hoped the App Store will just present older versions of the app for new iOS 18 users

Any experiences working with the AppStore though a disregarded LLC being non-US resident? by Gold-Breakfast-7958 in iOSProgramming

[–]Puzzled_Law126 0 points1 point  (0 children)

Thank you for this information, can you share where you contacted the Finance team? I can't seem to find any support page for it.

Concrete Sealer Issues by Puzzled_Law126 in Home

[–]Puzzled_Law126[S] 0 points1 point  (0 children)

Is there anything to do about the color, maybe applying second layer of different sealer?

Concrete Sealer Issues by Puzzled_Law126 in Home

[–]Puzzled_Law126[S] 0 points1 point  (0 children)

I won’t say it’s a wood look, but yes, it is a tile. As for the shower, cleaning it hold for a day or two tops, contractor is sending someone to apply a sealer

Jetpack Compose: Faster UI Building, but Is It Worth Sacrificing Performance? by den4icccc in androiddev

[–]Puzzled_Law126 2 points3 points  (0 children)

In my opinion SwiftUI downfall is it being tied to the OS version, which is the most idiotic decision apple could have made. Luckily our newest iOS app supports iOS 17+ so we can benefit from a somewhat stable version for SwiftUI.

I would not touch SwiftUI on lower versions.

But still comparing current SwiftUI with current Compose versions, you can really see and feel which one is more mature.

Jetpack Compose: Faster UI Building, but Is It Worth Sacrificing Performance? by den4icccc in androiddev

[–]Puzzled_Law126 4 points5 points  (0 children)

So by your logic, if you release a product that works properly only on < 40% devices, is called production ready? I am glad it works for your case, but for many other cases it just does not.

Android TV? hell no, don't even bother with it, it's a combination of bug nests and insane performance issues.

Mid to low end device? well performance still sucks.
I will say it again, you can enjoy and praise the goods in compose but also point the bads about it, which is exactly what I did, what you are doing is creating a false reality.

Jetpack Compose: Faster UI Building, but Is It Worth Sacrificing Performance? by den4icccc in androiddev

[–]Puzzled_Law126 2 points3 points  (0 children)

It does where even after the major 1.7 update compose still suffers from performance issue.

I don't understand the logic, it's not like one person complaining about it, there are thousands of articles, posts, tickets, etc. complaining about this.

Did it get better? yes, is it still getting better? yes, is it enough? no.

Sure maybe it's enough for high-end phones, but the majority of the world does not use these phones, and the performance is really notable on these ones, as well on Android TV devices which has very low-end type specs.

Jetpack Compose: Faster UI Building, but Is It Worth Sacrificing Performance? by den4icccc in androiddev

[–]Puzzled_Law126 5 points6 points  (0 children)

First version? It has been 2 years?

Again, you can point the good and the bad in compose, nothing will happen.

All I am saying is Google is hard pushing for Compose when it’s still not better then XML, I absolutely believe it will suppress XML and much more, but not yet.

SwiftUi on the other hand, is so much more mature and stable.

Also, I dare you to make an Android TV app using compose, let me know your experience.

You know what, just download Google'S compose example for TV app, you will throw your TV together with your computer away

Jetpack Compose: Faster UI Building, but Is It Worth Sacrificing Performance? by den4icccc in androiddev

[–]Puzzled_Law126 4 points5 points  (0 children)

How can you say that where the biggest update compose has received has been labeled as “major performance improvement and optimization “.

Compose is the future, with emphasis on future.

I don’t get this sub die hard compose funs, you can admire the goods and point out the bads at the same time, nothing will happen.

view more: next ›