Content
View differences
Updated by Henriette Darge over 6 years ago
It is well known that access to services through Unix sockets is way faster than TCP/IP sockets. Example benchmarks such as Postgres \[1\] and \[2\] and Redis \[3\] pop all the time.
So it’s expected that people would use them more than host:port accesses, specially on containers which grow ever more popular with a handful of services all in one place communicating between each other locally.
However, I tried to point openproject to a memcached server I already have setup perfectly for other uses and failed because of some artificial limitation imposed on cache\_memcache\_server. It seems that that variable is being forcibly split into host:port.
I’d really like if that variable (config/env/whatever) would be more flexible in a way which I could point to a unix socket as well. For instance, many configurations in the wild would accept some general URI such as ‘unix:///run/memcached/memcached.socket’.
As an example of a success story, consider that I can, even with openproject, point it to use a postgres server through unix socket just fine using this environment variable \[4\]: DATABASE\_URL: ‘postgresql:///openproject?user=openproject’. Since I’m using the docker container version of your distribution, I also have to bind /run/postgresql from wherever the actual server is running, which can be the host or even another container, but there’s nothing more to it and I get a much faster access to the external service.
This report has been provoked by a limitation discovered on the container accessible through https://hub.docker.com/r/openproject/community/. However, it seems like this limitation is not particular of the container, but it’s more general belonging to openproject itself, so I believed this was the proper place to propose this.
1. http://momjian.us/main/blogs/pgblog/2012.html\#June\_6\_2012
2. http://www.cybertec.at/2016/05/postgresql-performance-advise-unix-sockets-vs-localhost/
3. https://redis.io/topics/benchmarks
4. https://www.postgresql.org/docs/current/static/libpq-connect.html\#LIBPQ-CONNSTRING
Thanks for considering this.
So it’s expected that people would use them more than host:port accesses, specially on containers which grow ever more popular with a handful of services all in one place communicating between each other locally.
However, I tried to point openproject to a memcached server I already have setup perfectly for other uses and failed because of some artificial limitation imposed on cache\_memcache\_server. It seems that that variable is being forcibly split into host:port.
I’d really like if that variable (config/env/whatever) would be more flexible in a way which I could point to a unix socket as well. For instance, many configurations in the wild would accept some general URI such as ‘unix:///run/memcached/memcached.socket’.
As an example of a success story, consider that I can, even with openproject, point it to use a postgres server through unix socket just fine using this environment variable \[4\]: DATABASE\_URL: ‘postgresql:///openproject?user=openproject’. Since I’m using the docker container version of your distribution, I also have to bind /run/postgresql from wherever the actual server is running, which can be the host or even another container, but there’s nothing more to it and I get a much faster access to the external service.
This report has been provoked by a limitation discovered on the container accessible through https://hub.docker.com/r/openproject/community/. However, it seems like this limitation is not particular of the container, but it’s more general belonging to openproject itself, so I believed this was the proper place to propose this.
1. http://momjian.us/main/blogs/pgblog/2012.html\#June\_6\_2012
2. http://www.cybertec.at/2016/05/postgresql-performance-advise-unix-sockets-vs-localhost/
3. https://redis.io/topics/benchmarks
4. https://www.postgresql.org/docs/current/static/libpq-connect.html\#LIBPQ-CONNSTRING
Thanks for considering this.