If you have a single CPU droplet, doesn't that mean you only have 1 CPU and thus there's no point using 3 gunicorn workers because two of them don't have distinct CPUs to use.
And it's true. If you do have, say, 4 CPUs and 4 gunicorn workers, suppose that you fill all your caches, you're going to need to use 4x as much RAM memory compared to letting all be handled by 1 memcache or redis.
I was reading an article on why going over the network/socket is so much slower than doing it natively in Python (https://www.prowesscorp.com/computer-latency-at-a-human-scale/), and was wondering how locMem does it.
I am a newbie,and had just started searching, and almost immediately hit this article. This experiment confirms that the locMem cache is in fact in the process's own memory and not gotten through a socket. The socket, howsoever light it is, will presumably always be outperformed by local access. And then, one has to 'protect' socket 11211 from infiltrators (https://www.digitalocean.com/community/tutorials/how-to-secure-memcached-by-reducing-exposure) - not difficult, but still ...
The locmem cache's disadvantage is that its data is not shared across processes, and is not persistent (your process goes down, the cache gets busted). To me, given how complicated cache busting is, this looks like an advantage. Cache busting becomes as easy as shutting things down, and bringing them up again.
To 'fill' the cache after a shutdown automatically, I thought of two approaches -
1. Run "ab" with N parallel connections for a few seconds with all the target endpoints, where N is larger than the number of workers (in my case gunicorn sockets), forcing each to fill up their caches.
2. Have a special end-point, that just fills up the caches. I implemented the first, being lazy and not wanting to do the extra coding.
So each time I 'goDown' and 'bringUp' my code base, I just do a 'fillUp' using a script which calls ab. I do have dynamic pages, but large parts of each dynamic page is in fact static, so I cache fragments for repeat users, and full pages for first time visitors to each endpoint (those that come without a cookie).
I am worried I am doing it all wrong! Beacuse the other disadvantage of locMem is that each process will use up memory for its own cache. In my case, the caches are not big. If they do get bigger, I will try a shared memory approach, since that would still be much faster than sockets (http://pages.cs.wisc.edu/~adityav/Evaluation_of_Inter_Process_Communication_Mechanisms.pdf).
(This is my first project with Django, and I am using nginx, postgres, gunicorn, python, django, locMem, on a single CPU droplet on DOcean, with 3 gunicorn workers, static/media files being served from that droplet itself rather than AWS).
the 3 gunicorn workers is as per the recommendation from gunicorn documentation (2*num_processors + 1). http://docs.gunicorn.org/en/stable/design.html My cache is small - max 500 items (static fragments of pages) X max 200kb = 100Mb. With 4Gb RAM, I thought I could afford the duplication.
Comment
If you have a single CPU droplet, doesn't that mean you only have 1 CPU and thus there's no point using 3 gunicorn workers because two of them don't have distinct CPUs to use.
And it's true. If you do have, say, 4 CPUs and 4 gunicorn workers, suppose that you fill all your caches, you're going to need to use 4x as much RAM memory compared to letting all be handled by 1 memcache or redis.
Parent comment
I was reading an article on why going over the network/socket is so much slower than doing it natively in Python (https://www.prowesscorp.com/computer-latency-at-a-human-scale/), and was wondering how locMem does it. I am a newbie,and had just started searching, and almost immediately hit this article. This experiment confirms that the locMem cache is in fact in the process's own memory and not gotten through a socket. The socket, howsoever light it is, will presumably always be outperformed by local access. And then, one has to 'protect' socket 11211 from infiltrators (https://www.digitalocean.com/community/tutorials/how-to-secure-memcached-by-reducing-exposure) - not difficult, but still ... The locmem cache's disadvantage is that its data is not shared across processes, and is not persistent (your process goes down, the cache gets busted). To me, given how complicated cache busting is, this looks like an advantage. Cache busting becomes as easy as shutting things down, and bringing them up again. To 'fill' the cache after a shutdown automatically, I thought of two approaches - 1. Run "ab" with N parallel connections for a few seconds with all the target endpoints, where N is larger than the number of workers (in my case gunicorn sockets), forcing each to fill up their caches. 2. Have a special end-point, that just fills up the caches. I implemented the first, being lazy and not wanting to do the extra coding. So each time I 'goDown' and 'bringUp' my code base, I just do a 'fillUp' using a script which calls ab. I do have dynamic pages, but large parts of each dynamic page is in fact static, so I cache fragments for repeat users, and full pages for first time visitors to each endpoint (those that come without a cookie). I am worried I am doing it all wrong! Beacuse the other disadvantage of locMem is that each process will use up memory for its own cache. In my case, the caches are not big. If they do get bigger, I will try a shared memory approach, since that would still be much faster than sockets (http://pages.cs.wisc.edu/~adityav/Evaluation_of_Inter_Process_Communication_Mechanisms.pdf). (This is my first project with Django, and I am using nginx, postgres, gunicorn, python, django, locMem, on a single CPU droplet on DOcean, with 3 gunicorn workers, static/media files being served from that droplet itself rather than AWS).
Replies
the 3 gunicorn workers is as per the recommendation from gunicorn documentation (2*num_processors + 1).
http://docs.gunicorn.org/en/stable/design.html
My cache is small - max 500 items (static fragments of pages) X max 200kb = 100Mb. With 4Gb RAM, I thought I could afford the duplication.