Yeah I've primarily been developing for myself/not with a lot of users in mind/concurrency so I have yet to figure that out. I mean I have built say templating "engines" that produce pages for different people using the same db but I couldn't say update a database (like importing) and keep the live one active/not be affected as I only have one instance running.
I have yet to use nginx/only using apache at this time but have heard/looked into it.
Thanks for the tip on RabbitMQ, is this different from using say CRON (for scheduled tasks) or are you talking just processing the large amount of real-time requests, which at this time for me is just first-come-first-serve as far I'm aware.
I suppose it depends on what you application does. I have not used web sockets yet personally but have some experience with them, currently figuring out how to use web workers. Yeah lots to learn still.
No reason to bring up web sockets but some applications may have real time updates or push notifications.
edit: I want to get to the point where I have backend statuses telling me how much applications are running (resources) that would be cool and then hitting thresholds do something.
> Thanks for the tip on RabbitMQ, is this different from using say CRON (for scheduled tasks) or are you talking just processing the large amount of real-time requests, which at this time for me is just first-come-first-serve as far I'm aware.
oh, I never realized that they're both task schedulers with different meanings (I'm not native...^^)
cron is meant to fire off a command at a specific interval or date. RabbitMQ creates a schedule of what should be done in what order.
You generally only use cron for tasks outside of your application context, however. (i.e. creating backups, flushing old temporary files, maybe fetching updated files/data from a third party)
RabbitMQs use-case is much closer to your application: say one of your users wants to export some data. Your frontend application would just add this task to the task schedule and your next worker/cluster node would start processing it as soon as it has resources available.
this decouples the actual web application from what's being done on the server and lets you scale indefinitely, depending on how far you go on that front.
it, however, creates a lot of administrative overhead and is IMO not necessary until your project is already quite large. It might also be possible to scale in another way - it depends entirely on the application you're building.
a shared calendar, for example, wouldn't need this, because there are almost no resource heavy tasks that have to be done.
I have yet to use nginx/only using apache at this time but have heard/looked into it.
Thanks for the tip on RabbitMQ, is this different from using say CRON (for scheduled tasks) or are you talking just processing the large amount of real-time requests, which at this time for me is just first-come-first-serve as far I'm aware.
I suppose it depends on what you application does. I have not used web sockets yet personally but have some experience with them, currently figuring out how to use web workers. Yeah lots to learn still.
No reason to bring up web sockets but some applications may have real time updates or push notifications.
edit: I want to get to the point where I have backend statuses telling me how much applications are running (resources) that would be cool and then hitting thresholds do something.
Anyway thanks