Max image cache size parameter

[Anonymous]

Hello,
The default value in IIPImage for Max image cache size parameter is 10 MB. Is this a global limit - meaning IIPImage will never take more than 10MB in RAM in a specific machine?

We have a machine that has few GBs of RAM. Can performances be accelerated if we increase the max cache size parameter? Can you recommend on how much should be allocated?

Thanks!
Eyal

[Ruven]

Yes, it's a limit on the amount of RAM it will use for the storage of raw tile data. It's per instance of iipsrv rather than a global limit. If you have more RAM available, you can increase this value. How high you set this will of course depend on the total RAM you have available. Try setting it to 10% of your total RAM, for example, if you have a lot.

You can also consider using Memcached as a secondary cache. The internal cache stores uncompressed image data, whereas Memcached will store rendered output tiles, so the two are complementary and can work well together.

[Anonymous]

Great info, thank you!

[Anonymous]

Do you recommend using Memcached on the same server with IIPImage?
We have 2 servers with IIPImage installed, so we though of using a third server for Memcached, and configure the 2 IIPImage servers to connect to the same Memcached server. Or should we just install Memcached locally on the same hosts where IIPImage is installed?

[Ruven]

If you have plenty of unused RAM on the host machines, then yes, this could be a good option. Of course, if there's a free 3rd machine, it won't do any harm to add this in addition and create a cluster of Memcached instances.

When using multiple Memcached instances in this way, make sure you point each iipsrv process to all of them by setting the MEMCACHED_SERVERS iipsrv variable appropriately. In this way, the memcached cluster is used efficiently.

[Anonymous]

Hi,
Regarding the MEMCACHED_SERVERS definition, does the order of addresses in this parameter matters? will IIPImage first address the first, and only if it didn't exist will address the second? or it addresses everything at once?
The question is related to having both a local Memcahed on each of the IIPImage machines, and a central Memcached (that serves all the IIPImage machines).

Thanks!
Eyal

[Ruven]

This is managed by libmemcached rather than by iipsrv directly. From the documentation, it does look like libmemcached will sequentially address each available host in the list until it finds the cached object. It would make sense, therefore, to have the central Memcached server first in your the list for both iipsrv servers.

[Anonymous]

Thanks a lot for this info, now we (and everyone else whom reads your answers) know how to properly configure IIPImage with Memcached.

I have to say, from my experience, that using Memcached is a must for good performances, so I recommend everyone whom reads it to use Memcached in any installation of IIPImage.

-Eyal

[Anonymous]

Hi Ruven,
You mentioned about memcached documentation in the reply above. Could you point me to the links that gives more information about memcached architecture in general and APIs in particular. I don't mind reading books available if any.
Thanks,
Suhas

[Ruven]

For information on Memcached itself, you can find everything you need on their homepage: https://memcached.org/

iipsrv itself uses the libmemcached library to interface with Memcached: http://libmemcached.org/

[sp2907]

Thanks Ruven for a quick reply.
My observation may not be correct as I am new to this source code. Noticed that Memcached is used to cache the fetched tile data based on status of 'HTTP_IF_MODIFIED_SINCE'. Are there any other places where its used?
Wondering if there is a scope to use it for prefetching the tiles that could be used for constructing the requested region. (in TileManager class).

-Suhas

[Ruven]

You're right, it's used only if the server gets a HTTP_IF_MODIFIED_SINCE request. I guessyou could do some form of prefetching, but getting data through Memcached is very fast, so prefetching in the TileManager class is arguably not necessary.

[sp2907]

Many thanks for your inputs...
Just to clarify, one or more tiles could be used for constructing the requested region. If these tiles are prefetched, it might help with performance. I noticed that TileManager does have a class member tileCache aimed at maintaining array of fetched tiles in memory. But after debugging through the code, noticed that program returns (TileManager.cc line number 220) before populating tileCache. So next time when there is a request for region the raw tile is again fetched using TileManager::getNewTile() as tileCache is empty. Not sure if I'm missing something. If you could help me understand that will be great.
Also going back to earlier point, I was wondering if using memcached in place of tileCache would help.

-Suhas

[Ruven]

At line 220 there is a return after a call to the getNewTile() function and it is within this function that the tileCache is populated. So, new tiles are always added to the cache.

The Memcached code operates at a higher level and is triggered before any tile request is made. If a tile exists in Memcached, this will be obtained directly within Main.cc without any call made to the TileManager class.

[sp2907]

I missed that part of code in getNewTile() where cache is populated. Thanks for explaining and my apologies for coming up with too many questions. I hope this is last one :-)
In one of the reply above, you mentioned about considering memcached as a secondary cache. Am I correct in assuming that its equivalent to using memcached at TileManager level?

Thanks,
Suhas

[Ruven]

It's a good idea to use Memcached as a secondary cache. As I mentioned earlier, this is complementary to the Tilemanager level cache, but it's not operating at the same level. The internal cache stores raw pixel data, whereas memcached stores rendered output data after processing and compression etc.

[sp2907]

Great explaination...thanks Ruven.
Lot of things are cleare after replies from you for the questions I had. Thanks a lot for explaining each point with patience.

-Suhas

[Rajeev]

Hello everyone,

This explanation was very insightful, thanks. I do have a question I haven't been able to answer.

What is the rationale for using the processed and compressed tiles stored in memory by memcached exclusively when the HTTP_IF_MODIFIED_SINCE header is present in the request header?

Please correct me if I'm wrong. My understanding is that the HTTP_IF_MODIFIED_SINCE header is only sent in a request header when a resource has previously been accessed by a given client. In context, this might mean that the IIPImage server needs to run the TileManager and CVT processes each time a new user requests a resource.

If the IIPImage server has processed, compressed and stored the output in memory with memcached for the first user, why does the request for the same resource from the second user need the TileManager and CVT processes to run again? The data stored in memcached is also naturally lifecycled with the cache expiry. Can we respond to the second request by returning the data stored by memcached while it is available?

I understand this is a relatively old thread and may refer to a previous version. I have however observed this behaviour in a recently installed instance. Please advise.

Thanks,

Rajeev

[Ruven]

The IIPImage server should already be doing what you suggest.

On a first request by a client, the full processing chain is run and the output is stored by Memcached. A subsequent request by the same client with a HTTP_IF_MODIFIED_SINCE header will result in the server replying with a HTTP 304 Not Modified header with no TileManager or CVT process being run.

If a different user now makes the exact same request, the server will fetch the result from Memcached and return that if it exists. If not, it will run TileManager, get the raw data from the internal cache and re-run the CVT process.