Google Analytics (GA) is a free service provided by Google for collecting statistics about website visitors. The product is currently in use by around 57% of the 10,000 most popular websites across the globe. GA can track visitors, sessions, traffic sources, goal conversions, page performance metrics and more.

GA is implemented by including what is referred to as the Google Analytics Tracking Code (GATC), and is a snippet of JavaScript code that the user adds onto every page of website. This code collects visitor data and sends it to a Google data collection server.

Monitis’ GA Monitor is a java package that permits the creation of a Monitis custom monitor for viewing Google Analytics on the Monitis Dashboard. This extension of the Monitis API was necessary due to the fact that every website with a lot of traffic uses Google Analytics statistics for analyzing visitor’ traffic — as well as real end-user experience metrics, such as average page load. So, Monitis has extend the general API with a new version expressly for Google Analytics clients.

To do this, one of the best options available for us was, of course, Java — which is fully supported by Google Analytics libraries. For using the new package, it is necessary to download the Google library data, which is available at code.google.com, plus the Monitis Java SDK — available on github.

Every Google Analytics monitor is identified with three parameters: username (Google account), accountname and profilename. The three values identify the monitor on the dashboard. This has been a necessary choice because every account can contain different profiles associated with different Google Analytics accounts.

The heart of the package is the GoogleMonitor Java class — which contains four methods available to the user:

1. Googlemonitorexists: Check if the monitor identified by username, accountname, and profilename really exists.
2. deleteMonitor: Delete the monitor using three parameters (username, accountname, profilename) — if it exists
3. writeValues: Retrieve values from Google Analytics and write on the Monitor Dashboard with the period selected:

• start date and end date
• time of query
• number of pages seen in the period
• number of visitors; average load page time

You can also expand the set adding new fields to the monitors on the dashboard.

4. addGoogleMonitor: Create a new monitor on the dashboard identified by username, accountname, and profilename (see monitor details screenshot). In the figure, it is possible to see that the monitor contains the three fields — again, username , accountname, profilename — that identifies it, and it contains the five fields to show values retrieved from Google Analytics.

The package also contains a test class that you can use to create a monitor, get values from a Google Analytics account, and finally, delete it.

To test, it is necessary to edit the properties file with the values: Monitis API Key, Monitis Secret Key, and the details of the login, Google Account password, and the account and profile used for Analytics. After doing this test, run it and see if a new monitor appears on the dashboard with the data taken from the Google Analytics account.

We hope that this information will make it easier for you to create a custom Monitis monitor — specifically for viewing Google Analytics on the Monitis Dashboard. Signup now for 15-days free trial.

Full source code for Google Analytics Monitis package is here – https://github.com/monitisexchange/Monitis-Java-Plugins/tree/master/GoogleAnalitics-Monitor 

We will organize this series in the following sections:

·         Application engineering and design considerations

·         Application Performance

·         Measuring and tuning performance

The information we provide in this series will help you build applications that perform well and meet the various performance objectives, such as; response time, throughput, CPU utilization, memory utilization, and disk and network I/O. We’ll provide information how to measure and monitor and tune your application by using the appropriate configuration. We will also provide a number of principles and best practices that help improve performance.

Setting Objectives

Important to remember is that you set performance objectives upfront that include workload, response time, resource utilization, and throughput. Settings these objectives upfront helps the decision making process during the design phase of your application and it helps you to evaluate the performance of your application.

If you define your objectives well, it gives you a handle on where to focus during design and development phases. Performance metrics are used to measure the various scenarios of your application and when you compare them to your objectives to determine if your performance goals are met.

.NET Performance Best Practices At a Glance

We’ll start with discussing best practices at a glance to give an idea what topics we’ll be discussing in this series.

Design Best Practices

·         When you consider performance, balance your requirements with other service attributes of your application such as security and maintenance

·         Model performance starting in the early stages of the design process to evaluate the objectives against your design decisions. This can save time and resources down the road.

·         When it comes to deployment of your application, take into consideration any corporate policies and procedures as well as the infrastructure that your application is being deployed on. Identifying these requirements helps selecting the appropriate architecture and resolve possible conflicts between your application and infrastructure architecture early on.

·         Prioritize performance, maintenance, and ease of development when selecting a particular development approach. For example, you can using structures eliminates the need to implement your own serialization. XML is great for interoperability and flexibility, however, it is quite verbose and can require a huge parsing effort. In addition, XML can be used to transport large amounts of data, so use a DataReader to render the data quickly, but do not pass a DataReader object between application layers.

·         If you are designing distributed applications, prefer a service oriented approach above an object oriented approach.

.NET Development Best Practices

The following items list at a glance how to improve the performance of managed code.

·         Use FxCop.exe to analyse your binary assemblies and double check they conform to the .NET design guidelines recommended by Microsoft.

·         Evaluate your object classes design and look at performance issues associated with class properties and implications of class inheritance.

·         Manage memory efficiently by writing code that helps the garbage collector to function efficiently. You can accomplish this by minimizing hidden allocations and avoid promotion of short-lived objects, pre-allocating memory, chunking memory, and forcing garbage collections.

·         Try to avoid creating threads on a per-request basis, or using Thread.Abort or Thread.Suspend.

·         Avoid making asynchronous calls if they do not add parallelism and that block the thread right after initiating the call. In those situations, there is no benefit of using asynchronous calls.

·         Clean up your resources as soon as you have finished using them. For example, use finally blocks in exception handling, or use Dispose on any disposable objects.

·         Try to use StringBuilder when creating complex string manipulations and concatenating strings multiple times.

These are a few of the best development practices. We’ll discuss all of them in detail in a follow-up article. Let’s list a few data access performance best practices.

Data Access Performance

·         Use database connection pooling to share connections across different requests

·         Allow the user to page through large results sets when delivering large result sets to the end user one page at a time. DataAdapter and DataGrid are appropriate for small amounts of data. For large result sets use the SQL SELECT TOP statement to restrict the size of a result set.

·         Try to stay away from moving binary large object data repeatedly, but consider storing pointers in the database to file locations instead of the binary object itself.

·         If you can use a DataReader object instead of a DataSet object, do so, but use DataReader only if you need read-only access to data and do not have a requirement to cache the data. Use DataSet when you need the added flexibility or want to cache data between different requests.

·         Optimize long running queries by using SQL profiler, and to identify the cause of the long-running query use SQL analyzer. ‘

Improving ASP.NET performance

·         Optimize your web pages by trimming the size of each page and reduce the number of graphics. Disable view state for pages that don’t require this. Make sure buffering is enabled to reduce the communication between client and server.

·         Tune your ASP.NET thread pool. We’ll provide details on how to this in a follow-up article.

·         Utilize the Cache API to cache your data, either by using output caching or by partial page fragment caching. To do this effectively, separate the static and dynamic areas of your pages and user controls.

·         Disable session state if you don’t need it. If you do need it choose the appropriate method from the in-process store, the out-of-process state servers, or SQL server. Generally, the in-process store offers the best performance. Use the ReadOnly attribute on pages that only read the session state.

Improving .NET remoting performance

·         If you use remoting reduce the number of round trips of communication by using chunky interface.

·         Serialize only the data that you need to improve serialization performance by using the NonSerialized attribute preventing unnecessary fields from being serialized.

·         Use the following methods to improve serialization efficiency:

-          Use column name aliasing to reduce the size of column names

-          Avoid serializing the original and new values for DataSet field if not needed

-          Only serialize those DataTable instances that you require

Improving Interop Performance

·         To reduce marshaling costs, consider he amount and type of data you pass to and from unmanaged code.

·         Avoid unnecessary  marshaling by using explicit In and Out attributes

·         You can minimize heap fragmentation by not pinning objects longer than the duration of a P/Invoke call. If you have a fairly heavily loaded server application, consider calling the Marshal.ReleaseComObject function to make sure your COM objects are released in a timely manner.

As you can see there are a lot of items to be taken into consideration if you want to improve the performance of your .NET application. Over the next few weeks we will go deeper into the topics that we touched on in this introduction.

Had I been told to monitor a cat chasing a mouse with Monitis, my answer would have been – “Yes, it’s probably possible”.
With the not-so-recent addition of M3 to the arsenal of monitoring tools Monitis can utilize, it is possible to monitor anything. However this alone is far from being enough. Smart implementations of proper applicative monitoring is what should be practiced.
This whole article is a port of Konstantin Kosenkov’s hard work into M3. Most of the credit should go to him. Konstantin managed to design and implement a few very interesting counters in a PostgreSQL (PgSQL in short) installation.

PostgreSQL in a nutshell

PgSQL is an open source, cross platform implementation of a relational database. Yes, there are a few similarities to MySQL.

PgSQL is widely popular and we at Monitis decided it’s time to build a comprehensive set of monitors in order to provide proper server monitoring and increased uptime if you are using PgSQL.

However if you are not a PgSQL user, I’d still suggest to continue reading this article as the monitors and counters suggested here are invaluable for any database installation and not necessarily PgSQL.

In the next few paragraphs I’ll outline the counters we’ve chosen to represent, one by one.

Operating system counters

Please have this M3 configuration file open while continuing to read as it makes things a lot clearer.

First two monitors implemented are not PgSQL counters. However provide proper a nice overview of what’s going on in the system.
The first three counters are showing the CPU utilization while the fourth shows the load average.

Next two counters in the next monitor show read and write requests per second to the PgSQL device. Combine both of them and we get what we call – IOPS – Input/Output Operations Per Second.

Just looking at these two monitors in Monitis should give you a good idea whether the system is or not overloaded.

TPS – Transactions per second

TPS can give you a good idea as to how busy your system is and how fast your business and application is growing, together with the “busy hours” of your business.
Another idea is to monitor your TPS and think of ways to offload these transactions from your DB.

TPS is measured with a very simple query. M3 will query the total number of transactions, then query it again and calculate the difference over that time.

Cache Hit Ratio & Commit Ratio

Every DB implementation strives to load as much data as it can into memory (RAM). But not always it can load all of the data into memory.

Whenever a query is made, if the query was served from data which resided in the DB memory – it’ll be called a cache hit. If the DB will have to fetch the data from a disk, it’ll be called a cache miss.

The ‘Hit Ratio’ counter will show you how well your DB is doing in caching data. A higher value means you are doing well – meaning the DB barely has to access the disk – meaning queries are returned much quicker.

Commit ratio on the other hand shows you how many commits (writes) are actually successful in the PgSQL instance. Anything lower than 80%-90% might point at a serious problem.

Database I/O – Cache hits vs. Blocks read

We feature two counters under this monitor:

1. Blocks read by PgSQL
2. Cache hits by PgSQL

These two counters were coupled in another monitor to give you a better view about the ‘Cache Hit Ratio’ counter we introduced before.

Dividing cache hits by blocks read should give you the cache hit ratio. The close the cache hit number is to the number of blocks read – the better your PgSQL instance is performing – meaning it fetches less from the disk and more from memory.

User connections vs. Max user connections

This monitor is very self-explanatory. We’ll display the number of currently connected users vs. the maximum users number the PgSQL is able to handle.

Memory & disk footprint

Both these monitors are very simple yet show you how much your PgSQL instance occupies from your whole system.

Memory counters will show a total on the server, used and used by PgSQL.
Same goes for disk – total, used and used by PgSQL.

Configuring alerts in Monitis is easy. Configuring these alerts will ensure a better uptime for your server. Be the first to know if you run out of disk or if your PgSQL instance is in need for more RAM.

How does it work?

Check out M3 from here.

Edit M3Templates.pm – filling in the correct DB you want to monitor, the device it resides on and your API and secret key. Then simply invoke:

 # ./AddMonitors.pl pgsql_statistics.xml # ./TimerRun.pl pgsql_statistics.xml 

It’s running – login to Monitis, sit back and enjoy the statistics gathering!

With M3 and Monitis anything can be monitored. Follow us on github and twitter.

One advantage of using Monitis to monitor your systems and applications is the flexibility to use either the native agent or custom monitor code written in virtually any language. For custom monitors, the REST API provides the basic foundation to interface programmatically with Monitis. For many popular languages, there are open source SDKs available to make the process of interfacing with Monitis even easier. You can find links to Java, Perl, PHP, Ruby, C#, PowerShell, and VisualBasic SDKs and example scripts at http://monitis.com/api/api.html#sdk.

The Monitis Sandbox

For this article, we’ll be using the Monitis sandbox, a free development environment available to aid in the creation of Monitis custom monitors. You can sign up for an account at http://sandbox.monitis.com/.

Netstat

Netstat is a command available on unix systems to provide information about the state of the network interfaces. It has several modes, one of which can display statistics about the number of packets and datagrams sent and received. While there is no common API across unix systems to access this data, it is possible to extract this information from the text output of the program. Since the output varies slightly from system to system, it is necessary to take these variations into account when using that output.

Netstat examples using the Python Monitis SDK

The examples for this article are available at https://github.com/monitisexchange/Python-SDK/tree/master/examples. There are two examples. The first, monitis_netstat.py, can be used as is to create, list, update, and delete netstat monitors. The second, monitis_netstat_minimal.py, is a minimal implementation intended to illustrate the concepts for this article, but lacking the structure to handle command line arguments, different operating systems, etc.

monitis_netstat_minimal.py

Let’s take a look at monitis_netstat_minimal.py, line by line. It illustrates many of the core concepts in the Python SDK.

The following lines are imports from the Python standard library, used for calling netstat, searching its output, and comparing output from netstat with that retrieved via the SDK.

from subprocess import Popen, PIPE
from re import findall
from datetime import datetime

Next are the imports from the Monitis Python SDK itself, used for creating new monitors and fetching existing monitors.

from monitis.monitors.custom import CustomMonitor, get_monitors
from monitis.monitors.params import ResultParams, DataType
from monitis.api import Monitis

The Monitis.sandbox flag causes the SDK to use the Monitis developer’s sandbox, http://sandbox.monitis.com. By default, when this flag isn’t set, it uses the production environment, http://www.monitis.com.

Monitis.sandbox = True

The following block creates a new monitor. ResultParams encapsulates the format for the parameters that a monitor accepts. One or more of them can be passed in to the next line. CustomMonitor.addMonitor takes the parameters and creates a monitor based on them. It returns a new CustomMonitor object that represents the monitor in the Monitis API.

rp = ResultParams(
    'tcp_packets_in','TCP Packets In','pkts/s', DataType('integer'))
cm = CustomMonitor.add_monitor(rp, name='netstat monitor', tag='netstat')
print "Created monitor: %s" % cm.monitor_id

This code extracts the interesting data from the netstat output. In this case, that data is the count of TCP packets received. This is the only block of code in the minimal sample program that really isn’t dependent on the API. A different monitor could get data in any number of ways. Note that this call to netstat is based on OS X style output, but only a small change to the command and matching string is required to adapt it to virtually any unix-like operating system.

subproc = Popen(
    'netstat -s -p tcp | grep "packets received$"', shell=True, stdout=PIPE)
(netstat_out, netstat_err) = subproc.communicate()
count = findall('(\d+) packets received', netstat_out)[0]

Next, add_result takes the new data, and posts it in the format defined earlier in ResultParams.

cm.add_result(tcp_packets_in=count)

Here, we check that retrieving the results from the monitor gets back the same data that we put in.

today = datetime.utcnow()
result = cm.get_monitor_results(today.year, today.month, today.day)

Finally, delete the monitor. This exists in this example so that it cleans up after itself and doesn’t cause unused custom monitors to pile up.

cm.delete_monitor()

In typical usage, a monitor is only deleted when that data is no longer needed. This principle is explored further in monitis_netstat.py.

monitis_netstat.py

Under normal circumstances, a monitor is created once, data is updated on a periodic basis over time, and then that data is viewed in the Monitis web interface. To ilustrate this, monitis_netstat.py has command line flags to create, list, delete, and update a monitor.

Create

Create a new netstat monitor:

$ examples/monitis_netstat.py -s -c netstat_mon
Using name netstat_mon
Created new netstat monitor

List

List the monitors to verify that ours was created:

$ examples/monitis_netstat.py -s -l
2267	netstat_mon

Update

Run the monitor 10 times over five minutes to gather some data to display.

$ while (true) do examples/monitis_netstat.py -s -u 2267; sleep 30; done
1253222, 1616400, 381497, 551524
1253393, 1616514, 381505, 551536
1253436, 1616553, 381512, 551545
1253468, 1616580, 381514, 551549
1253485, 1616596, 381517, 551558
1253526, 1616633, 381522, 551609
1253564, 1616666, 381531, 551622
1253599, 1616695, 381536, 551629
1253623, 1616716, 381538, 551633
1253647, 1616740, 381544, 551638

Once this is complete, the results can be seen in the web interface.

Delete

$ examples/monitis_netstat.py -s -d 2267
Monitor 2267 deleted
$ examples/monitis_netstat.py -s -l

Try it

To get the code and try this yourself, you can clone a copy from GitHub, install the Monitis SDK module, and run it on your own system.

git clone git://github.com/monitisexchange/Python-SDK.git
cd Python-SDK
sudo python setup.py install

Monitis API Keys

Before you can run the tools, you will also need to set up the Monitis API Key and Secret Key. By default, these are read from the following environment variables, which you can set on the command line, or add to your .bashrc or other login command file. The values for these keys can be retrieved via the web user interface under Tools -> API -> API Key.

# production keys
export MONITIS_APIKEY='API KEY'
export MONITIS_SECRETKEY='SECRET KEY'
# sandbox keys
export MONITIS_SANDBOX_APIKEY='SANDBOX API KEY'
export MONITIS_SANDBOX_SECRETKEY='SANDBOX SECRET KEY'

Conclusion

While the Monitis REST API makes creating custom monitors simple in almost any language, it becomes truly easy with an SDK to handle the REST interactions. This article has illustrated just how effortless it can be to collect important information from your systems and record it in Monitis custom monitors.

Signup and use free monitis sandbox here - http://sandbox.monitis.com.

See also Python Performance Tips, Part 1

A Few Thoughts about APM and Its Future

APM is a vague term. There is no agreement even on what it stands for: Application Performance Monitoring or Application Performance Management. Some background information can be found here Industry Watch: Behind the APM and DevOps buzzwords. If I had to define the terms, I’d say that the term Application Performance Monitoring befits the existing products on the market whereas Application Performance Management is more akin to what the industry wants and needs as it promises so much more than is currently available.

Garter Magic Quadrant for Application Performance Monitoring divides the APM market into five dimensions of functionality:

-End-user experience monitoring (a.k.a. RUM – Real-User Monitoring)
-Application runtime architecture discovery, modeling and display
-User-defined transaction profiling (a.k.a. BTM – Business Transaction Monitoring/Management)
-Component deep-dive monitoring
-Application performance analytics

But Gartner also has another Magic Quadrant for IT Event Correlation and Analysis, which perhaps may also be placed into the Application Performance Management area.

There are additional areas that border the 2 quadrants, such as active, or synthetic, monitoring, which can be aligned to application monitoring from one side and also has roots in load testing from another side. This means that for some service companies the line between active monitoring and load testing became somewhat vague too.

All the traditional disciplines such as enterprise monitoring and performance analysis, system modeling, and capacity planning, shouldn’t be discarded – in my opinion they are all important elements of the APM puzzle (although I’m not sure where Gartner puts them).

Bernd Harzog’s posts Why is Application Performance Management so Screwed Up?, VMware Joins the APM Revolution with vFabric Application Performance Manager, Comparing the Different Approaches to Application Performance Management for Virtualized and Cloud based Environments, and Who’s Who in Application Performance Management for Virtualization and the Cloud prompted a lot of discussion on the Internet.

The posts include a good list of existing issues you may face when trying to use APM tools, and lists some tools that the author considers as the second generation of APM products.
I’d add one important issue – overheads. At least for the first generation the claim that you may use APM in production worked only if you did very selective monitoring.

My view of APM is that the first generation of APM tools, so well described by Bernd, were very immature. It’s not that something was explicitly wrong with APM in general – what was really wrong was the drastic contrast between what the tools actually could do and marketing promises made by the vendors. The vendors talked more about the APM vision and how the APM tools are supposed to work – but not about the exact things that these tools were able to do – which you only figured out after spending a few days evaluating the product.

If you check Garter Magic Quadrant for Application Performance Monitoring or my list of tools, it is clear that the market is very crowded but not well defined. There is no set criteria to compare APM tools, which makes choosing one difficult as they may actually offer vastly different functionality and use differing technological approaches – not that you’ll be able to work this out from by reading about them on vendor’s websites.

I do definitely agree however, that now we are getting the second generation of APM tools which are much closer to what some technologies promise. I don’t want to list names here and separate “first” and “second” generations. I’d guess that some “first” generation tools might advance to the “second” generation if progress continues – but, as I said, it is difficult to say without detailed evaluation of the tools. Some comparisons like the afore-mentioned

Bernd Harzog’s post, or posts like Ben Bramley’s APM Market Disruptors – AppDynamics and New Relic provide important information, but they should really be taken with a pinch of salt.

Even if you assume that the authors don’t have any commercial or personal interests, it’s unlikely that they have an equally deep understanding of all the products they reviewed and probably evaluated them in specific environments, which may, despite sounding similar, be completely different from yours.

It still looks like there isn’t a product on the market that will do APM across all platforms and systems, particularly if you have a full zoo of different technologies some of which are older than most of your IT employees (as many large corporations do). And don’t believe anybody who tells you that they can do that. It may work for your environment but first check if it is doing what you need it to do in the way you want it to be done.

It does however look like you can do it now for more systems with fewer problems – and start reaping the benefits of APM. Actually I don’t see any other alternatives to APM in the long term – although it is rather a topic for a separate post.

I’d also say that we are now getting Application Performance Management as a new information category. APM tools were around for a while, but not generic APM information (something beyond just talking about tool features). Now we are getting multiple sources that are interesting to everybody involved in performance – even if you don’t use this specific tool.

Here are some examples of what I am referring to. Some of these blogs are from tool vendors, but they provide great content far beyond discussing the tools. Many of them have existed for a while, but it looks like the quantity has finally evolved into quality and we see a new discipline emerging (instead of a just marketing term used to promote tools). It is definitely related to new technologies, such as virtualization and cloud computing, where traditional resource monitoring is not enough anymore and there is also a need monitor application and service levels.

Alexander Podelko, a performance expert currently working for Oracle.

2. Monitis adds a monitoring node in Denmark
Monitis has just added its 17th monitoring node in Denmark to bring 24/7 robust monitoring to companies with customers and viewership in Denmark. To monitor your site from the new node, simply sign up for a Monitis account and add an external monitor. The Denmark checkbox should appear.

3. Server side caching: a great way to speed up your site! (Joomla and WordPress optimization experience)
Website visitors are impatient. If your page doesn’t load, they will go elsewhere. A study by Amazon shows that even a slight 100ms increase in load times will reduce sales by millions of dollars. One way to achieve decreases in response time is server side caching. Monitis recently implemented this plugin on its main website and blog, which run on Joomla and WordPress CMS, respectively. This post describes the process and shows the improvement it caused.

4. New! Cloud-based MySQL Database Monitoring from Monitis
Huge News! Monitis has just added MySQL database monitoring to its all-in-one monitoring service. Now you can monitor the world’s most popular database from the cloud. The MySQL monitor includes 246 monitoring variables and more than 21 different metrics to provide one of the easiest to use, yet comprehensive database monitoring tools available. This post introduces the product and shows how it will appear in your dashboard.

5. New Monitis MySQL Monitoring Tool’s Video
Monitis has released a video to announce the launch of its revolutionary cloud-based MySQL monitoring. It shows why MySQL monitoring is so important beyond basic http and ping checks. Many popular Content Management Systems, like Drupal, WordPress, Joomla, and MediaWiki are based on MySQL, so monitoring and improving MySQL performance can have a dramatic impact for millions of websites.

MySQL is the world’s most popular open-source database and platform for millions of web applications – it’s critical but cumbersome to monitor.

Monitis’ MySQL monitoring provides three key benefits:

Insight
» 246 potential monitoring variables
» 21 aggregated, percentage-based metrics
» Adjustable thresholds to separate real issues from false alarms

Control

» Monitor entire IT universe from one dashboard
» Quick diagnosis & root cause detection

Simplicity
» Cloud-based means no need to install, update or maintain it
» Leaves you time to focus on more important things

For a FREE trial, go to:

https://www.monitis.com/free_signup.jsp

SAN JOSE, Calif., February, 15, 2012 – Monitis, the leading cloud and web application monitoring software provider, today announces that it has added comprehensive MySQL database monitoring to its award-winning Application Performance Management & Monitoring platform. The robust Software-as-a-Service (SaaS) tool enables users to gain significantly faster insight when conducting root cause analysis.

The MySQL monitoring feature includes 246 monitoring variables and more than 21 different metrics to provide one of the easiest to use, yet comprehensive database monitoring tools available. It was first introduced into the free Monitor.Us platform back in June last year and has seen the code battle hardened by many hundred free users over the last 8 months.

Hovhannes Avoyan, founder and General Manager at Monitis commented “This feature makes it easy for systems administrators and web developers to measure and monitor the performance of their php environments such as Joomla and WordPress, from multiple locations around the world. It gives them a true picture of application performance from where ever in the world the user is. Because the Monitis MySQL monitor is part of the Monitis platform it provides an unprecedented holistic view of software, database and underlying hardware, giving pressured techs the ability to quickly and easily diagnose the root cause of slow application performance.”

The service uses a small Linux agent that can monitor inside an organization’s firewall and distributed systems. The Monitis agent connects to a local or remote database and collects a variety of health and performance metrics that are graphically displayed in real-time on a web-based dashboard. Users can also set up notifications (should their database go down or pass a certain level of access volume) based on client-defined thresholds and rules.

Some metrics tracked and reported on by Monitis — which can be set up in minutes — include:

• Database size
• Resource utilization
• Analysis of responsiveness/latency
• Analysis of throughput
• Database usage
• Scalability

“Monitis’ SaaS delivery and pay as you go pricing mean it’s easy to get going and has low set up and running costs. It puts the power of MySQL monitoring in the reach of techs who otherwise wouldn’t have had the time to set up or budget to afford such a comprehensive solution.” adds Avoyan

Monitis MySQL Monitoring provides much greater check-in frequency, as low as every 5 minutes, and the ability to check the performance of the database from multiple locations around the world.

About Monitis

Monitis is the leading provider of Cloud-based Application Performance Management & Monitoring solutions for System Admins and Web Developers. Over 80,000 users worldwide have chosen Monitis to increase uptime and user experience of their services and products.

Monitis’ core product offerings include website monitoring, website full page load testing, transaction monitoring, application and database monitoring, cloud resource monitoring, and server and internal network monitoring. What makes Monitis’ software different is how fast it is to deploy, its flexible pricing and feature-rich technology that provides a comprehensive single-pane view of on-premise and off-premise infrastructure and applications.

More information on Monitis MySQL Monitoring is available on our website.

We analyzed our own website, which is based on Joomla Content Management System, and our blog, based on WordPress. We found that even from monitoring locations closest to our servers, there’s a 100ms wait to get first byte. That may sound reasonable, but if the browser is making multiple requests to your website (for media files or javascript, etc.) it reduces full page load times significantly.

After doing some research on Joomla and WordPress performance we found several performance tips for decreasing that load time. One of the important ones is to use server side caching. Fortunately, both applications have caching modules available.

For Joomla we installed a System Cache plugin that comes with Joomla. Details are at http://www.theartofjoomla.com/joomla-caching-explained.html. With the plugin installed, we saw a nice decrease of about 100 ms in response time, shortly after 12:00.

On WordPress we used a plugin called WP Super Cache: http://wordpress.org/extend/plugins/wp-super-cache/ and after installing it we achieved a noticeable drop in response time for our blog. You can see a ~90% drop at 16:00:

This shows how dramatic load time improvements can be when you use server side caching. If you plan on trying it out, the best way to measure the improvement is with our External and Fullpage monitors.

Copenhagen, February 14, 2011– Monitis, the award-winning provider of the world’s first all-in-one cloud-based service that combines web site uptime, server and application monitoring, today announced the deployment of a new monitoring node in Denmark.

This will provide companies whose business relies on the Web, a complete and accurate performance picture from the perspective of both Danish and international web site visitors.

The addition of this node brings the total number of Monitis monitoring nodes operating around the world to 17.  Monitis’ nodes across the US, Canada, Europe, Asia, Australia and South America monitor clients’ key IT processes every 60 seconds – offering fast and frequent checks, as well as alert notifications into the health of servers, networks, applications, events, cloud storage facilities, cloud platforms, websites, transactions and other processes.

“The addition of a new monitoring node in Denmark will enable us to expand our level of service to businesses with customers in Denmark,” said General Manager of Monitis Hovhannes Avoyan. “What really sets us apart from the competition is the frequency of monitoring. If a typical service offers monitoring “once a minute from 100 nodes”, in reality it means each node is activated every 100 minutes. In the current business environment, companies can’t afford such delays before discovering slowdowns or disruptions at a particular destination. With Monitis service, customers may choose one-minute monitoring intervals from all our monitoring locations simultaneously.”

“As more companies come to rely on proactive monitoring and instant notifications of IT problems, Monitis is committed to continuously expanding the network of monitoring nodes and raising the service bar higher,” added Avoyan.

You can try Monitis service for free by signing up at https://www.monitis.com/free_signup.jsp

About Monitis

Monitis believes that the Cloud is the biggest thing to happen in IT management since IT management. Having seen this vision early, Monitis is now the global leader in developing this market.  It is the first affordable network and systems monitoring solution that is based 100% in the Cloud. Besides Monitis’ enthusiastic and loyal user base of 80,000 customers from small businesses to Fortune 500 companies to government agencies and educational institutions, Monitis has won rave reviews from the technology analyst community, such as ”Most Innovative Start-Up″ from The 451 Group and a listing in OnDemand 100, a ranking by Morgan Stanley, KPMG, and AlwaysOn, of 100 top private companies globally.

Monitis was founded in 2005 by a team of seasoned IT developers fed-up and tired of the limits of software-based tools, while inspired by the promise of the Cloud. Headquartered in San Jose, CA, Monitis’s team of IT professionals has extensive experience running enterprise-grade IT businesses, as well as starting and selling several IT start-ups. Monitis employs a global workforce and enjoys a robust average month-on-month revenue growth of over 10%.

For additional information please send us an e-mail to info@monitis.com or call 800-657-7949

For press inquiries, please contact press@monitis.com