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 <arkkidd...@gmail.com> 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 <arkki...@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+u...@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
> <mailto:modwsgi+unsubscr...@googlegroups.com>.
> 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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/modwsgi/9F26BACE-EF10-4A6B-9133-5A52ABE4D9A3%40gmail.com.
