Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 117 Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 117 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 117 Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 117 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 117 Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 117 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 117 Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 117 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 117 Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 117 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 117 Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 117 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /ebs/sites/www/libraries/joomla/utilities/date.php on line 169 Blog Coeus Blue Managed Hosting, Load Testing, Consulting services, Magento Hosting, Cloud Hosting, Fry OCP, Open Commerce Platform, J2EE Hosting, Tomcat Hosting http://www.coeusblue.com/blog Sun, 19 Nov 2017 21:46:21 +0000 Joomla! 1.5 - Open Source Content Management en-gb Broken USPS international shipping in Magento http://www.coeusblue.com/blog/48-magento/74-uspsapi http://www.coeusblue.com/blog/48-magento/74-uspsapi Last night when USPS updated their API they opted to change the method names used in the API again. The result of this is that First Class for international no longer shows up for Magento sites using their API. To fix this and reenable international first class you just have to add the text "First-Class Package International Service" to the file app/code/core/Mage/Usa/etc/config.xml in 2 places around line 188 in recent versions. The 2 sections are and . Both are comma separated. Once you add it there and clear your cache you can go into admin, in the config section under shipping methods. Go to the USPS section and the new shipping method will appear in the allowed methods lists. Select it, save, clear your cache and you should be back in business.

]]>
info@coeusblue.com (Matt @ Coeus Blue) Magento Sun, 27 Jan 2013 15:04:28 +0000
Amazon EC2 outage, not for us http://www.coeusblue.com/blog/47-cloud-hosting/70-amazon-ec2-outage-not-for-us http://www.coeusblue.com/blog/47-cloud-hosting/70-amazon-ec2-outage-not-for-us

While sites like Reddit and Foursquare experienced nearly a day of downtime and are still having issues; our hosting clients experienced a total of 11 minutes of downtime related to the Amazon issues. There was an additional 15 minutes of total downtime in the middle of the night while engineers worked to ensure continued stability in the midst of hardware failures.  The site in question had only a single database server, no sites with a pair of replicated database servers experienced any downtime at all.

Enterprise levels of uptime and performance come from the design and support not the hardware.  The system within Amazon at the heart of the failures has been their network virtual disk product, EBS.  The sites which experienced substantial downtime all utilized that storage for the main hard drives of their systems without the use of RAID.  This is poor design having nothing to do with the cloud, because it puts a single point of failure across your environment.

Our environment assumes every system will fail at some point and works to mitigate that as much as possible.  We do utilize the EBS product, but we do so only in the context of RAID and do not use it for the operating system or core services of the machine.  The machines in our enterprise systems do not share any single points of failure, and the loss of one or more machines or even full availability zones is does not pose major problems.
Failures of this nature are going to happen.  I dont care if you host on Amazon, Rackspace, Microsoft, a traditional datacenter or the server under your desk, failures happen.  Core routers die, backhoes cut cables, systems guaranteed to always be up go down.  The key is to design your environment to have ways to deal with every possibility you can think of, and engineers with the experience and creativity to deal with the other million things you didn't.

 

]]>
info@coeusblue.com (Matt @ Coeus Blue) Cloud hosting Fri, 22 Apr 2011 13:43:12 +0000
Nginx for Magento Multisite http://www.coeusblue.com/blog/48-magento/68-nginxmagentomultisite http://www.coeusblue.com/blog/48-magento/68-nginxmagentomultisite I have been receiving some questions lately about multi site configuration when using nginx.  Normally there are a pair of variables set using apache's SetEnv in the .htaccess file not supported or used by nginx.  This method works for both Magento Community and Magento Enterprise.

The configuration overview found at MagentoCommerce is a reasonable start for single site configuration but punts on the multi site configuration question.  They point out:

The “MAGE_RUN_CODE” and “MAGE_RUN_TYPE” are for multi-store installations, each DOMAIN that represents a store should have that store code instead of “default” (line #53).

but not what needs to be done with it.  You could duplicate your configuration for each store code, but the easier way to deal with the store code is to build a map on it and switch on that map in the configuration.

 

 map $http_host $magesite { 
  www.site1.com site1storecode.com;
  www.site2.com site2storecode;
}
 server {
   <snip>
    location / {
                       
     if ($request_uri ~* "\.(ico|css|js|gif|jpe?g|png)$") {
      access_log   off;
      expires max;
     }

     try_files $uri $uri/ @magento;
     fastcgi_param  MAGE_RUN_TYPE  store;
     fastcgi_param MAGE_RUN_CODE $magesite;
     include fastcgi_params;
     fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
     fastcgi_param HTTPS $fastcgi_https;
     fastcgi_pass fastcgiUpstreamProvider;
}
   location @magento {

    # set expire headers
    if ($request_uri ~* "\.(ico|css|js|gif|jpe?g|png)$") {
     access_log   off;
     expires max;
    }

    include fastcgi_params;
    fastcgi_param MAGE_RUN_TYPE  store;
    fastcgi_param MAGE_RUN_CODE $magesite;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
    fastcgi_param SCRIPT_NAME /index.php;
    fastcgi_param HTTPS $fastcgi_https;
    fastcgi_pass fastcgiUpstreamProvider;
   }
}

Another common question is how to avoid duplication of configuration for secure and insecure site sections.  In the above configuration the sections in the location blocks which specify fastcgi_param HTTPS $fastcgi_https; let fastcgi know if secure is on or not. Using those and switching on the scheme with:

       map $scheme $fastcgi_https {
            default off;
            https on;
        }

You can combine the http and https sections.  This change does require a recent version of nginx, at least newer than the version in the centOS base repo as I am writing this.   In the server section just modify your listen lines to be:

                listen       80;
                listen  443  default  ssl; 

and add the normal ssl_ configuration to the server block.  This saves you from having to duplicate much of your configuration. This technique can grant you more control of other things as well.  For many of our clients we switch the fastcgi_pass paramater to let us split out admin functions and front end functions.  You can then push the timeouts and resource limits for admin to the levels they need to be for large jobs without allowing the front end site to over tax your servers.

 

 

]]>
info@coeusblue.com (Matt @ Coeus Blue) Magento Sun, 23 Jan 2011 17:37:51 +0000
Dynamic Infrastructure Scaling – AKA Auto-Scaling http://www.coeusblue.com/blog/47-cloud-hosting/66-dynamicinfrastructurescaling http://www.coeusblue.com/blog/47-cloud-hosting/66-dynamicinfrastructurescaling Cloud computing represents a major leap forward in enterprise application hosting. In the past, hosting a profitable e-commerce web site required substantial capital investment in hardware that sat idle more often than it was utilized serving content to customers. We developed something called dynamic infrastructure scaling to eliminate that waste and expense. As traffic to a site increases and additional capacity is required, more servers are brought online to meet the demand. As load subsides, servers are ramped back down. We call it auto-scaling and believe it can save online retailers money without affecting customer experience. Why? Because the site gets the capacity it needs for busy days and record- breaking holiday sales, and an inexpensive portion of that capacity at off-peak times.


How does auto-scaling work?


Once we understand the particular needs of an online business, we analyze the information gathered by our advanced monitoring suite with run time automatic server configuration. With that in hand, our engineers design a set of rules that control how and when servers are added to or subtracted from the farm. Because the servers are not physical hardware, but instead designed as a configuration and image combination for an individual business, additional servers can be added in minutes.

Auto-scaling that fits your business


The big providers have auto-scaling features but they differ from our Dynamic Infrastructure Scaling. Solutions from big providers require a lot of configuration to instruct the service how to start a server, rules telling it which metric to monitor, and an action to take when the rules violate an established threshold. We’ve found three problems with this method.

First, the complexity of the configuration itself; subtle mistakes can to often result in a configuration that doesn’t work at all, or even worse launches more or fewer instances than you intend. At Coeus Blue, we manage the complexity of the configuration for our clients.

What if your business logic doesn’t lend itself to the rules the interface allows? For example, if you< have a back end system in your office experiencing problems, adding more web servers that place load on that system will make things worse. By working with many clients over the years, we have developed tools with flexibility built in to work with the business, rather than against it. We design logic based on our clients’ business specs.  

The third problem occurs when load subsides and servers ramp down. Determining when traffic levels can safely be handled by fewer servers requires historical data, not just monitoring alone. Shutting down servers without affecting customers who are trying to checkout, requires more than just turning the instance off. We designed an auto-scaling solution to address both concerns. Our shutdown logic evaluates the site infrastructure's current metrics, as well as trend data to make recommendations. That trend-based logic, combined with advanced load balancing techniques enables us to determine the optimal time to remove a server, and prevent any impact to site customers.

Do we fit your business? Let’s find out.



As a managed service hosting provider we give our clients a turnkey solution that keeps their web sites working. Yes, you can find a vendor with the tools that allow you to build cloud instances, add and remove servers, even automate some of these tasks. The difference? We don’t believe in just providing busy business owners with a set of tools.

We provide a fully functional, fully supported, dynamically scaling web hosting solution. There’s no need for your staff to learn the tools. There is no reason for you to suffer through the headaches and ‘gotchas’. Patching, backups, security? We do it. Launching a new product with a big marketing push? No problem. Unlike other providers, there’s no complicated documentation to read, no counter-intuitive interface to learn. When you need something changed you call, speak with a skilled engineer who takes care of it for you, and quickly get back to running your business.

There’s a big difference between tech support and engineering. We understand that when you need site help, you need an engineer; a call to tech support is not enough. If this sounds like the kind of help your business can use, call me at 866.847.8171

]]>
info@coeusblue.com (Matt @ Coeus Blue) Cloud hosting Tue, 16 Nov 2010 00:31:36 +0000
Very fast magento caching with apc and memcached http://www.coeusblue.com/blog/48-magento/65-magento-caching http://www.coeusblue.com/blog/48-magento/65-magento-caching There is no single documentation regarding Magento's caching options in the local.xml and many of the posts that do exist today have not been updated in some time.  We have had a great deal of success using this in a no disk cache configuration.

<config>
<global>
<SNIP OUT INSTALL DETAILS ETC>
<cache>
<backend>Apc</backend>
<slow_backend>Memcached</slow_backend>
<fast_backend>Apc</fast_backend>
<slow_backend_options>
<servers><!-- The code supports using more than 1 server but it seems to hurt performance -->
<server>
<host><![CDATA[127.0.0.1]]></host>
<port><![CDATA[11211]]></port>
<persistent><![CDATA[1]]></persistent>
</server>
</servers>
<compression><![CDATA[]]></compression>
<cache_dir><![CDATA[]]></cache_dir>
<hashed_directory_level><![CDATA[]]></hashed_directory_level>
<hashed_directory_umask><![CDATA[]]></hashed_directory_umask>
<file_name_prefix><![CDATA[]]></file_name_prefix>
</slow_backend_options>

<memcached>
<servers>
<server>
<host><![CDATA[127.0.0.1]]></host>
<port><![CDATA[11211]]></port>
<persistent><![CDATA[1]]></persistent>
</server>
</servers>
<compression><![CDATA[]]></compression>
<cache_dir><![CDATA[]]></cache_dir>
<hashed_directory_level><![CDATA[]]></hashed_directory_level>
<hashed_directory_umask><![CDATA[]]></hashed_directory_umask>
<file_name_prefix><![CDATA[]]></file_name_prefix>
</memcached>
</cache>
<SNIP OUT RESOURCES SECTION>

</global>
<SNIP OUT ADMIN CONFIG SECTION>
</config>

A busy site will use a few hundred meg of APC cache and less than 100 meg of memcached cache.  At very high traffic levels memcache cannot keep up as the fast backend which is why this 2 tier method is being used.

This has been tested fairly heavily using nginx and php-fpm (both the 5.2 with patch and 5.3 native). You will need to use shared memory in apc to see the most gain.

If you have any questions or problems please feel free to post them.

 

]]>
info@coeusblue.com (Matt @ Coeus Blue) Magento Sat, 13 Nov 2010 19:35:55 +0000
What is the Cloud http://www.coeusblue.com/blog/47-cloud-hosting/63-blogwhatisthecloud http://www.coeusblue.com/blog/47-cloud-hosting/63-blogwhatisthecloud  

It is all you hear about any more. The term cloud is thrown around so often and in so many contexts what it actually means seems to be getting lost. I even hear people use the term synonymously with the internet itself. Cloud computing and mobile seem to have completely taken over the industry media yet most people don't seem comfortable with the terms and ideas. This is quite simply the most important thing to happen to online retail since the wide spread adoption of broadband. Social media has been the big buzz for a long time, but how much actual profit have you been able to trace back to that twitter account? The cloud can save you real money, real time, and when that big break comes it can save your butt. It is vital to your business to take the time to get to know this technology.

 

So, what is the cloud? What is cloud hosting? At a high level the cloud has come to mean a pool of infrastructure, providing services into a pool, usable by collection of virtual servers or applications. Clear as mud, no? Lets try that again.

 

The cloud is just plumbing. With traditional hosting you are buying a bottle of water. With cloud hosting you are having city water installed with a tap in your kitchen. You know, in the back of your mind, it is far more complicated than opening the bottle but when done correctly that complexity is hidden from you. You pay for what you use, and can use all you need. The confusion in the term tends to come from the thousands or millions of possible ways this could be implemented. There are some general trends forming but the rate of growth in the technology and ideas is exactly what is driving the excitement in this space.

 

Types of Clouds

 

The first distinction that can be made is between public and private clouds. Private clouds are exactly what they sound like. Private corporate networks that have extra capacity and may offer themselves as service providers. These clouds can be more inexpensive than public clouds but do not generally have the size that that provides the main advantage. Public clouds are those provided by the largest players in the market such as Google, Amazon and Microsoft and made available via various lease programs to the public. These are the clouds that are revolutionizing ecommerce.

 

The next level of grouping that can be made is between virtual server or abstracted application style clouds. The abstracted application style services such as Google's App Engine are ideal for businesses with in house development staff who don't have the expertise to deal with the underlying infrastructure. As this model grows it will become a strong platform for medium sized ecommerce applications but the choices for robust enterprise site frame works are still limited.

 

In contrast, the virtual server model was all but designed just for ecommerce. Most services provide you with a simple image of one of their supported operating systems and let you work with it as you see fit. Amazon's EC2 service, for example, lets you use most Linux distributions, Microsoft Windows (including SQL Server) and they now even have images that can run Oracle with the licensing fees built into the instance costs. This means any of the major ecommerce, content management, database, or any other application software you already use can be run in the cloud. This type of service does require you to have staff or service providers who not only know the traditional administration skills to maintain the services and images but also the specific tools available for that cloud vendor.

 

This has only been a quick glace into what has become the tech industry buzz word of the moment, but hopefully I have clarified things enough that you can dig a bit deeper into how this technology can help your business get the most use out of your IT budget.

 

{jcomments on}

 

]]>
info@coeusblue.com (Matt @ Coeus Blue) Cloud hosting Sat, 09 Oct 2010 22:51:45 +0000