TYPO3 CMS
TYPO3 is a free Open Source content management system for enterprise purposes on the web and in intranets. It offers full flexibility and extendability while featuring an accomplished set of ready-made interfaces, functions and modules
The TYPO3 Association has released a new version of their very successful open source project. TYPO3 has been downloaded over 3.000.000 times from Sourceforge.org which makes it one of the World’s leading Enterprise Open Source products.
The main focus of the new 4.2 version is improving usability, but there are also many enhancements for system administrators and developers. Including bug fixes, there are nearly 650 enhancements in TYPO3 4.2.
Read more…
Discover Nucleus CMS
The Nucleus CMS core development team has released Nucleus CMS v3.41. This release fixes a bug in the configuration variables and has reordered English languages files to ease the translation. All changes can be found in the history of the included documentation (an online version can be found here).
There are no security updates in this release so that you have not to hurry up. But we recommend to update so that your blog software is up to date and work with all plugins.
Index Types
Filed under: Featured, MS SQL Server, MS SQL Server 2000, MS SQL Server 2005, MS SQL Server 2008, MySQL 5.1, MySql, MySql 5.0, Oracle
In addition to an index being clustered or nonclustered, it can be configured in other ways:
• Composite index: An index that contains more than one column. In both SQL Server 2005 and 2008, you can include up to 16 columns in an index, as long as the index doesn’t exceed the 900-byte limit. Both clustered and nonclustered indexes can be composite indexes.
• Unique Index: An index that ensures the uniqueness of each value in the indexed column. If the index is a composite, the uniqueness is enforced across the columns as a whole, not on the individual columns. For example, if you were to create an index on the FirstName and LastName columns in a table, the names together must be unique, but the individual names can be duplicated.
A unique index is automatically created when you define a primary key or unique constraint:
•
Primary key: When you define a primary key constraint on one or more columns, SQL Server automatically creates a unique, clustered index if a clustered index does not already exist on the table or view. However, you can override the default behavior and define a unique, nonclustered index on the primary key.
Unique: When you define a unique constraint, SQL Server automatically creates a unique, nonclustered index. You can specify that a unique clustered index be created if a clustered index does not already exist on the table.
• Covering index: A type of index that includes all the columns that are needed to process a particular query. For example, your query might retrieve the FirstName and LastName columns from a table, based on a value in the ContactID column. You can create a covering index that includes all three columns.
Index Design
As beneficial as indexes can be, they must be designed carefully. Because they can take up significant disk space, you don’t want to implement more indexes than necessary. In addition, indexes are automatically updated when the data rows themselves are updated, which can lead to additional overhead and can affect performance. As a result, index design should take into account a number of considerations.
Database
As mentioned above, indexes can enhance performance because they can provide a quick way for the query engine to find data. However, you must also take into account whether and how much you’re going to be inserting, updating, and deleting data. When you modify data, the indexes must also be modified to reflect the changed data, which can significantly affect performance. You should consider the following guidelines when planning your indexing strategy:
• For tables that are heavily updated, use as few columns as possible in the index, and don’t over-index the tables.
• If a table contains a lot of data but data modifications are low, use as many indexes as necessary to improve query performance. However, use indexes judiciously on small tables because the query engine might take longer to navigate the index than to perform a table scan.
• For clustered indexes, try to keep the length of the indexed columns as short as possible. Ideally, try to implement your clustered indexes on unique columns that do not permit null values. This is why the primary key is often used for the table’s clustered index, although query considerations should also be taken into account when determining which columns should participate in the clustered index.
• The uniqueness of values in a column affects index performance. In general, the more duplicate values you have in a column, the more poorly the index performs. On the other hand, the more unique each value, the better the performance. When possible, implement unique indexes.
• For composite indexes, take into consideration the order of the columns in the index definition. Columns that will be used in comparison expressions in the WHERE clause (such as WHERE FirstName = ‘Charlie’) should be listed first. Subsequent columns should be listed based on the uniqueness of their values, with the most unique listed first.
• You can also index computed columns if they meet certain requirements. For example, the expression used to generate the values must be deterministic (which means it always returns the same result for a specified set of inputs). For more details about indexing computed columns, see the topic “Creating Indexes on Computed Columns” in SQL Server Books Online.
Queries
Another consideration when setting up indexes is how the database will be queried. As mentioned above, you must take into account the frequency of data modifications. In addition, you should consider the following guidelines:
• Try to insert or modify as many rows as possible in a single statement, rather than using multiple queries.
• Create nonclustered indexes on columns used frequently in your statement’s predicates and join conditions.
• Consider indexing columns used in exact-match queries.
MailTo Syntax
MailTo Syntax
________________________________________
PLEASE NOTE:
• It is recommended that you use a process other than MailTo handle the e-mail process from your web site.
• If you do use MailTo, please encode the included e-mail address(s) to reduce the spam for that address.
One routine to assist encoding and e-mail address is available at: http://www.ianr.unl.edu/email/encode/
The MailTo command can do more than enter a single e-mail address in the “Send To” field while activating your e-mail program. It can also:
Feature Syntax
Address message to multiple recipients , (comma separating e-mail addresses)
Add entry in the “Subject” field subject=Subject Field Text
Add entry in the “Copy To” or “CC” field cc=id@internet.node
Add entry in the “Blind Copy To” or “BCC” field bcc=id@internet.node
Add entry in the “Body” field body=Your message here
Within the body use “%0A” for a new line,
use “%0A%0A” for a new line preceded by a blank line (paragraph),
see example below.
Notes:
” ” (beginning and ending double quotes) are necessary if any spaces are used
Mailto parameter should be preceded by “?” for the first or only parameter and “&” for second and subsequent parameter.
Some examples, with actual HTML Code included, follow:
Simple MailTo
MailTo with Multiple Recipients
MailTo with Subject
MailTo with a Copy
MailTo with a Blind Copy
MailTo with message already started in Body
MailTo with multiline message in Body
NOTE: Use “%0A” for a new line, use “%0A%0A” for a new line preceded by a blank line.
Features may be used in combination
MailTo with Subject, a Recipient, a Copy and a Blind Copy
Remember to use only one ? (question mark), when providing multiple entries beyond e-mail address
Understanding MySQL Query Cache for PHP Developers
Problem Statement:
Many PHP developers using MySQL have unclear understanding of the MySQL query cache. So we decided to write a series of introductory articles to get everyone on the same page. This article is the first installment of the series and here we will introduce the basics of query cache in MySQL. Note that unlike a typical book chapter, this article will be of low-fat flavor — less theory and more actionables — of an introduction to query caching for MySQL.
What is a MySQL query cache?
It turns out that MySQL has a built-in query cache that can cache a specific type of queries — SELECT statements — to speed up delivery of the result sets. The cache can increase performance for many instances but can also hurt performance if not used wisely.
What can be cached in the MySQL query cache?
Only SELECT statements can be cached. This does not include prepared SELECT statements. Query caching only works for SELECT statements that are fully qualified and returns same result every time. This means you cannot use non deterministic functions that return data depending on situation. For example:
// Following SELECT query can be cached
$stmt = “SELECT * FROM user WHERE active = 1″;
// Following SELECT query cannot be cached
$stmt = “SELECT * FROM user where signup_date >= NOW()”;
// Following SELECT query cannot be cached
$stmt = “SELECT count(*) FROM user”;
Here are the requirements a query must meet to take advantage of the query cache:
• Only exact queries are serviced from the cache — must match the stored query in exact detail.
• Queries with placeholders — such as the ones for prepared statements — are not cached in query cache
• Queries with user defined functions or non-deterministic functions cannot be cached
• Any table changes (such as issuing of an ALTER statement) will remove the queries from the cache for that table
Introduction to query cache parameters
The more you understand the query caching parameters, the better you are going to be at tuning the query cache to your advantage. First find out what are the global query caching parameters that you can fiddle with using the following query at the mysql command-line prompt.
mysql> show global variables like ‘%query_cache%’;
A sample output is shown below:
+——————————+———–+
| Variable_name | Value |
+——————————+———–+
| have_query_cache | YES |
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 536870912 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
+——————————+———–+
6 rows in set (0.00 sec)
The purpose of these parameters are described briefly as:
• have_query_cache – size of query cache in bytes
• query_cache_limit – the maximum size of result set (default: 1048576 bytes or 1 MB). If your query returns result set that is greater than the limit set here, it will NOT BE CACHED
• query_cache_min_res_unit – the smallest block size allocated by query cache. Default is 4KB
• query_cache_size – the total memory available to query cache
• query_cache_type – when set to ON or 1, query caching is on for all applicable queries, when set to OFF (0) query caching is turned off and when set to DEMAND or 2, caching is on for queries with SQL_CACHE directive in the query
• query_cache_wlock_invalidate-causes the query cache to invalidate any query in the cache if a write lock is executed against the table(s) it uses
Whats your query cache status right now?
To find out whats going on with your query cache, run the following command from the MySQL command-line prompt:
mysql> show status like ‘%qc%’;
Here is a sample result:
+————————-+———–+
| Variable_name | Value |
+————————-+———–+
| Qcache_free_blocks | 978 |
| Qcache_free_memory | 527371984 |
| Qcache_hits | 645545 |
| Qcache_inserts | 130796 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 417579 |
| Qcache_queries_in_cache | 4973 |
| Qcache_total_blocks | 11167 |
+————————-+———–+
8 rows in set (0.00 sec)
Here are some brief explanations of these status metrics:
• Qcache_free_blocks – number of memory blocks marked as free, which indicates memory fragmentation
• Qcache_free_memory – total amount of memory free for query cache
• Qcache_hits – number of times query result was found in the query cache
• Qcache_inserts – number of times queries were written to the query cache
• Qcache_not_cached – number of queries removed from cache due to low cache memory
• Qcache_queries_in_cache – number of queries that could not be cached
• Qcache_total_block – total number of blocsk in query cache
Calculating query cache hits vs misses
Here is the formula for calculating hit ratio for query cache:
$totalSelectQueryCount = $comSelect + $qcacheHits
$percentHits = ($qcacheHits * 100)/ $totalSelectQueryCount
What the above formula does is adds up all the SELECT queries in the system using two MySQL global variables: com_select and qcache_hits.
To set $comSelect, run show global status like ‘%com_select%’ query. For example:
mysql> show global status like ‘%com_select%’;
+—————+———+
| Variable_name | Value |
+—————+———+
| Com_select | 1739663 |
+—————+———+
To set $qcacheHits, run show status like ‘%qcache_hit%’. For example:
mysql> show status like ‘%qcache_hit%’;
+—————+———-+
| Variable_name | Value |
+—————+———-+
| Qcache_hits | 20786961 |
+—————+———-+
With the above sample number, the percent hit is 92.28% which is great.
Managing query cache
To manipulate your query cache, you can use the following MySQL statements from the MySQL command-line:
To remove all the queries from your query cache, run:
RESET QUERY CACHE;
To defragment the query cache memory, run:
FLUSH QUERY CACHE;
MySQL Crash Recovery
MySQL Crash Recovery
MySQL is known for its stability but as any other application it has bugs so it may crash sometime. Also operation system may be flawed, hardware has problems or simply power can go down which all mean similar things – MySQL Shutdown is unexpected and there could be various inconsistences. And this is not only problem as we’ll see.
MySQL has angel process mysqld_safe which will restart MySQL Server in most cases. It is great, unless you have run into some bug which causes it to crash again – such crashes qucikly following one another are kind of worse because they explore many less tested code paths in MySQL and so problem potential is larger.
So lets look at the problem which happen during the crash which might need to take care of or which may seriously affect MySQL Performance.
MyISAM Corruption – If you’re writing to MyISAM tables there is very large chance of them becoming corrupted during the crash. Note corruption may be hidden and do not expose itself instantly – you may notice wrong query results days after crash. Sometimes corrupted tables may be reason for further crashes or hangs, and corruption may spread itself further in the table. You probably do not want any of these so it is very good idea to run MySQL with myisam_recover option which will make sure all improperly closed MyISAM tables are checked first time it is accessed. This option is however rather painful to use with web applications – users may issue different queries which may trigger check/repair running for many tables at onces, which typically make system extremely slow and also can use up all allowed connections or run out of memory ( myisam_sort_buffer_size is normally set pretty lage). If this becomes the problem I use tiny script which moves out all MyISAM tables out of MySQL database directory, checks them with MyISAMchk and moves them back to running server. This looks scary but it works great – until table is checked and ready application gets error rather than stalling forever which allows application to become partially functional as soon as possible. This hack is needed only in some cases – in most cases using Innodb for tables which you need to be recovered fast is better solution.
Innodb Recovery – Unless you have some hardware problems (99%) or found new Innodb bug (1%) Innodb recovery should be automatic and bring your database to consistent state. Depending on innodb_flush_lot_at_trx_commit setting you may lose few last committed transactions but it is it. It is Performance of this process which may cause the problems. As I already wrote innodb_log_file_size and innodb_buffer_pool_size affect recovery time significantly as well as your workload. I should also mention if you have innodb_file_per_table=1 your recovery speed will depend on number of Innodb tables you have, as well as many other operations, so beware.
Binary log corruption – Binary log may become corrupted and out of sync with database content. This will sometimes break replication but if you’re just planning on using binary log for point in time recovery it can go unnoticed. sync_binlog Is helping by syncing binary log, but at performance penalty. If using Innodb you also might with to use innodb-safe-binlog option in MySQL 4.1 so your Innodb log and binary log are synchronized. In MySQL 5.0 XA is taking care of this synchronization.
.frm Corruption – Few people know MySQL is not really ACID even with Innodb tables, at least not for DDL statements.
There is a chance of failing for example during CREATE statement with table created in Innodb dictionary but .frm not created or not completely written. Partially written .frm files or .frm being unsync with internal Innodb dictionary may cause MySQL to fail with wierd error messages. In MySQL 4.1 sync_frm option was added which reduces this problem as time window when it can happen is much less. Still if failure happens just during writting .frm file nasty things may happen, not to mention such potentially multiple operation DDL statements as RENAME TABLE – these are most vulnerable.
master.info corruption – If slave happens to crash you can also have relay logs corruption and master.info being corrupted. Not to mention MyISAM tables can contain partially completed statements as well as some of updates totally lost. The safe approach it to reclone the slaves if they crash or you can take the risks and try to continue. Sometimes you might be able to manually find appropriate position even if master.info file is out of sync but I would not be basing my failure handling scenarios.
Cold Start – If you restart MySQL server its caches (key_buffer, innodb_buffer_pool, query_cache,table_cache) are cleaned, so may be OS caches. This may reduce performance dramatically. So if you’re bringing server back after crash you might want to populate caches. For MyISAM key_cache this can be done by using LOAD INDEX INTO CACHE statement, for other storage engines it can be done by issuing large index scan queries. Full table scan queries allow to preload table data ether in storage engine caches or in OS cache. You can save these into .sql file and use –init-file to make sure it is run on startup. The other approach is to prime server with real servers (ie clone queries from other slave) before putting traffic to it.
In case application is not highly available so there is only one server you might with to start serving only some users initially (returning error to others) and gradually increase the load as server warms up. This may sound strange but makes a lot of sense as not only waiting for pages which never load is more frustrating for users than getting honest “try again later” message, but also – warmup takes longer time on extreme load.
Innodb statistics – Unlike MyISAM Innodb does not store index cardinality in tables, instead it computes them on first table access after startup. This may take significant time if you have very large number of tables (Some users have hundreds of thousands of tables per database host). This one is pretty much part of cold start problems but I wanted to point out it separately. To warmup this data you might run select 1 from _table_ limit 1 for each table or any other statement – it is table open which is important.
There are other problems which you may experience related to MySQL Crash Recovery – Restoring data from backup, corrupted Innodb tablespace recovery etc but I should write about them some other time.
Reference by : http://www.mysqlperformanceblog.com/2006/07/30/mysql-crash-recovery/
On the Road with the Google Maps API
In the previous installment of this occasional series discussing the Google Maps API, we used the API and a PHP library named GoogleMapAPI to plot and calculate a route along a map. Uses for such a feature are many, among them determining distance as the crow flies between two points, and even a quick gauge for figuring the length of a simple jogging or bicycling route. However, although useful, the limitations of such a feature quickly become apparent when the need arises to calculate the distance of a more complex route. Or what if you needed to chart a much longer route, such as one which would take the user from Columbus, Ohio to Cleveland, Ohio? For instance, charting the route as accurately as shown in Figure 1 would likely prove fairly tedious using this approach.
Figure 1. Charting a complex route
Thankfully, the Google Maps API offers a feature which can greatly reduce the work involved in creating complex routes such as this. In fact, you’ll be able to use this feature to create a complex multi-point route simply by clicking on your starting and concluding points, letting the API plot what it deems to be the most direct route. Sounds cool, doesn’t it? In this tutorial I’ll show you how to implement this feature into your website, and perform other tasks such as determining the distance of the route, and even displaying route directions such as those available at http://maps.google.com/.
Snapping Points to a Route
The first thing we’ll need to figure out is how the API will plot a route along the known roads and other byways. This is accomplished using the loadFromWaypoints() method, which will accept an array of up to 25 coordinates (or alternatively addresses, and even a mix of the two), and then work out the route which connects these points. The following function will add a marker to the map, and append the marker’s coordinates to an array named coordinates (defined in the typical initialize() function). If the coordinates array ever consists of more than one set of coordinates, the loadFromWaypoints() method is called, resulting in a route between the coordinates being drawn.
function plotRoute(overlay, latlng) {
// Create a new marker based on the coordinates
var marker = new GMarker(latlng);
// Instantiate the GDirections class
var directions = new GDirections(map);
// Add the new marker to the map
map.addOverlay(marker);
// Create the new array element
coordinates_array_element = latlng.lat() + “,” + latlng.lng();
// Add the new array element to the map
coordinates.push(coordinates_array_element);
// If > one point on the map, plot the route between these two points
if (coordinates.length > 1) {
directions.loadFromWaypoints(coordinates);
}
}
As was demonstrated in the previous article, to execute a function when the user clicks on a map, just attach a listener to the map, as is shown below. I’ve placed this call in the initialize() function. If you don’t know what purpose the initialize() function serves, be sure to consult earlier articles in this series.
GEvent.addListener(map, “click”, plotRoute);
Avoiding Highways
The route plotted between Columbus and Cleveland logically guided the user along one of the state’s major highways, namely I-71. But what if you were planning a marathon bicycle ride between Columbus and Cleveland? You can tell the API to avoid using highways by modifying the loadFromWaypoints() method call like so:
directions.loadFromWaypoints(coordinates, {”avoidHighways”: true});
Once in place, reload the map and again plot the points between Columbus and Cleveland. You’ll notice the outbound route from Columbus avoids using I-71, as shown in Figure 2.
Figure 2. Avoiding highways along the route
You can pass along other properties as well, including one (locale)for changing the map locale, and another (preserveViewport) which will zoom the map to an appropriate level in order to ensure the entire route appears within the map viewport. Consult the API documentation for a complete list of available properties.
Calculating the Route Distance and Trip Duration
You can also easily determine the distance and estimated travel time using the GDirection class’ getDistance() and getDuration()methods, respectively. However, because these values are not returned until the loadFromWaypoints() method returns the route, you’ll need to use a listener to retrieve the values at the appropriate time. For instance, the following listener waits for the directions object to load. Once loaded, the duration is retrieved, converted into minutes, and updated within a div named duration placed somewhere within the web page.
GEvent.addListener(directions, “load”, function() {
var duration = (directions.getDuration().seconds / 60).toFixed(2);
document.getElementById(”duration”).innerHTML = duration +
” minutes to arrive at your destination.”;
});
Figure 3. Displaying the estimated travel time
Displaying Route Directions
Sometimes you might wish to provide the user with directions from one point to the next. Adding this feature is shockingly easy; just modify your call to the GDirections object to identify the div where the directions should be inserted, like so:
var directions = new GDirections(map, document.getElementById(”sidebar”));
After adding the sidebar div to your web page, you’ll be able to create interfaces such as that shown in Figure 4.
Figure 3. Displaying the estimated travel time
Conclusion
This and the previous article present you with two easy ways to determine distance between multiple points on a map, whether its as the crow flies or as somebody might travel along an established roadway. If you wind up doing anything interesting with these features, I’d love to hear about it!
2 May 8 Popular Open Source Forums
* – phpBB is one of the most popular forum softwares. With phpBB you can customize with mods and you can stylize your forum. For a fully Modded phpBB forum with about 500 different mods that all have been fully tested click here.
* – Vanilla is a lightweight open source forum that was developed by Mark O’Sullivan using PHP and MySQL. Vanilla comes loaded with extensions, and you can customize the forum with your own add-ons.
* – YetAnotherForum.NET is a Open Source forum or bulletin board for web sites running ASP.NET. YetAnotherForum.NET is fully coded in C# ASP.Net and uses Microsoft SQL Server. It comes with all the standard forum features and even WYSIWYG editors.
* – YaBB is an Open Source forum system (bulletin board, message board) written in Perl. This system is the first and most popular open-source perl forum software and it runs very fast.
* – IceBB is an open-source forum solution powered by PHP and MySQL. IceBB is written with the prototype and scriptaculous frameworks and the code output is very clean. IceBB has mostly all the same features as some of the paid forums but it even has an RSS feed.
* – WP-Forum is a simple discussion forum plugin for WordPress. It has three themes that you can choose from and is a simple solution if you have a WordPress powered site.
* – miniBB is an open source message board script written in PHP. miniBB is a lightweight and compact alternative to phpBB. With miniBB you can customize the software with add-ons and it is Search Engine Optimized.
* – SMF is a free professional grade forum software that actually isn’t open source. SMF has loads of features with a great community and tons of free modifications.
If you know of any more Open Source Forums then please comment below. Thanks!!!
Popularity: 100%
Configuring Apache2.2 mod_proxy_ajp with Tomcat
mod_proxy_ajp is an Apache module which can be used to forward a client HTTP request to an internal Tomcat application server using the AJP protocol. In this example I have used JSPWki as the example application running on a Windows server with Apache2.2 and Tomcat 5.5
Advantages of mod_proxy_ajp rather:
- You can gain a lot of flexibility (lot of the apache modules/features can be used especially “name-based virtual hosting”)
- Practical for those who need to support Java applications along with PHP / Perl … (only one apache server is needed)
- Certificates management is easier in apache configuration (this argument is a lot subjective)
- It’s not Tomcat’s main objective to serve http static resources (not optimized for that)
- Load balancing/cluster management is easier with an apache frontend
Tomcat configuration
We just have to create the AJP connector in the conf/server.xml file like that:
<Connector port="8009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
This line will enable AJP connections to the 8009 port of your tomcat server (localhost for example).
Apache2 configuration
One way (useful if this apache is a global front end) is to create a virtual host for this application.
ProxyPassandProxyPassReverseare classic reverse proxy directives used to forward the stream to another location.ajp://…is the AJP connector location (your tomcat’s server host/port)
# JSP Wiki DNS
<VirtualHost 10.1.1.170:80>
ServerName wiki.example.com
ServerAlias wiki
DocumentRoot “D:/Tomcat 5.5/webapps/JSPWiki/”
#DocumentRoot “D:/Apache2.2/htdocs/JSPWiki”
<Proxy *>
AddDefaultCharset Off
Order deny,allow
Allow from all
</Proxy>
ProxyPass / ajp://localhost:8009/
ProxyPassReverse / ajp://localhost:8009/
</VirtualHost>
The following entries were made in server.xml on the Tomcat App Server :
<Host name=”wiki.example.com” debug=”0″
appBase=”D:/Tomcat 5.5/webapps”
unpackWARs=”true” autoDeploy=”true”>
<Alias>wiki</Alias>
<Context path= “” docBase=”D:/Tomcat 5.5/webapps/JSPWiki” debug=”1″/>
<Valve className=”org.apache.catalina.valves.AccessLogValve”
directory=”logs” prefix=”home_access_log.” suffix=”.txt”
pattern=”common” resolveHosts=”false”/>
</Host>
Under JSPWiki/WEB-INF/jspwiki.properties the Base URL was modified as follows :
jspwiki.baseURL=http://wiki/JSPWiki/
Follow Us
Earn a Dollar daily
