My load test is pretty mellow, I thought... Originally was doing: ab -c 15 -n 500 -s 10 https://mysite.com/
And this caused response times of ~8 sec Trying again with: ab -c 5 -n 500 -s 10 https://mysite.com/ still leads to ~3 sec response time. My hope was for this to be able to handle ~100 concurrent users, but I hadn't really thought about it in terms of requests/second... I'm primarily worried about the base url handler, as the base url triggers a large get payload from an external API. Other url's have much faster response time. I am just starting to get familiar with MPM's, and I'm still not entirely sure which MPM this server uses. Because of this output: $ sudo ls /etc/apache2/mods-enabled/ access_compat.load authn_file.load authz_user.load dir.conf mime.conf *mpm_event.load* proxy.conf rewrite.load socache_shmcb.load wsgi.conf auth_basic.load authz_core.load deflate.conf dir.load mime.load negotiation.conf proxy.load setenvif.conf ssl.conf wsgi.load authn_core.load authz_host.load deflate.load filter.load mpm_event.conf negotiation.load proxy_http.load setenvif.load ssl.load I believe I am using worker MPM. I was also confused by the blank "Server MPM:" line in this output: $ apache2 -V [Thu Sep 17 17:16:46.880034 2020] [core:warn] [pid 26387] AH00111: Config variable ${APACHE_RUN_DIR} is not defined apache2: Syntax error on line 80 of /etc/apache2/apache2.conf: DefaultRuntimeDir must be a valid directory, absolute or relative to ServerRoot Server version: Apache/2.4.29 (Ubuntu) Server built: 2020-08-12T21:33:25 Server's Module Magic Number: 20120211:68 Server loaded: APR 1.6.3, APR-UTIL 1.6.1 Compiled using: APR 1.6.3, APR-UTIL 1.6.1 Architecture: 64-bit Server MPM: Server compiled with.... -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=256 -D HTTPD_ROOT="/etc/apache2" -D SUEXEC_BIN="/usr/lib/apache2/suexec" -D DEFAULT_PIDLOG="/var/run/apache2.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="mime.types" -D SERVER_CONFIG_FILE="apache2.conf" I did not have WSGIRestrictEmbedded On, but tried adding it-- no effect. I do not have any performance monitoring or backend metrics. I've been going purely off of htop (and other similar tools) and CloudWatch. I also tried https://django-debug-toolbar.readthedocs.io/en/latest/ locally but it wasn't very insightful to my issue. On Thursday, September 17, 2020 at 2:06:08 AM UTC-4 Graham Dumpleton wrote: > When you say "load test", do you mean totally overload the server way > beyond the realistic amount of traffic you would ever expect to get? :-) > > In other words, are you running tests like: > > ab -c 15 -n 1000000000 http://mysite > > or: > > siege -c 15 -t 120s http://mysite > > which is just throwing as many requests as absolutely possible at Apache? > > This is only going to likely cause Apache to choke up as you are putting > it into an overload state, made worse by number of server processes. It is > the wrong way of evaluating how much load your server can realistically > take. > > What is the real number of requests/sec you would expect to ever receive? > > Does every URL handler take 1 second to response, or are response times > across the site varied? > > What are the Apache MPM settings you have set? Since using prefork MPM, > what do you have set for: > > <IfModule mpm_prefork_module> > StartServers 1 > MinSpareServers 1 > MaxSpareServers 10 > MaxRequestWorkers 250 > MaxConnectionsPerChild 0 > </IfModule> > > Do you have: > > WSGIRestrictEmbedded On > > set in Apache configuration (outside of VirtualHost)? > > And finally, do you have any performance monitoring in use, or at least > have a backend metrics database/service where could report metrics? > > Graham > > On 17 Sep 2020, at 3:21 pm, Scott McConnell <scott.mc...@gmail.com> wrote: > > Hello, I am using apache/mod_wsgi to serve a processor/ajax heavy Django > application on an Ubuntu 16.04 machine. The app is working with low traffic > on https (~1 sec response time), but I'm running into a bottleneck during > load testing. > > During a load test (15 concurrent requestors) response time becomes ~6 > sec, but CPU utilization peaks at 30% according to CloudWatch. I am using > an EC2 instance and I've been continually increasing the size with no > effect (now using c5.xlarge). > > The strange part is my htop output... one process is taking the majority > of the CPU time, whereas the wsgi daemon processes don't seem to take on > any tasks. This culprit process starts after I restart the server and never > dies until the server is stopped. > > This was the output when I tried tracing the process: > > $ sudo strace -p 14645 > > strace: Process 14645 attached > > restart_syscall(<... resuming interrupted restart_syscall ...> > > Below are some htop screenshots, and I pasted my config at the bottom. > > When sorted by CPU utilization: > > <Screen Shot 2020-09-17 at 12.37.42 AM.png> > > then all the way at the bottom are my daemon processes named wsws: > > <Screen Shot 2020-09-17 at 12.35.47 AM.png> > > Here is my mysite.com.conf: > > <VirtualHost *:80> > > ServerAdmin webmaster@localhost > ServerName mysite.com > ServerAlias www.mysite.com > DocumentRoot /var/www/html > ErrorLog ${APACHE_LOG_DIR}/error.log > CustomLog ${APACHE_LOG_DIR}/access.log combined > LogLevel info > > <Directory /home/ubuntu/myrepo/mysite/static> > Require all granted > </Directory> > > <Directory /home/ubuntu/myrepo/mysite/mysite> > <Files wsgi.py> > Require all granted > </Files> > </Directory> > > > WSGIDaemonProcess mysite python-path=/home/ubuntu/myrepo/mysite > python-home=/home/ubuntu/myrepo/venv processes=25 threads=1 > display-name=wsws request-timeout=60 inactivity-timeout=600 > WSGIProcessGroup mysite > WSGIScriptAlias / /home/ubuntu/myrepo/mysite/mysite/wsgi.py > WSGIApplicationGroup %{GLOBAL} > > RewriteEngine on > RewriteCond %{SERVER_NAME} =www.mysite.com [OR] > RewriteCond %{SERVER_NAME} =mysite.com > RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} > [END,NE,R=permanent] > > </VirtualHost> > > > -- > 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/3622efe1-62d3-4d07-99c9-74fac83541aen%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/3622efe1-62d3-4d07-99c9-74fac83541aen%40googlegroups.com?utm_medium=email&utm_source=footer> > . > <Screen Shot 2020-09-17 at 12.35.47 AM.png><Screen Shot 2020-09-17 at > 12.37.42 AM.png> > > > -- 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/fdd3403c-ff19-42ee-b619-864b0341db7bn%40googlegroups.com.
