Home     RSSRSS

Archives: Environment

Application Performance and Scalability

September 18, 2018 by kiranbadi1991 | Comments Off on Application Performance and Scalability | Filed in Development, Environment, Performance Engineering

Application performance is measured by service time (response time), latency, throughput, efficiency.

Depending on application needs, we describe performance as “how fast “can a given task or work can be completed by the program with the available computing resources.

Scalability means ability of the application to increase throughput or computing power of the program when additional resources (CPU/Disk etc) are given to the program.

Scalability and Application performance are two different things for the majority of the applications and almost all of the time they are at odds to each other and requires some level of tradeoffs. Designing the application for scalability often requires that we distribute the given set of work (tasks) across parallel threads or programs or computing resources so that all the given computing resources can be used by the programs so as to increase throughput.

Good example to understand this concept is deploying the some web application on a single server which hosts its database (Persistence), application server (Business layer), cache server (Service layer/persistence layer) etc. on the single machine. Since all the components of application are hosted on same machine, it’s bound to give very good performance (No network latency involved across any tier). However after a certain point, performance might start to deteriorate after reaching a certain threshold in terms of throughput. Once the threshold throughput is achieved. There is no way to increase the throughput since every tier is on same single server. However if we move the each of the layers on the different machines, then we might increase the throughput of the application, however this might decrease the performance of the application (Network latency involved here). It’s very rare case to see application performance and scalability go hand in hand.

Tags: , , , ,

Implementing Caching Solution

April 28, 2015 by kiranbadi1991 | Comments Off on Implementing Caching Solution | Filed in Development, Environment, Performance Engineering

I have been in quite a few engagements where projects used in process caching and distributed caching using various open source and commercial products.Some projects used memcache,ehcache and some used oracle coherence.I have seen project’s implement in different ways.Caching can be implemented declaratively or programmatically and some of the common questions to ask while implementing cache is,

– How do we refer to the cache component, by name , or id or something else .
– How many items do we need to store in cache memory
– How long do we want to store the items in cache
– Do we need to store items to disk as well, if yes how many items

I think these questions are good enough to get started on cache implementation.However depending on projects requirements we can implement caching in different ways.Maybe I will write something about it in next post.

Tags: , , ,

My SQL InnoDB Storage Engine

January 24, 2015 by kiranbadi1991 | Comments Off on My SQL InnoDB Storage Engine | Filed in Database, Environment, Performance Engineering, Small Businesses

MySQL comes with different level of support for InnoDB Storage engine for every version of its release. The Default configuration settings for InnoDB also varies version wise. So its always a wise decision to ensure that if we are upgrading the MySQL and are having InnoDB as default Storage engine, then it does no harm to revisit the configuration settings.

InnoDB is default general purpose storage engine and is recommended for all tables unless you have any special cases. MySQL Server has a pluggable storage engine architecture that enables storage engines to be loaded into and unloaded from a running MySQL server.

InnoDB has below features that separates it from other engine types,

  1. Row level Locking – blocks  reading or writing of table data by connections if another connection is currently using that data.(MyISAM has table level locks) .
  2. Acid Compliance – Atomicity means that if a transaction fails then the changes are rolled back and not committed. Consistency means that each successfully executed transaction will move the database ahead in time from one state to the next in a consistent manner without errors or data integrity issues. Isolation means that each transaction will see separate sets of data in time and not conflict with other transactional data access.Durability  ensures that any data that has been committed in a successful transaction will be written to disk in its final state, without the risk of data loss from errors or system failure, and will then be available to transactions that come in the future. So chances of transaction corruption is not possible or very small.All transactions are executed in isolations.
  3. Referential Integrity – It has ability to store data in multiple tables and maintain referential integrity and data consistency.

One can verify the type of engine used by MySQL by issuing below commands,(I have PhpMyAdmin and it looks something like below screenshot)

image

Also before creating any tables with InnoDB as engine, it makes sense to check transaction isolation levels. This can be checked with below command,

image

Transaction Isolation levels has of below options,

READ UNCOMMITTED -  Every select query operates without locks so you don’t get consistency and might contain dirt reads. So it violates ACID Principles and should never be used if your application issues transactions that require point-in-time consistent data reads.

READ COMMITTED – This setting offer consistent reads without table or row locks. Each consistent read, even within the same transaction, sets and reads its own fresh snapshot of point-in-time data.It offers  consistency and performance for applications that do not require full ACID.It does not fully comply with ACID.

REPEATABLE READ – The InnoDB default isolation level for ACID compliance.

SERIALIZABLE: This is the same as REPEATABLE READ but MySQL converts  select queries with the preface of LOCK IN SHARED MODE when auto-commit is enabled. If auto-commit is disabled then each select query is started in a separate transaction, which will ensure that all reads are consistent. This setting also allows for XA distributed transactions support, which you can read more about in the MySQL manual.The SERIALIZABLE value setting will impact database transaction execution performance, so only enable this if it is absolutely necessary.

Tags: , ,

« Older Entries