81–90 of 96 posts
Earlier quoted context omitted.
We use 5 ec2 instances to serve around 32 million requests per day on PHP, all under 100ms. It is not the language.
Framework or custom app?
My experience scaling up Rails (mostly in size of codebase NOT in size of traffic) really made me love typesafe languages. IDE smartness (auto complete, refactoring), compile error instead of runtime, clear APIs... Kotlin is a pretty nice "Type-safe Ruby" to me nowadays.
Earlier quoted context omitted.
"For millions of users the CPU cost difference probably justifies the rewrite cost." This is only true if you have expensive computations done in Ruby or Python or similar, which is very rarely the case.
Not true, Ruby and Python are absurdly slow at even trivial tasks. Moving stuff around in memory, which is most of what a webapp is, is expensive. Lots of branches is gonna be really expensive too.
Scaling a non-scalabe by default framework that should have been few services written in a performance first language at a billion+ USD company. I am not sure why are we boliling the oceans for the sake of a language like Ruby and a framework like Rails. I love those to death but Amazons approach is much better (or it used to be): you can't make a service for 10.000+ users in anything else than: C++, Java (probably R…
You really do not know what you are talking about, it is not about the language, like it was repeated in this forum many many times already. We serve an application in PHP to thousands of users per second in less than 100ms constantly.
> it is not about the language
Sure how about these people?
https://thenewstack.io/which-programming-languages-use-the-l...
Earlier quoted context omitted.
Sometimes it is the language. Or at least the ecosystem and libraries available. My go-to example is graphql-ruby, which really chokes serializing complex object graphs (or did, it's been a while now since I've had to use it). It is pretty easy to consume 100s of ms purely on compute to serialize a complex graphql response.
I have mixed feelings about this. It's saying that python is too slow for data science ignoring that python can outsource that work to Pandas or NumPy. For GraphQL on Rails you can avoid graphql-ruby and use Agoo[1] instead so that that work is outsourced to C. So in practice it's not a problem. 1. https://github.com/ohler55/agoo
Exactly. So C/C++/Fortrant is better in this regard than Python.
Earlier quoted context omitted.
Having at least 2 web servers and a read-only DB replica for redundancy/high availability is very easy and much safer. Yes, setting up a single-server is faster, but if your DB server dies - and at some point it will happen - you'll not just save a lot of downtime, but also a lot of stress and additional work.
my startup has a similar setup (elixir + postgres). we use aurora so we get automated failover. its more expensive but its just a cost of doing business.
Earlier quoted context omitted.
Interestingly I have had almost the exact opposite experience being very frustrated with the Django docs. To be fair, it could be because I'm frustrated with Django's design decisions having come from Rails. When learning Django a few years ago, I still carry a deep loathing against polymorphism (generic relations[0]), and model validations (full clean[1]), You know what - it's design decisions... [0] https://docs.dj…
Would love to hear more about what you don't like with model validations (full clean).
But yea, I can complain at length.
- Model validations aren't run automatically. Need to call full_clean manually.
- EXCEPT when you're in a form! Forms have their own clean, which IS run automatically because is_valid() is run.
- This also happens to run the model's full_clean.
- DRF has its own version of create which is separate and also does not run full_clean.
- Validation errors in DRF's Serializers are a separate class of errors from model validations and thus model Val Errors are not handled automatically.
- Can't monkey patch models.Model.save to run full_clean automatically for because it breaks some models like User AND now it would run twice for Forms+Model[0].
Because of some very old web-forum style design decisions, model validations aren't unified thus the fragmentation makes you need to know whether you're calling .save()/.create() manually, are in a form, or in DRF. And it's been requested to change this behavior but it breaks backwards compat[0].
It's frustrating because in Rails this is a solved problem. Model validations ALWAYS run (and only once) because... I'm validating the model. Model validations == data validations which means it should be true for all areas regardless of caller, except in exceptions, then I should be required to be explicit when skipping (i.e. Rails) where as in Django I need to be explicit in running it - sometimes... depends where I am.
[0] https://stackoverflow.com/questions/4441539/why-doesnt-djang...
Earlier quoted context omitted.
my startup has a similar setup (elixir + postgres). we use aurora so we get automated failover. its more expensive but its just a cost of doing business.
Last time I looked at Aurora (just as it came out) it was hilariously expensive. Are the costs better now for a real use case?
It still is. But you have to look at it in perspective. do you have customers that NEED high availability an will pull out pitch forks if you are down for even a few minutes? I do. the peace of mind is what you're paying for in that case.
Plus its still cheaper than paying a devops guy a fulltime salary to maintain these systems if you do it on your own.
Earlier quoted context omitted.
was it? i read it was a huge ram server
https://stackexchange.com/performance
However, if they have a peak of 450 web requests per second and somewhere between 11000 - 23800 SQL queries per second, that'd mean between 25 - 53 SQL queries to serve a single request. There's probably a lot of background processes and whatnot (and also queries needed for web sockets) that cut the number down and it's not that bad either way, but I do wonder why that is.
The apps with good performance that I've generally worked with attempted to minimize the amount of DB requests needed to serve a user's request (e.g. session cached in Redis/Valkey and using DB views to return an optimized data structure that can be returned with minimal transformations).
Either way, that's a quite beefy setup!
Earlier quoted context omitted.
Would love to hear more about what you don't like with model validations (full clean).
Sorry on the slow reply. But yea, I can complain at length. - Model validations aren't run automatically. Need to call full_clean manually. - EXCEPT when you're in a form! Forms have their own clean, which IS run automatically because is_valid() is run. - This also happens to run the model's full_clean. - DRF has its own version of create which is separate and also does not run full_clean. - Validation errors in DRF'…
I think Django seems confused on the issue of clean/validation. On the one hand, it could say the "model" is just a database table and any validation should live in the business logic of your application. This would be a standard way of architecting a system where the persistence layer is in some peripheral part that isn't tied to the business logic. It's also how things like SQLAlchemy ORM are meant to be used. On the other hand, it could try to magically handle the translation of real business objects (with validation) to database tables.
It tries to do both, with bad results IMO. It sucks to use it on the periphery like SQLAlchemy, it's just not designed for that at all. So everyone builds "fat" models that try to be simultaneously business objects plus database tables. This just doesn't work for many reasons. It very quickly falls apart due to the object relational mismatch. I don't know how Rails works, but I can't imagine this ever working right. The only way is to do validation in the business layer of the application. Doing it in the views, like rest framework or form cleans is even worse.