I have an api (Express.js driven) that doesn't do any disk operation. It only reads/writes to db. Would there be a difference if the machine runs an ssd type of disk or standard disk?
Does it influence the performance? Because I believe the require loads files only one time not every request.
Related
I read somewhere "A modern server has 144GB RAM memory", is that 144GB all used as cache?
When we talk about a server's cache, does that mean the server's memory?
It all depends on the caching method utilized by the applications that run on the sever. There are numerous caching methods, but two methods frequently used are persistent Caching and In Memory Caching.
With persistent cache, the application stores cache values somewhere intended to be “permanent”, such as the file system, database or otherwise.
Whereas, with In Memory Caching, the application uses the memory (AKA RAM, in your question 144GB) to store data. Using this method, the data is intended to be semi-permanent and not persist across reboots, application recycles, or otherwise.
If, when coding, you allocate a new object, dictionary, list or otherwise, these objects are stored in memory. Additionally, all of a servers memory is not available to the applications that run on said server. All operating systems and processes that are installed use the same RAM. Therefore, it’s common for a device that has 4GB RAM to only have 2GB reasonably usable, as the other 2GB is used by the operating system. Of course, these numbers depend on a lot of factors.
I was reading about Redis and Apache ignite, both of them are in-memory cache and also act as distributed cache. I was wondering what is in-memory cache? Where is the data stored ? In the memory of local system on which an application is being used or in the memory of server where the application is hosted? How does in-memory caching works?
Example:
An application with ignite cache is running on x IP address and I am using the application on y IP address so cache will stored in memory of x IP address system or y IP address system?
Also What does it mean when we say distributed cache?
The in-memory cache can be thought of as a cache that has performance critical information/data of a database that is shared across requests in an application. There is direct access to data/memory rather than through other mechanisms that enables database related operations to operate with high efficiency inturn increasing the throughput, responsiveness of the system.
In general, in the case of distributed cache based on deployment model, the cache memory can be between database and application in a distributed manner. This cache memory can be distributed between the nodes and shall operate based on the distributed hash table and the type of data. The access of data from cache in respective nodes can in turn shall apply the in-memory cache logic to bring in performance optimization.
Here is an example of how it is achieved with Amazon Elastic Cache
As you can see, the Amazaon Elastic Cache solution has a Cache Engine running in each node which implements the caching protocol/algorithm and the Amazon Elastic Cache can support cache sizes from 6 to 67 GB in a particular node. A DNS name is assigned to each Cache Node while it is created and you need to configure the DNS names of the nodes into the client library that is being used. Once your application invokes the Put or Get requests to the cluster, the library shall algorithmically choose a particular node using the hash function that shall spread the data out across the nodes and also help in fetching the same from the nodes.
A distributed cache partitions/shards your data across multiple cluster nodes.This allows utilizing memory and CPU resources of the entire cluster, and load balance requests. A node is a process that can be running on your physical server, virtual machine, or just be a Kubernetes pod. This article might be helpful to understand the basics.
Usually, an application needs to know the IP address of at least one cluster node to open a connection. Once the connection is opened, you would work with the cluster in a way similar to relational databases - just issue your SQL requests, compute tasks and perform other operations.
Also, watch the In-Memory Computing Essentials for Software Engineers recording that covers most of your questions and introduces you to the essential capabilities of Ignite. There is free instructor-led training that is scheduled from time to time on this topic.
One of my Railo web applications generates too many I/O requests.
Since it's hosted on an Amazon Ec2 instance, that directly affects my billing badly, because of EBS disk activity (hundreds of milions of operations).
How can I monitor I/O requests? The perfect tool would allow me to find which template/component makes intensive I/O.
I'm already using FusionReactor and that's great for profiling memory spaces and so on, but it doesn't have anything for I/O.
so you could start out by using the operating system monitoring tools to see if you have mainly reads or writes, next step is looking at memory issues despite it being an disk IO issue, maybe your servers are low on memory and thrashing the drives as they are swapping pages in and out of memory.
if you have not done so turn on the template cache this will stop railo checking the file system on every page request (provided you have the memory).
if you have plenty of memory (both for your OS and for the JVM) and you have template caching on start looking for your busy pages in fusion reactor, check for cffile, cfdirectory and other tags in these pages.... good luck.
also use of queries of queries is often a culprit in high disk io as internally a database is used which runs pages to disk on large resultsets if I remeber correctly.
My Azure cloud service reads and writes to blobs using the .Net storage library (1.7). The blobs are in the same data centre as the service. In my first container, operations are fast (order of 10ms). In my second container they are very slow (typically about 2s or 14s, not much in between). Both are transferring the data using CloudBlob.DownloadToStream() into a MemoryStream. File sizes are typically less than 100kB.
Now I admit I haven't set up a proper test to be able to demonstrate all the above - I'm just going by my log files, so there could be some subtle difference in the way I am accessing the blobs. Apologies if this turns out to be the case.
Anyway, the only relevant difference between these two containers seems to be:
The fast container is accessed frequently (tens of thousands of requests per day), and the slow container quite infrequently (perhaps 200 requests per day).
The fast container typically stores items that are fetched soon afterwards. The slow container is often loading things that might have been stored days ago.
Question: What factors affect blob performance for infrequently-accessed blobs? What can I do to make it faster?
(I don't know how Azure blob storage is implemented, but based on the above I'm going to guess that the data is saved into a storage array and accessed via a dynamically scaling collection of VMs, each of which implements in-memory caching of blobs. Thus the ~14s delay occurs when Azure finds it needs to spin up the VMs. The ~2s delay occurs when a VM is available, but it needs to hunt down the data on a physical disk (seems rather slow), and the 10ms delay occurs when the item is stored in an in-memory cache, or something like that.)
Windows Azure Storage is not architected how you are describing (with an expanding number of cache VMs), so there would be no impact of some data being cached and other data not being cached on the Azure Storage server side. See Windows Azure Storage Architecture Overview for a good overview, or SOSP Paper - Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency for a more in depth look.
To determine why your blob requests are slower, the first thing to do would be to determine if the slow performance is server side or client side. Fortunately Azure Storage makes this easy via the Storage Analytics (Windows Azure Storage Logging: Using Logs to Track Storage Requests) - just compare the End To End latency and the Server Latency. I suspect you will see one of two things:
Low E2E and Low Server. This would indicate that either the request is getting delayed being sent from the client (ie. not enough worker threads), or your logging is providing incorrect data.
High E2E and Low Server. This would indicate a problem on the client side in processing the request (not enough worker threads to process the Response, slow processing of the memory stream, etc).
I guess NTFS (file system of Windows) has some cache. Suppose I have a file, which is frequently accessed (read-only). How can I check if this file is in the file system cache ? Can I increase the file system cache size ?
Check
http://blogs.technet.com/b/askperf/archive/2010/08/13/introduction-to-the-new-sysinternals-tool-rammap.aspx
You can use RamMap which will give you a dedicated view of how current system is caching files.
Also to mention, cache isn't based on file, more by block/page.
There is no direct way from user space to detect if a file has been cached (partially or completely). In a multithreaded/multiprocessing environment, once you have received this information, it is instantly out of date.
There is no "limit" to caching in Windows that can be adjusted (although my data is Windows 7 and prior versions). The cache manager simply uses the memory manager to place data into memory and get callbacks when physical memory needs to be reclaimed (say, by an application's demands). The memory manager trades off file cache against memory demands of processes.