Re: [openresty-en] Serving static JS files using Openresty

agentzh · 2013-02-06T03:42:37+00:00

Hello! On Thu, Feb 14, 2013 at 5:12 AM, Sam Lee wrote: > Actually, I ended up using ngx.location.capture('/proxyslowapp') > Yes, this should work tho...

Re: [openresty-en] Serving static JS files using Openresty

agentzh

Hello!

On Tue, Feb 5, 2013 at 12:13 AM,  <ankit...@gmail.com> wrote:
> I am trying to setup a server where in I have to serve static JS files
> (total of 4 files ~ 7-30KB in size). I am currently using SRCache to do it,
> but I am not happy with the memcached required with it to store the content
> as memcached is showing Connection Timeouts when the no. of connections
> increases. The config I currently have is as following:
>
>
>> upstream memcached_backend {
>>         server                      unix:/tmp/memcached.sock;
>>         keepalive                   32;
>>     }
>

What's the number of concurrent requests that your Nginx is handling?
You may want to increase the keepalive connection pool size (32).

Also, what's the CPU usage of the memcached process under load? Is it
really high? You may want to enable the multi-thread support in your
memcached server too. And/or just enable multiple memcached instances
and do a shard in your location = /memc via something like
set_hashed_upstream (from the ngx_set_misc module).

Also, you may get better results when just putting your static .js
file on a tmpfs partition instead of using any server-side caches. The
ngx_srcache module is best for dynamic response caching.

Best regards,
-agentzh

ankitjain53

Thanks agentzh for the info.

I checked and I saw that the memcache CPU usage is almost 0 and the concurrent connections is around 20. This server though has another file being served (which is being done by lua-resty) and that has around 1k requests/sec which can also connect the memcached (if lookup fails in nginx-dict) but uses the lua-resty-memcached module to connect to the memcached.

For memcached we are using the default no. of threads which is 4. Will try and increase that to match the no. of cores.

As per the tmpfs as it would be volatile, need to see how we can have it updated after each restart. Thanks again for all the info.

On Wednesday, 6 February 2013 01:12:37 UTC+5:30, agentzh wrote:

Hello!

On Tue, Feb 5, 2013 at 12:13 AM, <ankit...@gmail.com> wrote:
> I am trying to setup a server where in I have to serve static JS files
> (total of 4 files ~ 7-30KB in size). I am currently using SRCache to do it,
> but I am not happy with the memcached required with it to store the content
> as memcached is showing Connection Timeouts when the no. of connections
> increases. The config I currently have is as following:
>
>
>> upstream memcached_backend {
>> server unix:/tmp/memcached.sock;
>> keepalive 32;
>> }
>

What's the number of concurrent requests that your Nginx is handling?
You may want to increase the keepalive connection pool size (32).

Also, what's the CPU usage of the memcached process under load? Is it
really high? You may want to enable the multi-thread support in your
memcached server too. And/or just enable multiple memcached instances
and do a shard in your location = /memc via something like
set_hashed_upstream (from the ngx_set_misc module).

Also, you may get better results when just putting your static .js
file on a tmpfs partition instead of using any server-side caches. The
ngx_srcache module is best for dynamic response caching.

Best regards,
-agentzh

agentzh

Hello!

On Tue, Feb 5, 2013 at 1:58 PM, Ankit Jain wrote:
> I checked and I saw that the memcache CPU usage is almost 0 and the
> concurrent connections is around 20. This server though has another file
> being served (which is being done by lua-resty) and that has around 1k
> requests/sec which can also connect the memcached (if lookup fails in
> nginx-dict) but uses the lua-resty-memcached module to connect to the
> memcached.
>

Interesting. Does increasing the memc_read_timeout setting reduce the
number of timeout errors?

If memcached is not eating much CPU time at all, then there's no merit
in enabling multi-thread support in memcached.

Do all the error messages have the substring "while reading response
header from upstream"? Or are there any other variants? Like "while
doing something else"?

Best regards,
-agentzh

ankitjain53

Hello agentzh,

The memc_read_timeout setting does change the no. of errors, but the errors are not constant but are intermittent. So they still happen. Also I would not like to increase the timer because of the memcached connection fails in 100ms, the page would be served normally (instead of the SRCache) which will reduce the delay, otherwise it would keep on trying for memcached.

As per the errors, there are no other errors related to memcached in the logs.

Thanks,
Ankit

On Wednesday, 6 February 2013 04:49:16 UTC+5:30, agentzh wrote:

Hello!

On Tue, Feb 5, 2013 at 1:58 PM, Ankit Jain wrote:
> I checked and I saw that the memcache CPU usage is almost 0 and the
> concurrent connections is around 20. This server though has another file
> being served (which is being done by lua-resty) and that has around 1k
> requests/sec which can also connect the memcached (if lookup fails in
> nginx-dict) but uses the lua-resty-memcached module to connect to the
> memcached.
>

Interesting. Does increasing the memc_read_timeout setting reduce the
number of timeout errors?

If memcached is not eating much CPU time at all, then there's no merit
in enabling multi-thread support in memcached.

Do all the error messages have the substring "while reading response
header from upstream"? Or are there any other variants? Like "while
doing something else"?

Best regards,
-agentzh

agentzh

Hello!

On Wed, Feb 6, 2013 at 12:53 AM, Ankit Jain <ankit...@gmail.com> wrote:
> The memc_read_timeout setting does change the no. of errors, but the errors
> are not constant but are intermittent. So they still happen. Also I would
> not like to increase the timer because of the memcached connection fails in
> 100ms, the page would be served normally (instead of the SRCache) which will
> reduce the delay, otherwise it would keep on trying for memcached.
>

Thank you for the information.

What versions of memcached and libevent are you using? If you're not
using the latest versions, you may want to consider upgrading them :)

Also, you can try using ngx_lua + lua-resty-memcached in your location
= /memc to handle the srcache_fetch and srcache_store subrequests and
see if there's any change.

Best regards,
-agentzh

ankitjain53

Hi agentzh,

The versions are: memcached 1.4.5 and libevent 1.4.2. We are using Debian 6 default packages.

I would try the /tmpfs thing as it does look to fit well in our case. Will surely let you know how things go.

Thanks,
Ankit Jain

On Thursday, 7 February 2013 at 12:57 AM, agentzh wrote:

Hello!

On Wed, Feb 6, 2013 at 12:53 AM, Ankit Jain <ankit...@gmail.com> wrote:
The memc_read_timeout setting does change the no. of errors, but the errors
are not constant but are intermittent. So they still happen. Also I would
not like to increase the timer because of the memcached connection fails in
100ms, the page would be served normally (instead of the SRCache) which will
reduce the delay, otherwise it would keep on trying for memcached.

Thank you for the information.

What versions of memcached and libevent are you using? If you're not
using the latest versions, you may want to consider upgrading them :)

Also, you can try using ngx_lua + lua-resty-memcached in your location
= /memc to handle the srcache_fetch and srcache_store subrequests and
see if there's any change.

Best regards,
-agentzh

--
.