web notes - a blog

Most web companies have very high speed Internet connections. This may improve productivity for those that develop on remote, publicly accessible servers, but it can also prevent the development team from appreciating the impact of the design and front-end coding on the site performance for the majority of site visitors.

The easiest way to determine the estimated download time is to use YSlow. Take the number of bytes required to display an uncached page (or unprimed cache) and divide it by the estimated connection speeds. http://websiteoptimization.com is an excellent resource, because it calculates page load/display time for you, as well as illustrating all the page components. It may be affected by caching, so review the report carefully. You can use Google analytics (or any similar service) to see the connection speeds.

Low-tech methods include allowing employees to work from home. DSL is one of the very common access methods, and will show performance issues much better than cable or other very-high-speed paths.

The above link can also be used to understand the time required for the page load and display process.

The link above is a link to Secunia, which tracks security issues for many products.

Interpreting the data is definitely subjective, for the following reasons:

• If an application is constantly being tested and reviewed for security issues, problems will be found more quickly.
• Applications with reports of many issues may simply be tested better than others.
• Applications which are very popular will also have a greater presence, as this implies greater testing.
• Development teams that are very concientious and report issues frequently will cause a greater quantity of reports than more reserved teams.
• Development teams that refrain from reporting security issues may consider that a valid approach, by reducing the information available for malicious users.
• Some applications have fundamental issues that make them more vulnerable than others.

After reviewing the reports for an application, there are several courses of action.

• Check if the application has been compromised on your server. Immediately apply any recommended upgrades or patches.
• Review the application documentation and the site/forum for additional tips on securing the application.
• Review any appropriate server security practices.
• Determine the value of any data or content involved, with an eye toward the cost of replacement or porting to a different application. Be sure to include the cost of training, learning curve (both for users and developers), administration issues, etc.
• Consider a web application firewall such as mod_security (http://modsecurity.org).
• If you have sensitive data or ecommerce, consider a hosted solution.
• Repeat

An application that can power multiple sites can greatly reduce maintenance.

Allowing users to run regular expression (REGEXP) searches through a web interface provides excellent search capabilities with very little engineering. One need only change WHERE `field`=’value’ to WHERE `field` REGEXP ‘regex’.

A problem arises if the regex entered is invalid. MySQL will report an error.

One solution that works well is to wrap the mysql_query string in a function or class method. Then, when testing for an error, check (use stristr) to see if the error was a regex error. Regex errors should be handled as user errors, not application errors. They should be logged to allow later analysis (if there are alot of regex errors, help should be provided).

Another approach is to use the PREPARE STATEMENT (see link above). This will throw an error if there are any invalid regexes.

Pay particular attention to the site visitor IP addresses in the web stats.

Any IP address that has a significant amount of requests for unknown reasons should be suspect.

Use the link above, or its overseas equivalent to determine who the IP address belongs to. If you don’t think they should be using your site heavily, use an .htaccess file to block them. Be sure to block the entire block reported by the whois system.

Apache allow,deny directives allow you to block requests: http://httpd.apache.org/docs/2.2/howto/access.html

These requests will show up as Forbidden in the stats later, and should eventually stop, since they aren’t being served.

In addition - if you are seeing alot of unexplained requests, from unknown sources, you should check your server for unauthorized content.

The following steps can be taken to make an existing eZ publish installation run more quickly:

• Empty the trash
• Clear the collected information
• Clear the search stats
• Delete all the drafts, especially those of the administrator

These steps remove unused information from the database and can really help the system run faster.