5701 Lonetree Blvd.
Rocklin, CA 95765
|
(916) 920-4730 |
Too many Apache processes? Too many MySQL threads? PHP time-outs? Sluggish page load times? Yup, we have been there! With a multi-tier caching implementation, some smart infrastructure tuning and a decent data archiving process, and we can help you get that performance-hog off your back!
 | Ready to Get Started? |
|
Call (916) 920-4730 |
By analyzing your performance needs vs what the application and current infrastructure provides, we can identify, recommend and possibly tweak and tune your apps and infrastructure to meet desirable performance demands.
Our process is simple:
When your Web apps are not responding fast enough, the quickest reaction is to scale up the hardware. Sure, buying bigger and better hardware helps, but chances are high that your Web apps and the underlying operating system, Web server, interpreter, and database infrastructure are more likely to be the culprits.
PHP has a lot of tuning options. For example, if you use default session handler, you are creating, updating and deleting a file per session. What if you used memory (ram-disk) for the session storage, do you think you will gain some performance under heavy load? Or, what if you used a database for sessions instead? The right answer depends on your Web app’s needs.
You can even run it few different ways (cgi, mod_perl, fastcgi) and get very different performance profiles. By configuring PHP with just what your apps need and running it using in the ideal approach, we can help you tune your apps.
By default, MySQL runs well enough for typical applications. But left untuned it will soon become one of the major performance bottlenecks. Using data active archiving strategy, query caching, optimized table-space allocation techniques, along with memory (buffer) and thread management, we can achieve a great deal of performance before touching the code or data model.
By default, Apache uses a decade old pre-fork technique that is hard to scale up under heavy load. Using helper servers like lighthttpd, litespeed, etc. we can gain anywhere from 2x to 10x performance even before any PHP/MySQL code and database scheme review.
There are tons of performance configurations that need to be tuned just right to deal with performance on the OS level. For example, if you are planning to serve large media files, it would be best to enable Linux kernel’s sendfile feature and tune the file system with large block size for faster I/O. Similarly, we can relocate frequently used objects (files, locks, etc.) on shared memory and/or use memcache network server to speed up your apps significantly.
Once the infrastructure is tuned, the data model, data archiving strategies are really the next step for performance tuning.
Splitting the database read/write traffic across an array of replicated databases with a master database server enables extremely fast reads and fast writes due to of lack of contentions and thus avoid wait on table/row-level locks.
Badly written JOINS are often the biggest performance killer.
By reviewing and profiling your current PHP code base, we can identify the critical area of your code and perform revisions to optimize code for performance and enhance security.
We cannot tell you how many customers we have migrated from commodity servers that they purchased or some server farm has setup for them. A commodity server is one that uses low-end hardware and pretty much a PC dressed up as a server. A simple way to tell if you got a piece of junk server or not is to ask your vendor if they installed a RAID using SATA drives or not.
Most SATA drives spin at 7200 RPM at the most; many large ones spin at even lower 5800 RPM. Disks being the slowest part of your server with physically moving parts, imagine what would a SAS drive array spinning at 15000 RPM will do when compared to a commodity server running at best 7200 RPM. Also, how about a 15K RM SAS RAID array with Solid State Disk (SSD) based ram disk coupled with kernel level cache — bcache — the same stuff that works for large companies like Facebook?
Also, just putting a few servers together and having them communicate via the public interface (one that carries the Internet traffic) is so poor in performance that we get headaches just thinking about it. When you ask a commodity server firm to provide you a few servers, there is also a chance that they just allocate whatever servers are available. Typically, they have different server groupings so that if you ask for a mid-end Web server and a higher-end database servers, they will give you them from different subnets and have you do all your communication via using Internet IP addresses. So your internal traffic between your web server and the database server will go out in the same pipe where rest of their customers on the same subnets are sending their data. This creates more network bottleneck than a dedicated local private network running at gigabit and only sharing traffic with your own servers!
At EVOKNOW, every customer has a private physical (not virtual – VLAN) LAN for all their servers to communicate at gigabit speeds.
We’ve got you covered!