Home     RSSRSS

Posts Tagged ‘Performance Engineering’

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 ComplianceAtomicity 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)


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


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: , ,

Transaction Response time–First Indicator of Application Performance

February 14, 2014 by kiranbadi1991 | Comments Off on Transaction Response time–First Indicator of Application Performance | Filed in Performance Center, Performance Engineering, Performance Test Tools, Quality, SilkPerformer, Small Businesses, Web Server

What do you mean by Transaction ?

What do you mean by Transaction Response time ?

Why is the Transaction Response time a key Performance Indicator for the application or system ?

Lot of young people who wants to become Performance Engineer asks me about these types of questions. Seriously I believe Transaction is often associated with the context.For Database DBA it could be something like commit the output of the SQL statement to the DB or rollback the entire output of the SQL Statement and bringing the DBA to its initial state due to some failures.For Developer, it could be related to 1 business requirement equal to 1 transaction and to the banker or domain specialist, it could be one entry in the ledger log.For the prospective of Performance Engineer, it could means any of the 3. It just depends on what is your objective of your tests or what are we looking for measure in the system or application.

The way Performance Engineer sees the transaction is bit different than the way Developer sees them.Some of the examples of the Transaction as seen by Performance Engineer are,

  • Time taken to do the login of the application
  • Time taken to generate and publish the report to the users.
  • Time taken to load the data to the database or Time taken to process xx amount of data and load it into the database(Batch Jobs).

If you look closely at above example, you can see that transaction is always associated with Time. Time taken to do X activity is prime focus of the Performance Engineer.The same might not be true for other folks like DBA,Domain experts or Developers.

One of the reasons as why Performance Engineer always associates time to transaction is because most performance tools have taught us to see transaction this way.Wrap the activity/event/Business functionality between start and end transaction markers and calculate the difference between these start and end time and say that these are our transaction response time for that activity.Most Load testing tools works this way and this logic works for almost 99.9999% of the application.However this kind of logic does not gel well with few of the technologies where non blocking of UI is more preferable than blocking of the UI. Comet/Push are some of the technologies where Marker based transactions do not work favorably unless you do some kind of the hacking.So I believe that Transaction marker based solutions work only for technologies where users waits for the response to come back.

Transaction Response time is most important characteristic of the System Performance from the Users point of view.If they are satisfied with the speed of the system to do more work in short time, then probably no effort is required to speed up the system, else lot of effort is required to increase the speed. Sometimes users are also satisfied with bit of high response time because they know the there is lot analytical calculation program/application has to do to bring data back to them.However when as more and more users starts getting into the system , they start experiencing slowness of the application.Application starts to more time to respond to the users request and the functionality which was taking 3 to 5 sec now starts to give response in 5 to 8 sec.As the user load increases, response time also starts to increase and after a certain point, it fails to respond to the users request.Performance Engineers calls this behavior a breaking point of the application.The reason for the application to stop responding could be many reasons ,however from the performance engineering’s prospective,its suggested that we do bit of analysis based on queuing theory.Rate at which application is receiving requests is more than the rate at which it can serve the requests keeping in mind the environmental constraints.Response time degradation can  happen not only when the number of users or volume of data exceeds some thresholds, but also after the application is up and running for a particular period. A period can be as short as hours or as long as days or weeks. That is often an indication that
some system resources are not released after transactions are completed
and there is a scarcity of remaining resources to allocate to new transactions.
This is called  resource leak  and is  usually due to programming/coding defects.

We say application is having performance issues after analyzing the trend of transaction and can conclude the below points based on data we have collected

    • Transaction response time is getting longer as more users are actively
      working with the system
    • Transaction response time is getting longer as more data are loaded
      into application databases.
    • Transaction response time is getting longer over time even for the same
      number of users or data volume primarily due to leaking of resources like memory,connections etc..

Transaction response time matters a lot when your application is web based application and its public facing site. The revenue of the company depends on how fast the application responds to the user’s request. If your application is internal , then it increases the productivity of the team and company over all.

Tags: , ,