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>
>>> 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/modwsgi/27697b57-c903-4881-bddd-691060d62b47n%40googlegroups.com.
