Notice: register_sidebar was called incorrectly. No id was set in the arguments array for the "Sidebar 1" sidebar. Defaulting to "sidebar-1". Manually set the id to "sidebar-1" to silence this notice and keep existing sidebar content. Please see Debugging in WordPress for more information. (This message was added in version 4.2.0.) in /usr/share/wordpress/wp-includes/functions.php on line 4139 Tech Notes » 2011 » December

iPhone 4s and iPhone4 Physical Case Differences

Uncategorized No Comments »

After some false-starts on iPhone cases (burned off my previous one, and i kinda don’t miss it), I wanted to post a quick note pointing others to a detailed description of some key differences.

iCollectGadgets shows a few great photos, but the key is in the following two (with permission, I’m willing to host a copy of these on my site to reduce any bandwidth-stealing):

Button Alignment:

Earbud 3.5mm Socket:

I would strongly recommend checking out the original site:

Battery Life: non-optimal

Uncategorized No Comments »

Teo phones taken from chargers this morning at 8:00: the latest HTC Android, and an iPhone 4, not a 4S. The iOS device has all manner of 3G, wifi, location services activated, the HTC perhaps the same.

IPhone is 80% battery, HTC is 57%. Sure, optimal conditions rate the content the other way, but we all know our wifi access points will hit 300 feet / 100meters range in an optimal situation: real life differs, and for my usage, HTC with MAYBE the same services active is burning battery twice as quickly.

Not sure Android is winning yet.

ConfirmEdit Nailed my WikiMedia

Uncategorized No Comments »

So I suddenly saw this:

Fatal error: Call to undefined method WebRequest::getIP() in extensions/ConfirmEdit/Captcha.php on line 202

Apparently, this is due to rev 106097, which replaced wfGetIP() with a wgRequest->getIP() that doesn’t exist. Maybe it’s in Yesterday’s version of WikiMedia only. 🙁

My fix:
cd extensions/ConfirmEdit
svn update -r 106096

I’m putting this blog entry so that others may see it and make use of it.

Avoid MATCHES in Filters

Best Practices, VirtualWisdom No Comments »

Where possible, try to avoid using “MATCHES” expressions in Filters that are evaluated often; one suggestion is to move them to UDCs, but it’s not necessarily a constant rule.

I’ve used a few terms in that one-line suggestion, perhaps I can expand on this a bit.

VirtualWisdom lets you make filter expressions such as:

Attached Port Name MATCHES ^OracleServer_*

This powerful logic lets you leverage similar names and terms to select similar servers. Consider selecting similar storage targets or hosts by parts of names, or FCIDs that start or end in the same sequence, or switches using the word “Core” or “Edge” in its role. In fact, a simple filter applied to an alarm can apply a more urgent reaction to a port with errors on a core switch rather than an edge, representing different SLAs or criticality.

The example above says “look for where the Attached Port Name — the nickname of the device attached to a switch — starts with ‘OracleServer_’ “.

UDC — User-Defined Context — allows a VirtualWisdom Administrator to define an additional metric in terms of filter expressions: when various conditions match, a constant enumeration is used for that port’s value, or that ITL’s encoding. For example, for switches with certain names, a “DataCenter” column can identify where that switch is to help forward physical layer errors (such as CRCs) to the right team to more quickly address the issue. Different storage or servers involved in different business units can be enumerated, and based on that “BU” flag or value, different SLAs may be applied, or different teams alerted. UDCs are quite powerful, and are processed on every summary that gets stored in the database.

UDCs can use the same “MATCHES” terms that standard filters can use.

The problem with MATCHES is that it strips away some optimization: the Query Optimizer is a part of a database that cross-references the client’s query with existing possible indices, even aggregate indices, to reduce the processing load by orders of magnitude. Any Oracle Admin who has spent time with the “SQL EXPLAIN” has seen the difference a simple re-ordering of expressions can make in a complex query to get a more efficient join, or fewer rows evaluated for processing to reach a result. These indices only match constant expressions with basic comparison operators such as “==”, “!=”, ““, and are completely inefficient for fuzzy or regular-expression matches.

A “MATCHES” expression in your filter or UDC can increase the load between a VirtualWisdom Portal Server and the underlying MySQL database engine. Although Virtual Instruments Engineering has worked to improve the database schema and queries, resulting in dramatic improvements in processing efficiency and maximum ITL and port count of a Portal Server, we the users still have the power to ruin this with a heavy expression or two.

If a filter isn’t run very often (such as a private dashboard, or a filter used mostly in a daily report), it may not pose very much load on the database; conversely, for a filter that runs often, constantly, the load of a MATCHES expression can repeatedly affect the server for the same data points. It’s almost as though a cache of the resulting filter would avoid rerunning the comparison so often. That is where a UDC can be used.

For filter expressions that run often, consider moving the MATCHES to a UDC calculation, and convert the filter to a comparison against that precise value. For example, if your filter looks like:

Attached Port Name MATCHES BillingServer_* OR Attached Port Name MATCHES CustRecords_*

This can be converted to a UDC such as:

  • default value: “Other
  • value “Billing” when “Attached Port Name MATCHES BillingServer_*
  • value “Records” when “Attached Port Name MATCHES CustRecord_*

This sort of UDC means that the two MATCHES expressions will run twice on every Port or Exchange of every summary. If only Servers are identified by this pattern of nicknames, you could also avoid this sort of evaluation on non-Servers by the following:

  • default value: “Other
  • value: “Other” when “Attached Device Type != Server
  • value “Billing” when “Attached Port Name MATCHES BillingServer_*
  • value “Records” when “Attached Port Name MATCHES CustRecord_*

In general, if a MATCHES is rarely evaluated, then its load — however heavier — only affects the server at rare times, so in total has a lower effect. A 100-fold heavier query run only weekly is not worth swapping for a UDC expression run every five minutes.

Try to consider each case where MATCHES is used for conversion to a UDC expression, and whether even that evaluation can be avoided by a constant expression evaluated before the MATCHES expression. Your portal server will thank you!

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in