>> >> Hi, which is the "noise" you are reporting ? >> >> Maybe it can help addressing the issue (i bet it is the I/O generated by >> noise slowing down things) >> > > > The noise is in the response time of the application call (logged via a > timer within the python app). While we may have problems with the I/O, I > did also just run a test in which I modified the uwsgi app from: > processes = 2 > threads = 10 > > to > processes = 20 > threads = 1 > > and am seeing a much less noisy response time profile (and with a latency > closer to that of running with two processes and one thread). Can I infer > from this that the problem lies somewhere within running python threads > (either on the uwsgi end, sqlalchemy end or something else I haven't > thought of) rather than with my database? > >
Starting from 1.0, the threading model of uWSGI maps 1:1 with the mod_wsgi one. If you see worst performance (or bad behaviour) in uWSGI with the same mod_wsgi threading setup, it is a uWSGI problem for sure. Your config and assumptions about threads are all right. My only doubt, is in nginx vs apache behaviour. From what you have wrote it looks like you have configured mod_wsgi in daemon mode, so at the lowest level this is a proxy-like solution. nginx can generate a vastly higher number of concurrent connections than apache, and this could lead to all of the uWSGI threads waking up concurrently (meaning lot of lock-contention and memory usage). How you are benchmarking the setup ? What is the MaxClients setup in your apache config ? Can you check system memory usage during the benchmarks ? -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
