Search Results - nginx

Lockin can either be direct - multi year contracts or indirect by being dependent on the hosting provider for free services that have been packaged into the cost of hosting.

• For a strong disaster recovery plan, it is recommended you have backups taken into a different hosting provider. This is part of our bespoke disaster recovery plan we create for you.
• Evaluate another cloud or hosting provider - without disrupting your live server, a test with some traffic patterns can be evaluated, either for improved performance or lower costs.

We use nginx as the webserver software, validating requests then routing requests to appropriate servers. Checkout our blog articles on use of nginx.

php configuration for performance requires knowing how many CPUs are available to run php. For example, if you have a single 8 CPU (4 cores with hyperthreading) and you are running the entire stack including mysql, redis, nginx we would use a max of 6 for simultaneous php processes.

Great performance from mysql is available from Percona. We use features such as one file per table for write speed, direct write to disk for data safety and optimal cache configuration for speeding up page response.

If you bulk upload products, you would need a way to bulk upload images. There is no reliable way of giving a write only access to just the upload folder. Our stack supports uploading to a folder whose content is them magically moved to the final destination.

Magento creates right sized images in the product/cache folder. Our stack automagically optimizes the images at the system level, without a plugin. Original image files are not changed. The compression is lossy for jpeg files with a controllable quality allowing for a right balance between image quality and size. The image creation is CDN compatible.

css and js files are minfied by a "offline" process. Minified files are sometimes erroneous. This is due to the minifier being strict about syntax. For example a css file with a "//" comment. With our minifier system, you can exclude files.

Blacklist IP addresses that are either suspicious or spamy. Magento reports the IP addresses that perform actions like creating a new registration. Alternatively log files can be analyzed to determine the list. luroConnect / Insight reports top IP addresses hitting the site. Once you know what IPs you do not want, add to our blacklist. Our nginx configuration will do the rest.

A basic DOS protection is to restrict number of hits from a single IP address. Our configuration file defaults to enabling this protection. Hits from the same IP address are limited to the rate specified. Hits faster than the rate are first queued and then rejected. luroConnect / Insight reports these for review.

Your own IP addresses can be whitelisted to bypass this check.

Over 60% of traffic is generated from BOTs or programmatic access to the web server. Many of them are crawlers. While some such as google are essential, however, most of them are not. BOTs use resources and cause a caches to be misled with what is important, both leading to slowdown of web sites. Actively managing BOT access is essential.

When you upgrade your code you need to put the site in maintenance. Magento's default functionality is a switch - either everyone sees a maintenance page or every one sees the live site. Our private mode, implemented as a nginx configuration, has whiltelist IPs that get to see the live site while other IPs see the maintenance page.

We support any standard php frameworks - such as cakephp, laravel 4.x and 5.x.

We discuss your architecture and make a bespoke support plan.

While Magento's search has improved, external search can give features not possible with mysql search. Magento Commerce / Enterprise supports SOLR and ElasticSearch out of the box. However, requires configuration and management.

(Beta) A WAF based on open source ModSecurity is a standard part of our stack. Having a WAF as close to the server hosting the website is the best configuration. It avoids dual https hops for each request. With our WAF built into nginx, you have a superior edge protection.

Magento defaults to file system for caches and sessions. We use redis based in-memory cache. With separate redis processes for Magento cache, Full Page Cache and Sessions, Magento sites can easily server TTFB of under 1 second.

Magento 2 supports Varnish out-of-the-box for Full Page Cache. However, there are 2 problems - some 3rd party plugins do not support Varnish. Also, given that varnish does not support https, it is difficult to configure. Our Magento 2 stack supports varnish as well as redis based Full Page Cache, allowing maximum flexibility in speed and configuration.

Yes, if you have signed up for our done-for-you service to act on it as per SLA (Service Level Agreement). Each incident is closed with a root cause analysis document which would try to describe why the incident occurred and what steps are taken or have to be taken to prevent it from occurring again.

All CDNs give API based invalidations. However, each has a different terminology / concept and API calls. With our inotifywait based scripts we easily identify changed css / js files and invalidate CDNs.

An offline minifier is our preferred solution. Built as a grunt script, we would add this as a default step at the end our site update script.

We can also work on a custom nginx with page load module or apache's page load module or maybe even use the Magento merge and minifier.

When bulk uploading products, images need to be transferred to a specific folder. We would ideally like to give access to only the upload folder.

Our devops team has designed a solution for this. A image upload login is created where images are uploaded. Upon upload, the files are automatically transferred to the final location required by the csv.

Technically, the script uses a feature called inotifywait in linux. This watches the folder on which upload is performed and moves the file to the final destination instantaneously.

It is difficult to ensure all images are optimized before upload. Magento automatically generates different sized images that are needed on different pages. When using CDN, the images need to be optimized before upload to CDN.

Our devops team created a solution to solve this problem. Using the convert utility (part of ImageMagik) and inotifywait feature of linux, the moment a new image is created, it is automatically optimized. By watching the image cache folder, the images are converted typically before the CDN gets them.

Sites need code updates to be smooth. Code updates may come from plugin vendors or from internal developers or contractors.

Having a git repository is a starting point. When code is deployed there are configurations such as database and cache settings which are in files that need to be retained on the live server.  You may not trust a developer to have full access to the live server to deploy.

Our devops team has developed a easy to use special and secure login mechanism which you can cause the code to be deployed automatically with the specified files being retained. The access to this login is easily restricted with private keys making it very secure.

For larger environments we have a detailed deployment mechanism using jenkins that gives historical status of deployments and with an ability to rollback a deployment.

Testing a new plugin or getting a project completed requires to build a development and/or staging site. Reliably creating an environment at will is essential to higher productivity and avoiding "it works for me" situations.  Use of "localhost" have short term gains with long term pains.

Also taking backup of live data to test development code is detrimental to the performance of the live site.

Our devops automation will allow creation of a server and deploying the latest code and previous nights' database backup. Once the code is developed, committed and pushed, the developer instance can be safely destroyed.

No one likes wasted resources! Why keep a cloud server running or at full capacity when access is known to be low?

Our devops team can write automated scripts that use the cloud service API to resize or shutdown or powerup a instance at known time or with a single command.

Each scenario decides what data would be needed to recover. Often forgotten items to backup are system configuration files modified for our site such as nginx or apache configuration, email configuration, external search engine configuration, etc.

• Not all data has to be backed up – some files can be versioned allowing a restoration from a previous known working version.
• Location of backup is another crucial factor – we always backup customer data off-site – at a cloud location other than the primary hosting location. For example a different AWS region or a completely different cloud provider. Versioned data is also stored in a known location.
• Access to backup up data should be available – so pem keys, usernames, passwords, etc.
• It is also important to store information of the system services installed and from where (the rpms, versions and yum repos). As with versioned items these should be updated when changed.

It should be clear what data would be lost. Is your database replicated or backed up periodically? How about media files - are they backed up immediately or on a schedule?

Many times, a service may be down temporarily and a decision may need to be made on either waiting for the repair.

The tradefoff may be between the hours of data lost vs the hours of service that will be lost.

Who has the switch to initiate the process?Also the process may be initiated but the final switch may require a second confirmation.

All such process should be documented.

Just because you have a backup does not mean the restoration will be instantaneous. Human factors may also need to be considered. An estimate per scenario will help the decision maker and set the expectations.

Recovery services charge on initiating the recovery process. The charges may apply even if the final go ahead is not given.