At my workplace we're planning a major refactor on our core product, a web application with several 'modules'. I quoted that because that's one of our main concerns: modules are not really modules, the whole thing is monolithic. The application is written in PHP with smarty templating and using Pear for accessing a MySQL database. We're not really concerned with database independence, although it would be nice if that wouldn't take months to implement.
Our main concerns are that development time/cost is increasing exponentially because of bugs popping up in unrelated places and not having a sound common architecture to rely on to get the most common functionality (each module is basically copy/paste from the previous one, then adapt).
I've got some experience with the web MVC principle, mainly in ASP.NET MVC. I like the clean separation it offers and the testability. However, when trying this on a local machine the app is simply a lot slower than it should be.
Alright, enough introduction, off to the questions:
- Should I rely on caching modules? Does this remove most of the overhead using a good architecture provide? Something like APC.
The application is mainly read. Writing is mainly single values (change a single field on a record). Any OR/M for PHP that are good at this?
Also looking for a flexible MVC framework. I know Zend, CakePHP, maybe Symfony?
The tricky part is that we don't have the luxury of being able to do a full rewrite. We'll have to incrementally improve a currently very messy codebase. This has to be done while writing new code, or fixing bugs. One thing I'd really, REALLY like to be able to do is write a regression test for a new bug before fixing it, to prevent it from popping up again later (this happens, occasionally).
The stack I'm currently considering contains:
MVC framework of choice
Logging (log4php?)
an OR/M of choice (doesn't have to be dynamic, code generation is fine too)
IoC container of choice
Smarty Templating, perhaps abstracted so we can switch it out if we need to.
Opcode cache of choice (we're using one now, forgot which one, have to ask sysadmin)
The main point that worries me is the performance implications of creating clean code in PHP. Seeing it's a parsed language opposed to something like the .NET/Java web stack, creating abstractions for otherwise in-line code (with obligatory separation in different files) might create new problems on another level.
Note: Retag if you come up with more appropriate tags, I'm not sure on the current ones.
Having a clean setup isn't a performance issue, usually. Most performance is spent with databases or other external systems you're talking to.
Except for these there are usually one or two hotspots which might be worth optimizing but for that you should start with a clean design, then use a profiler (like XDebug or ZendDebugger) to identify the bottlenecks.
A clean software design is way more important than the 0.01% performance gain by a "optimized" design. Usuallyit's even cheaper to buy and run more hardware than worry about an "optimized" codebase which is unmaintainable.
I'd stress budgeting time to build tests, with the following arguments to management:
When developers fix a bug, allow them to write a test for the bug. Bugs reoccur much more often than they probably should, and this is a cheap and effective way to stop that completely.
When developers are building new functionality, allow them to write tests under it. Since they're completely familiar with the functionality at that point, this is the least expensive time to build the "safety net" of automated testing.
Don't candy coat how long testing will take you; whether it's 1% of your time or 50%, give that to the manager straight, but stress that building automated testing as a safety net will stop users from hitting as many bugs, and will save developer time for new development instead of bugfixing.
As far as managing an MVC component with a spaghetti code component, we had a similar issue with a large project. What worked well was just taking a directory and making that the new docroot for MVC app (Zend Framework in our case) such that:
old part:
http://site.com/data.php
http://site.com/other.php
new part:
http://site.com/app/controller/action/...
Re authentication, you have a couple of choices. Probably the most logical is to redirect your login.php script to the MVC login and then pass it back to the original page that you want to go with necessary info passed as a GET parameter. This will allow legacy and new systems to exist simultaneously and transparently.
Re slowness, before I would pull out XDebug, I would try to isolate a problematic part and just output times it takes. Faster IMHO.
There isn't any good reason that well structured object oriented code should perform significantly worse than sapghetti php code in a database driven web application. You need to do some profiling to find where your bottlenecks are and optimize accordingly.
You do have a tough (but not uncommon) situation.
As far as organizing the code to minimize bugs, all I can give is a tip of the cap to DRY.
For performance issues, those are easy to find, because their very slowness shows them to you, by this technique.
Related
I'm currently trying to find the best solution/technology to build our ERP.
Our line of work is very specific, no ERP on the market would fit our needs (or 50% of them), so we decided to go for an in-house solution.
We were advised to choose a client/server solution (.net + WPF), but the result of the first delivery is below our expectations.
We are currently thinking about starting over in php (with the same SQL Server Database), and wondering :
Would a php framework (Symfony, Laravel) be a good pick ? We need to have freedom, to ensure maintainability over time
Would a front-end framework (Bootstrap, Foundation, Materialze) be a good idea
Or should we do everything from scratch
Our main concerns are :
Those framework (and the web itself) will evolve, meaning we have a high maintenability risk (although we can prevent our employees to not use our recommanded browser)
Those frameworks are already well organised, meaning it might be difficult to do whatever we want with them
If we use addons (like UI Kits, JQuery scripts), we will multiply compatiblity risks over time
Considering the investment, our solution should have a 10-year lifetime (with maintenance and improvement over time, of course)
While this question is based on advise and not really suitable for this website. I will do my best to answer your questions.
Would a php framework (Symfony, Laravel) be a good pick ? We need to
have freedom, to ensure maintainability over time
It would, Laravel is based on Symfony and has more out-of-the-box solutions. With Symfony you have more freedom.
Would a front-end framework (Bootstrap, Foundation, Materialze) be a good idea Or should we do everything from scratch
You could use any of those font-end frameworks, however they update reguarly, keeping up with trends. Updating a font-end framework means updating every view you have. You could choose not to update however.
If we use addons (like UI Kits, JQuery scripts), we will multiply compatiblity risks over time
jQUERY has been around since 2006 and is not likely to go anywhere anytime soon. It would advise it is safe to use.
I'm currently working in a company that made a from scratch ERP 8 years ago. They had a similar line of work and no ERP fits the needs.
So 8 years later (today), the erp is still used every day, but it's like impossible to maintain. Php (and tech in general) evolves so fast that you can't waste time (and money) evolving it.
Server version
Security failures
...
I recommend to use a "safe" framework with :
long term support
Easy migration system between versions (which means you can evolve your erp easily)
So yes, using a framework is the solution imo. And symfony seems to be the safest. You'll first need to learn how to use it properly but after that you'll be free to do whatever you want with it. Moreover, you can find help everywhere on this framework. It has a strong community which is an important strength.
In the front office, Bootstrap and JQuery are safe too. Bootstrap has a strong community too, and jQuery is not moving on versions.
I'm working on ERP solution and all I can is tell you about how we do it:
PHP framework should be used for your project because it gives you a
good base on what to work on and speeds you up. I'm working in
Laravel and it has all I need.
We are using Bootstrap 3. I'd recommend using some sort of front-end
framework because if your html will be written in easy-to-read manner
then upgrading to newer versions of framework shouldn't be hard.
We use JS + jQuery + vue.js. All I can say is: you shouldn't rely on
JS, php is what your project is based on. JS should be used for
simple stuff that make page feel more dynamic. As JS libraries are
written in JS they will barely lose any functionality over time.
I really should vote to close this - it's both too broad and primarily opinion based.
If you want to develop a web based application using Java, C or C# then a framework is pretty much essential. But with PHP it's a very different story - you are starting with a language specifically designed for the purpose which comes with a rich library of tools from a single vendor. Further if you develop on a Linux platform then the development tools and the platform all come under one provider for patch management. As soon as you start adding in third party components, the problem becomes much more complicated.
For seem reason, Open Source projects seem to thrive and do well when they are making frequent releases. For commercial software regular releases are important for generating revenue streams. When a product is finished in development it seems it is finished in the market. Consider pound vs haproxy.
IME the quality of code you can download from the internet varies greatly. Sadly popularity does not always equate to quality (but price has little relationship either). Frequently programmers are too focussed on delivering functionality to consider security, performance and scalability. Indeed there seems to be a belief that adding more functionality into a framework gives it some advantage over other products (more functionality = more complexity = more bugs = less security + harder to fix).
A problem specific to PHP frameworks is most seek to be all things to all people (more complexity) - providing session abstraction, templating, database abstraction, templating, routing... There are some exceptions of highly focussed tools (e.g. smarty for templating, metabase or AdoDB for database abstraction, jQuery for interacting with the DOM) which focus on doing one thing and doing it well.
Once you start adding third party code into your system, you need to ensure methods for ensuring that code is up to date - but the cost is up front - adding the second, third, fourth... package has a lot less impact than adding the first one (assuming that you do put proper process in place around the management of sourcing and deployment). Using composer helps (but falls a long way short of fixing) the base problem.
Yes, you will be encountering problems that other people have written solutions for. Using a (good) framework or library will probably save costs early on in the project (once you have dealt with the bump of getting your development team up to speed).
Those frameworks are already well organised, meaning it might be difficult to do whatever we want with them
I suggest that if they are well organised it should make it easier for you to do whatever you want with them!
But have a look around SO - frequently people are posting questions asking how do I do xyz with CakePHP / Falcon / CodeIgniter / Laravel. In most cases, what they are asking would be easier to do without the framework rather than via the framework.
I could go on, but this reply is already too long.
There is no answer to your question. If there was it would depend on a lot of other factors like available skills, risk appetite, budget....
If you decide to use a framework (or frameworks) then do consider building the system around micro-services and (if practical) avoid using the frameworks front controller. This will reduce your dependence on the framework if you ever need to re-engineer it out.
I'm deciding on a web framework for an upcoming project, and I'd appreciate any advice. We've decided to use jQuery for the JavaScript, and are heavily leaning toward Python or PHP (more Python) for our server-side logic. I'm especially interested in web2py because of its jQuery integration.
About our project
Our project is to develop a security console for a complex
cybersecurity system operating within an organization's internal
network.
This console will be largely server-driven, as messages come in from the network and must be pushed by the server to the user.
The user will also be able to initiate security actions, the implementation for which will likely be in C++.
The interface we've planned will be relatively rich, and I want to leverage jQuery's power as much as possible.
We have some control over the browser environment we'll be running in (e.g., we don't have to worry about clients with JavaScript disabled).
Our site is likely to have only a few, long-lived client connections.
We are looking for software components with permissive licenses, though we're using some copyleft components (I see that web2py is LGPL while Django is BSD, so +1 to Django)
We have about a month to create a functional demo of our system, of which this interface is a small (but visible) part.
About us
We are two developers with about 5 years of programming experience, but little web development experience. I have several years of Python experience and a summers' worth of experience messing around with PHP. My coworker has some Python experience and has never touched PHP.
I used Django once back in 2008, and was frustrated by the file and code structure, which I found highly unintuitive. Perhaps this structure is inherent to the MVC model (I've had similar experiences with Django and CakePHP since), and I just need to bite the bullet and memorize it.
My Question
Given the information above, what are the relative advantages of the various Python/PHP web frameworks for our project? As mentioned above, I'm especially interested in web2py because of its jQuery integration, though Django's dominance is (once again) hard to ignore.
Thank you very much for your time!
Before deciding on a framework, you should first decide if you want to commit to a language you are unfamiliar with.
You said you've both got minimal PHP experience, so you have to weigh up the advantages here; Will the pros for going PHP (if any) out weigh the amount of time the developers will need to spend to retrain?
(Although depending on your background experience, PHP should be very easy to pick up.)
If you frame it like that, PHP would have to have a pretty convincing offering to give you. From what I'm seeing, specifically Django vs web2py, they both seem very close in functionality - which is good, but doesn't provide the "you must use x!" scenario you may be after.
However, If you will be bringing more people in later and feel finding people to work with web2py will be difficult, it may tip it to PHP. You said your self, Django's popularity (and BSD license) is hard to ignore, and it should make it easier to find people for later expansion.
If it were me, in your shoes, I would go with web2py. Assuming the development team will continue to be Python focused for the foreseeable future.
Python vs PHP: Python
With python, you can always write wrappers for C code so you won't have to mess with starting other processes and passing args to them. That might be useful for your security functions.
Web2py will allow you to easily write a webservice for this too, to more easily integrate the C portions with the web-site infrastructure.
If you already prefer python, I would go with that. If you need to bring on web-developers later that are trained in PHP, teach them Python. It won't take long, and I'm sure they'll appreciate it in the long run. Plus, moving from a PHP MVC framework to web2py or even django would make things easier. I've used CodeIgniter for PHP and find that web2py was so much simpler and easy to understand.
Also as for the directory structure, django is not actually true MVC -- it's MTV (model, template, view).
I find web2py's organization a little more straight-forward. But yes, either way it can seem strange at first. I would say YES, you should bite the bullet and use MVC.
In web2py, the "view" is html markup with the ability to write raw python code. The controller extracts data from the model (database), attaches any needed files (css/js etc) and the model of course simply defines the structure of the data and allows you to access it in an OO way.
Lastly, I wouldn't tip my hat in favor of web2py just because of jQuery integration. It does use it, and a some of the built-in framework stuff (like response.flash/session.flash, the LOAD function that loads a page or data from another controller) rely on jQuery, but using it in another framework only means you have to write an include statement (e.g. ).
But, the way it allows/forces you to focus on development is what takes the cake for me.
I've been using Django as part of my work for a couple years now and truly enjoy it when I can make it work. Unfortunately, and maybe it's just me, but I end up spending hours working on configuration every time I start a new server, or try to make it work in a development IDE.
It's relatively simple to start a new project and start coding. But there are all sorts of little catches that keep things from working if you deviate from the norm. Things like if you want your django project to serve from a subdirectory like example.com/django. The information is out there to make it work. But it's hard to find.
I can't tell you if web2py has those same problems or not. I only just learned about it from your question. It does look slick and simple though. I can tell you that after the hassles of getting the applications to serve properly from whatever server configuration I'm using, django is way more fun to program with than plain php. PHP frameworks may differ.
From my understanding the project not usual web application, you must need event driven program, web server in python.
Django won't help you here.You should look into Flask, Flask has inbuilt console too.http://werkzeug.pocoo.org/, you might need to use twisted, gevent,Flask jquery.
I would recommend asking about web2py on its mailing list -- you'll get lots of help and advice there. Regarding the LGPL license, note that it only applies to the framework, not your application -- you can license your application however you like, including closed source/commercial.
It sounds like you'll need some server push functionality, but if you'll really only need a few long-lived connections at a time, you might not need to bother with solutions like Twisted or gevent. If necessary, though, web2py does include this (requires Tornado, and works using WebSockets, though can be adapted to use other methods).
Many conversations on frameworks tend to discuss ease of use and speed of development. These issues are important but they tend to come from developers who are creating new low traffic projects over and over for different clients. It is important in that situation to be able to knock out a solid solution for the client in as little time as possible. I myself have operated in this area for many years and have used many MVC frameworks with much successes.
But what about when you are working on a single high traffic application for several years? Now ease of use and speed of development start to take a back seat to scalability and speed. It doesn't matter how easy it is to use or how fast you can write code if the application won't function because of speed and scale.
My question to any large scale developers out there is, are frameworks still useful in this situation and if so which have been used successfully in large scale production situations?
common frameworks: zend, symphony, codeignitor, cakephp
When it comes to large applications, it's not the framework you should be concerned about, it's the database.
First decide which database you going to use, then look for a framework that has good support for that database. If you want your app to scale to unlimited size and still be fast, you should eliminate Mysql as an option right from the start.
Look for NoSQL solution, find the one that you like. Cassandra, MongoDB, CouchDB are the top 3 choices, but there are others. All of these are fairly new, but some of the biggest sites in the Internet are using them. Do your research, choose database, then choose framework.
I don't know most of the frameworks, I looked at Zend and Symphony2, both support MongoDB, both are pretty fast. I would look at either one of these 2, no reason to look anywhere else.
But really, if you plan on writing a really large application you should really write your own code and don't use frameworks. This way you will have only the functions that you need and none of functions you don't need. Remember most frameworks offer you a lot more functionality then you really need. Unnecessary functionality usually slows down your app.
if you want a fast app, then it has to be lean, only do what you need and nothing else.
symfony is used by Yahoo on it's Bookmarks and Answers site.
You should note they ditched the ORM so the database remains as the main concern for scaling (as Dmitri stated), you can read more about it here.
Dailymotion is also using symfony.
My question to any large scale developers out there is, are frameworks still useful in this situation and if so which have been used successfully in large scale production situations?
I've seen symfony-based applications successfully scale up to many thousands of users so is a strong candidate.
The creator of php liked codeigniter(in the past) the best, because it is the fastest framework when he benchmarked it. You can listen to video about that over here.
To add on to what the others have already said:
You can start off with any framework as your starting point. As your application gets bigger (and I mean, BIG), you can start modifying the framework and customizing it to your application's specific needs. After all, frameworks are a general solution to most problems.
You should pick whatever framework you're most comfortable with, and tailor it to your needs if your application ever grows extremely large. No point worrying about a million visitors when you don't have them yet.
WordPress.com is about the 22nd most popular website in the world and it runs on (you guessed it) WordPress, which is a framework with a large amount of overhead. So it definitely is possible.
Whether you are using a framework or not, you end up working on the same kinds of problems as your site gets to massive scale. Building on top of a framework means that you'll have one less problem (no custom framework to write) while working on other scaling issues. However, you may have to extend or tweak that framework to work with whatever technology you need to scale.
And in general, what I would recommend is that you don't blaze your own path. Find an app or site that is comparable to the one you are building and figure out what technology and techniques they used to build that site (many like WordPress.com, Twitter, Google projects are well documented or have chatty developers) and use the same technologies and techniques. You'll benefit from them figuring everything out ahead of time.
Zend Framework is a good framework but not very fast.
Can you tell whether it's worth using Zend Framework for highload projects, for example, for email marketing service that can inlude about ten or houndred thousand of users?
Is it possible to achive acceptable performance using Zend Framework?
Has anybody such an expirience?
Thank you very much.
For what I have seen, the definitive defense of Zend Framework performance and recommendations for performance optimization comes from Padraic Brady at:
PHP Framework Benchmarks: Entertaining But Ultimately Useless
In particular, note his four recommendations for performance optimization:
Don't use Zend_Application. While Zend_App is great for creating consistent complex bootstraps within a standardised structure, it doesn't come without a significant performance hit to baseline performance. A more direct bootstrap (typical of ZF until Zend_App arrived) is far faster and can also be done without configuration files.
Skip using the ViewRenderer plugin. Without the ViewRenderer, you need to manually configure Zend_View and add render() calls to Controllers. This is actually very simple to do and is fairly fast - fast was never really part of the ViewRenderer's genetics.
Use autoloading. Strip require_once calls from the framework library so unneeded files are ignored. Replace uses of Zend_Loader_Autoloader with a not-so-crazy autoloader function. In fact, pray Zend_Loader is never used - it does a lot of file ops that, to date, have never been explained to me as having any value.
Preload everything (Symfony 2 Preview does!). It buys you some performance cookies and equalises the speed baseline. Using a simple preload script is not that hard.
We've used ZF in a lot of high traffic sites, and we've had no issues so far. We did have to jump through a few low-hanging hoops, though.
Some suggestions:
use Zend_Queue to help with batch mailing
use Zend_Cache whenever possible
Use plugin loader cache
Strip require_once calls in favor of autoloading
Get rid of components you don't want. (as suggested, you would not need MVC stack for CLI / mail)
We chose Sphinx in favor of Zend_Search_Lucene (enormous performance gain)
The bottom line for us has been this: development time is much, much more expensive than hardware. The flexiblity and higher re-use of code completely trumps any minor performance losses we had to deal with. For the most part, the performance overhead was very fixed.
You ask:
Is it possible to achive acceptable performance using Zend Framework? Has anybody such an expirience?
Yes, I have experience with a site with millions of users. But you do need to use techniques to deal with the high load. Caching etc...
A CDN can help a lot. Look into developing with the cloud. Amazon might be a pain to get started with but it helps you scale if need be.
I guess what I'm saying is, the Framework may cost you a bit of performance, but helps make maintenance possible and building it faster (once you get over the learning curve). Then you you have to evaluate what needs to be done to improve performance (although it helps a lot to plan for what will be obvious problems, right from the get go).
I know of several companies that use ZF in high-performance/high-load scenarios. I don't know which ones I can state and which ones I can't, but some of them are media companies who have to handle popular TV shows. Others handle live sporting events. Others are multi-billion dollar companies who need to serve their internal organizations. So, ZF is being used by plenty of companies who run pretty high-load sites. One of our case studies is Fox Interactive (http://framework.zend.com/about/casestudies) and I know of several other customers who use it for high-performance websites.
Zend Framework MVC, out of the box, will be quite fast. My blog comes back in about 100ms without caching and there's a fair amount of stuff that happens on my front page. I could probably drop that down to 50ms with some internal caching (Full page caching could drop it down to single digit ms, but then it's not touching ZF).
Seconding Joe's answer. I've also seen ZF deployed on a few sites handling millions of requests and have yet to encounter a problem. When dealing with that amount of traffic it's a good idea to use other strategies beyond your framework, including but not limited to caching and the use of a CDN.
I've found most frameworks will call or create many class instances per request which I think is what causes people to say that framework X is slow without having any real world experience with it. Any hit you take there can be easily mitigated by using an accelerator and caching.
If you already have a team of devs you've hired, I'd suggest using what they feel most comfortable with and have the most experience with. Best case they'll be able to tune their code for that framework.
A lot of the framework, any framework really, is used for building and managing the project development but the resulting project is 'just' php, html, css etc. the same as any other php web site. So what evidence do you have, that's real timing against other framework and non-framework built sites not anecdotal evidence, that a Zend project site is slow.
Edit -- answers to below --
I don't think the structure that the framework uses will hurt performance. It may be more a question of PHP being acceptable and then how much 'overhead' is added with the site design and the optimisation of loading say JavaScript's etc. I would imagine that using the Yui guidelines of minifying JavaScript and CSS and loading them in the correct order and making sure the PHP code is efficient will help. You can also use other standard things such as DB Caching and Zend Accelerator will speed things up. One thing to be careful of would be the DB connection. The use of an ORM layer might have an impact.
However back to the original question about the framework i think it is similar to asking if using Eclipse or Textmate has an effect on the speed of the resulting site.
I am thinking of using a PHP framework called CodeIgniter.
One of the things I am interested in is its speed. I have, however, no way to find out how fast it is, and would rather not simply take the word of their website for it. Does anybody know how I can determine its speed myself, or can someone tell me of a site that can?
Code Igniter also has some built-in benchmarking tools:
http://codeigniter.com/user_guide/general/profiling.html
Yes, the problem is you have to build your application to profile it.
At work we had a couple of projects written outside which we load-tested before putting them on our main boxes. We were quite surprised to find critical performance problems with both; one was written in CakePHP and the other was written using Drupal. I don't think this highlights a problem with any framework or CMS other than the need to do profiling and load-testing on any site which is going to get significant traffic. In both cases it was what the developer had done, rather than the characteristics of the software platform, that caused the problem. For example, there was a recursive function call the developer had created in the Cake project which instantiated the entire Cake object every recursion and this would have taken out the server had it gone live under load.
In my opinion performance should not be a deciding factor in choosing a framework; the objective differences are likely to be marginal and the way you use it is likely to cause far more performance problems than the inherent performance of the framework.
I believe that to scale any PHP application to run under load, you will need an opcode cache and you'll need to write in intelligent content caching using something like memcached or whatever built-in caching your framework supports.
If your site is database-driven I would be very surprised if your bottleneck would be the application framework. "Fast" as in faster development is what I would worry about rather than "fast" as in speedy handling of requests. Significant optimization is better done by caching strategies and optimizing your database access.
Besides database access your own code will be where most of the time for each request is spent (and even that is usually not significant compared to database access), the framework will likely not be affecting the time spent on a request, unless it is really badly written.
It way be better to look for a framework which has good caching support (which Code Igniter may have, I don't know), that will almost always save you more time than the few milliseconds you could shave off the request handling by using a slightly faster framework.
Have a look at the Zend Framework too, it has the benefit of being PHP 5, whereas Code Igniter is still PHP 4, as I understand it. That may be an issue when it comes to speed, but in favor of which framework I don't know. Zend has good caching support and a database profiler that can help you find where your bottlenecks are.
i'd recommend testing it for yourself. use xdebug's profiler to create a cachegrind compatible file and webgrind to visualize the file.
that way you end up with very reliable information.
CodeIgniter is plenty fast for most projects. Some have posted here and if you Google, you will find that it compares favorably to other frameworks with respect to speed.
I would agree with another poster that performance is usually not a big concern when it comes to framework choice. The major frameworks all have sufficient performance for most projects.
I maintain a site that gets slammed a few times a year. Last year the development team rewrote the entire site using Codeigniter and we have had much luck in terms of performance. Additionally, the time it took to perform the rewrite was minimal as this framework is quite easy to work with. CakePHP in my opinion is also a good choice if you find that you don't like Codeigniter.
For CodeIgniter and other PHP frameworks, PHP Quick Profiler is very handy for benchmarking and measuring speed especially for database queries. You must check this out:
php-quick-profiler
It's very easy to install and provides an awesome GUI for examine different benchmarking tests.