Any way to limit number of users who are logged in

@tykus How would you go about finding a bottleneck like that?

@ctyler Try Laravel DebugBar - barryvdh/laravel-debugbar

@Beybol Thanks for the tip. I am using DebugBar. Something else is going on. I am just not seeing any queries that are taking up a lot of memory. They just are not that complex.

@ctyler Inspect other elements than queries using debug bar - maybe there is something wrong with other elements (ex. views). If you find some slow requests you can try to limit them using Rate Limiting Middleware in your routing setup: https://laravel.com/docs/9.x/routing#rate-limiting

@Beybol that is a great idea. I have actually been thinking about this a lot. Even beyond my current issue.

So should rate limiting be set up on all laravel applications to prevent crashing. At least a top limit however high. A website, whether Laravel or not, cannot handle unlimited traffic.

@Beybol The more more I look at the rate limiting the more I like that idea.

To explain the issue in more detail. This is an LMS for classes that occur in real time. In order for users to get there certificate users must login, take the survey and the they can click on a link to receive their certificate that is generated on the server. I really dont think the certificates are the issue because I have those being queued and only 2-3 are being generated at any given time.

So, as part of getting the certificate, you have to enter a code that is given at the end of class(To make sure people stayed till the end). Now we are creating a situation were the class ends at 3:45. At 3:46 you have 1000 people logging in at nearly the exact same time entering the code, taking the survey, and getting there certificate. That's a lot. So, its not just general 1000 user traffic.

When the owner tells people that the certificates will not be available until the next day, it is not an issue at all. However, I don't like that stipulation. I like the idea of the rate limiting that simply tells people, system is busy try again latter or something similar. Also, the owner really does not want to pay for a beefier server for these classes that only happen a few times a year and I don't really blame her.

@sinnbeck Its more near 1000's. I was just using 100 as an example limit. If all of these people try to log in and do the same thing all at the exact same time, I could see that happening. This is kind of a strange situation. Me personal, i would rather get a beefier VM but unfortunately that is not an option.

I could try generating the PDFs at night but I really don't think that would be the issues. Especially since there are only 3 workers running at a time so only 3 PDFs would be generated and email at any one time.

@ctyler If you save their responses to a queued job, you can finish serving the user quickly and then run the queue in the background for however long it needs to take.

But sounds like there is oportunity for optimisation. I would first look at the database indexes. Maybe you are checking if the student performed the survey before using their id, and the class or the date. Examine the queries and check that you have appropriate indexes

@Snapey Those are all good suggestions. I think I will start there.

@Snapey Out of curiosity, how many active users should a normal app support at the same time using it?

I always thought e.g. 25k records in DB was a lot, but I got told that's nothing.

So if you have some cheap Digital Ocean server for 5$ and the app is well optimized, how many users would you expect it can handle before upgrading the server? Or is there some CPU/GB e..g 0.001GB = one user? or something?

@aurelianspodarec its not that straightforward.

You can have thousands of users logged in but not making any requests, so not loading your server at all.

Suppose your server could only serve one request at once. If that took 100ms to return the response, then a second user accessing the server at the same time would wait 100ms, and a third at the same time 200ms. Then if a third request came in 100ms later and a 4th 100ms after than then suddenly work starts to queue.

Now suppose your code is so poor, or your database queries so complex that each request now takes 1 second and not 100ms. Seems obvious but you have now gone from 10 requests per second to 1 request per second.

Now, instead of users waiting 100,200,300ms they are now waiting 2,3,4 seconds. Not only are they now seeing longer wait times, but the chances of more users making requests at the same time has gone up significantly.

Fortunately, web servers don't only serve one request at a time, and with more memory and more threads they can serve more and more concurrent requests.

But there is no hard and fast rule because it involves too many factors.

@Snapey Wow. That made me put things into perspective. Thanks for the reply.

That's very interesting. Poorly optimized code is almost as if the app isn't built at all because it won't work if it has a lot of users - I guess this shows how important it is to optimize the app and its something one needs to learn ASAP. I did look into optimization though now I'm focusing on making things work a bit more, but wow. This made me realise in reality you can't deploy a non-optimized app - I guess depends on the context too. Maybe if one has no users its fine but then you'd need to do it eventually.

Where did you learn all of this btw? Is this the knowledge I'll also gather the more back-end I do? I'm personally building an app based on what Iv'e learned from laravel from scratch by adding my features etc... maybe if I were to deploy this, have some challenges like this guy, id google more about it and get to know how the server bits etc... works also better I suppose.