Tuesday, October 28, 2008

150 OpenSearch plugins for Colnect

"OpenSearch is a collection of simple formats for the sharing of search results" the official website says. OpenSearch makes interfacing a website in which you use a lot of search much easier since you don't have to navigate through the site's pages to see the results. You skip waiting for a new page and save yourself some time.

Colnect supports OpenSearch for the benefit of the collectors on the site who often search the huge catalogs for the items they're interested in.

In Firefox:

and IE7:


Yesterday I've tried to publish the plugins on Mycroft Project so collectors could easily install from there as well. It's probably the web's most notable directory for OpenSearch plugins. The problem is that Mycroft has no auto-submission feature to be found and so I couldn't add all the plugins.

"How many plugins have you made?" you might ask and the answer is quite simple. There's one plugin to search for a collectible item by name and another to search for a collector by username. Later I may add searching by catalog code. So what's the problem submitting 2 plugins manually? Well... that 2 turned into 150 since currently there are 3 collectible types on Colnect (coins, stamps and phonecards) and the site is supported in 25 languages. 2 times 3 times 25 gets to 150 and that's not so much fun to do manually anymore... I hope they'll come up with a solution. The best would be to use simply submit the site's URLs and let MyCroft use the auto-discovery link tags like the browsers use to allow you to add the plugin.

Happy OpenSearching...

Sunday, October 19, 2008

Colnect V2 is now LIVE! :)






Following a long period of hard work, Colnect V2 is now up and running. It is a completely new version of the familiar Colnect. Its huge catalogs, from which any collector can easily manage his/her personal collection, currently include nearly 12,000 coins and over 120,000 collectible phone cards. As the catalog information is contributed by collectors, the catalog is expected to grow very quickly in the coming months.

Colnect V2 is available in 25 languages accommodating for the needs of collectors from all around the globe.

Go check out the site and register if you haven't so far. We're on the way to revolutionize the collectibles world.

Saturday, September 20, 2008

Performance: MySQL, APC, memcached.

A highly important issue of any notable website is performance. You may have created the best website in the world but if it dies under load, you're gonna lose customers. User experience is very important today and having a slow website doesn't help at all.

Optimization is, however, not a trivial issue and requires expertise in different fields. There are so many different places where you can optimize that it's not always that easy to know what to focus on. Though this post will adhere to its title I'll still list here where optimization can occur in a website.

* Correct usage of HTTP headers to make client browsers request less information.
* Smaller responses (gZIP / more CSS - less HTML / use of Ajax to return instead of reloading complete pages).
* Optimization of your server machine(s) hardware AKA "I need more CPU, I need more memory and 'how much is another 1U?".
* Server software optimizations: Webserver (such as Apache) / Scripting engine (such as PHP) / DBMS (such as MySQL) / cache engines (such as memcached, APC) could and should be tweaked heavily. Failing to define an appropriate index in your DBMS or making some wrong choices on where and when the webserver saves user sessions, for example, could carry a heavy toll.
* Network optimizations: anyone said CDNs?

The fun part is that all these parts are well entangled.

I've read an interesting post about prefering MySQL cache over the popular memcached in some situations. Though it was pretty much one-sided (ignoring the overhead of a database connection), it rose some interesting points and is well worth reading.

An advantage towards the DBMS that I consider relevant is greater flexibility. For example: you allow outdated information to persist (such as statistics). Say you want it updated about every 5 minutes. If you cache it for 5 minutes it'll expire and then you may face a situation in which a few threads query the database again to get this information. If you use a Memory table for this information you can read it and, if expired, set some writing lock that'll cause other thread to keep reading the expired information until it's well updated.

Another interesting older post about performance showed some interesting benchmarks. The biggest problem of relying on others' benchmarks is there can always be one single parameter different on your system that would mean the results for you would be totally different. For example:
* A new version of a product has just changed everything about it.
* A configuration option made a product completely flunk its benchmark tests.
* Your queries may not be similar at all to what is tested (though you may think it is).

So these were my 2c about performance for now. The bottom line is simple: there's always a part of your system that's not properly optimized. The best is to check the painful spots and remedy them while maintaining an overall look of what your system has to provide.

Link and Search

Did you like reading it? Stay in the loop via RSS. Thanks :)