Ok, If I have only two virtualhosts all the time and I am going to change only python-path will that work with the direct signal using SIGUSR1.
If the above is possible then I think I have some kind of solution. Thankyou, RajKumar On Thursday 25 July 2024 at 12:35:09 UTC+5:30 Graham Dumpleton wrote: > Are you always using the same two virtual host server names and just > updating the version number in the paths? > > On 25 Jul 2024, at 4:21 PM, RajKumar Ambadipelli <[email protected]> > wrote: > > Yes I am adding new virtual hosts when ever I want to release a new > version of that services lets say initially my virtualhost config will be > like > > #Students Webservice Config > Listen 9002 <VirtualHost *:9002> > ServerName test.myapp.com > ErrorLog /var/log/webservice_error.log > WSGIPassAuthorization On > WSGIDaemonProcess Tes9002 python-path=/home/uoadmin/releases/1.0.0 > /students:/home/admin/releases/1.0.0/shared display-name=%{GROUP} > WSGIProcessGroup Tes9002 WSGIApplicationGroup %{GLOBAL} > WSGIScriptAlias / /home/admin/releases/1.0.0/students/conf/wsgi.py > <Directory /home/admin/releases/1.0.0/students/conf> > <Files wsgi.py> Require all granted </Files> > </Directory> > </VirtualHost> > > When i want to go for new releases the down part is appended to above part > > <VirtualHost *:9002> > ServerName dev.myapp.com > ErrorLog /var/log/webservice_error.log > WSGIPassAuthorization On > WSGIDaemonProcess Dev9002 python- path=/home/uoadmin/releases/1.1.0 > /students:/home/admin/releases/1.1.0/shared display-name=%{GROUP} > WSGIProcessGroup Dev9002 WSGIApplicationGroup %{GLOBAL} > WSGIScriptAlias / /home/admin/releases/1.1.0/students/conf/wsgi.py > <Directory /home/admin/releases/1.1.0/students/conf> > <Files wsgi.py> Require all granted </Files> > </Directory> > </VirtualHost> > > > Now I am going to have two virtualhosts with two daemons 1st is already > recognized by apache server where as second one is not yet recognized by > apache server > > Thankyou, > RajKumar > > On Thursday 25 July 2024 at 11:40:31 UTC+5:30 Graham Dumpleton wrote: > >> 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 <[email protected]> >> 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 <[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 >> >> <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 [email protected]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/27697b57-c903-4881-bddd-691060d62b47n%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/27697b57-c903-4881-bddd-691060d62b47n%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/0794a799-7f70-4d68-affe-b2b7a4f43529n%40googlegroups.com.
