When i have 260 microservices those all are light weight applications using same python interpreter and with django rest api framework, and currently each application hosted on apache server usign mod_wsgi daemon mode and my main problem is while making changes to one of application virtualhost other ongoing daemons are distured as i need to reload or restart. All those 260 services very light weight each listen to http request on unique ports.
ThankYou RajKumar On Tuesday 23 July 2024 at 16:37:42 UTC+5:30 Graham Dumpleton wrote: > One can optimise embedded mode for better performance, but I would put a > big caveat on that and say is only probably a good idea to tackle if you > have the one web service. > > Running 260 micro services in one Apache httpd instance with mod_wsgi > sounds rather scary either way. > > If you use mod_wsgi daemon mode where each micro service is in its own > daemon process group (with a single process and small number of threads), > then you might get away with it if these aren't high volume sites. That > said, it is still a lot of managed daemon mode processes and not sure how > well Apache will handle that, especially on restarts. > > Running them all in embedded mode would be a bad idea if each needs a > separate Python interpreter context because the Apache worker process would > be huge in size. If Apache httpd was configured for prefork MPM it would be > even worse because you would have a potentially large number of worker > processes since all are single thread. You also run a big risk with micro > services interfering with each other in strange ways if running in > different sub interpreter contexts of the one process due to how Python > imports C extensions, and process wide environment variables work. Various > third party Python packages with C extensions will not even work in Python > sub interpreters (eg., anything related to numpy). > > You definitely want event or worker MPM, but even then, for 260 micro > services, if they need separate Python interpreter context I can't really > recommend it still because of size concerns for processes and potential > cross sub interpreter interference. > > So the question is whether when you said 260 micro services you really > mean independent web applications, or whether you just mean you have 260 > different unique HTTP handlers as part of the one application, and thus in > the same Python interpreter context. > > When people talk about such large number of micro services, usually you > would not be aiming to host them in a single Apache instance but would > instead be looking at running something which can handle things at scale > like Kubernetes and creating separate deployments for them in that, relying > on the ingress routing Kubernetes provides to get traffic to the > appropriate micro service. > > Graham > > On 23 Jul 2024, at 7:13 PM, RajKumar Ambadipelli <[email protected]> > wrote: > > mod_wsgi in embeded mode allows graceful restart, > What are the potential issues that I will face if I use mod_wsgi in > embedded mode instead of daemon mode, > I have to host around 260 python micro services. > > I have saw your blog on 'why are you using mod_wsgi in embedded mode?' > But, I unable to understand it very well in that you mentioned if we > configure mpm settings correctly then mod_wsgi in embedded mode is better > than daemon mode but not mentioned any configurations. > > Thanking you, > RajKumar > > On Tuesday 23 July 2024 at 13:04:50 UTC+5:30 Graham Dumpleton wrote: > >> On 23 Jul 2024, at 4:09 PM, RajKumar Ambadipelli <[email protected]> >> wrote: >> >> I am using Apache Server with mod_wsgi for hosting my python django >> applications. Versions: Python 3.9.18 Server version: Apache/2.4.57 >> mod-wsgi==4.7.1 >> >> One of my application virtual host configuration with two different >> versions: >> >> ... >> >> So, When the source code is modified I can referesh the wsgi daemon using >> touch /home/uoadmin/releases/1.1.0/students/conf/wsgi.py touch >> /home/uoadmin/releases/1.0.0/students/conf/wsgi.py But when I added new >> virtualhost to the above configuration file or else when I modify above >> file the apache server unable to recognize modifications made the existing >> virtualhost or newly added virtualhost until doing apachectl graceful (or) >> apachectl restart (or) systemctl reload httpd but all the commands above >> killing the ongoing requests forcefully directly terminating them. >> >> How to handle above situation. >> >> I want to know how will apache server recognize modifications to >> virtualhost or newly added virtual host without reloading or restarting. >> >> It can't, Apache httpd requires you to perform a restart (reload) in >> order to read changes to the Apache configuration files. That is how it >> works. >> >> If above is not possible then is there anyway for restarting or reloading >> apache server gracefully that is without terminating or killing other >> ongoing requests or daemons while using apache server + mod_wsgi for >> serving python with django? >> >> Unfortunately not. The way Apache httpd manages the mod_wsgi daemon >> processes it will force a restart of those as well and even though Apache >> has a concept of graceful restart for it's own worker child processes, it >> doesn't extend that to managed process like the mod_wsgi daemon process and >> always restarts them immediately even when it is a graceful restart. There >> is nothing that can be done about this. >> >> The only way you could handle it if you need to be able to freely restart >> the main Apache server and have it not affect your Python web applications, >> is to run the Python web applications in distinct secondary web server >> processes and use the main Apache server to only proxy requests through to >> the secondary web servers. >> >> For the second web servers you could use mod_wsgi-express to make things >> easier, but you could also just not use mod_wsgi for the secondary web >> servers and use gunicorn or some other standalone Python WSGI/asyncio web >> server. >> >> Graham >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/d28663bc-a143-4e4f-949d-38e065c5ac9fn%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/d28663bc-a143-4e4f-949d-38e065c5ac9fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/1fffb2f7-ed8a-4d88-a52b-00e7e82e98d5n%40googlegroups.com.
