What is the reason for doing the graceful restart? Is it because you are adding/removing virtual hosts, or making some other Apache config change.
You do not need to do a complete Apache restart if just want to force a daemon process to restart, you can instead send the processes a signal directly. From memory it is SIGUSR1 that triggers a graceful restart of processes, but you will need to confirm that. > On 25 Jul 2024, at 3:28 PM, RajKumar Ambadipelli <arkkidd...@gmail.com> wrote: > > 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 <arkki...@gmail.com <>> >>> 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 <arkki...@ <>gmail.com >>>>> <http://gmail.com/>> 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 modwsgi+u...@googlegroups.com <>. >>> 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 modwsgi+unsubscr...@googlegroups.com > <mailto:modwsgi+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/1fffb2f7-ed8a-4d88-a52b-00e7e82e98d5n%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/1fffb2f7-ed8a-4d88-a52b-00e7e82e98d5n%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 modwsgi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/FB85A549-69E4-4CE7-891B-DD466A0156C2%40gmail.com.
