ScientiaMobile

Currently, we are using Tera-WURFL 2.1.5 but we are going to apply Wurfl PHP. My system has about 2000 requests/second (It's huge and It continues increasing ). so I really consider about the performance about this change. Anyone here could tell me about the performance of Wurfl PHP lib? is it faster than Tera-WURFL 2.1.5 ? it has full features as Tera-WURFL 2.1.5 ?

Thanks in advance!

Hi,

With 2k req/sec, everything bottlenecks will start appearing all over, so it's hard to say which API will be faster. If you have 1GB of RAM to allocate to APC, then using the PHP API with APC will probably be your fastest option. If you are using multiple servers, I would seriously consider using the PHP API with a shared Memcache server, so all the APIs share the same cache. If your frontend servers are already low on memory, I/O and/or CPU, I would take a look at setting up a separate server just for the Database API / Tera-WURFL, and using the TeraWurflRemoteClient on the frontend servers. This is a lightweight PHP client that talks to the master Tera-WURFL server with a RESTful API. That approach will offload the resources to the central server.

With regards to features, the PHP API is very similar to the Database API. Notable features that are currently only available on one API are:
Database API: Remote HTTP API to separate frontend servers from WURFL API server, and the capability filter to allow you to load only certain WURFL capabilities (if you're not doing this, you should really do it!).
PHP API: Shared memory caching (APC, Memcache)

Note that the shared memory caching and capability filter are on the development roadmap to be ported, so in v1.5 or v2.0 of the API (later this year), both APIs will support these functions.

Finally, with this much traffic, I would suggest you contact us at http://www.scientiamobile.com/license and we can talk in more detail about our ultra high-performance options like the WURFL C++ Apache Module and similar plugins for popular reverse proxies.

I tried to compare results between Tera-Wurfl and Wurfl API. But they are really different. I tested on 1000 different user-agent and compare some capabilities as :
Tera-wurfl :
$my_device->capabilities['display']['max_image_width']
$my_device->capabilities['display']['resolution_width']
$my_device->capabilities['product_info']['brand_name']
$my_device->capabilities['product_info']['model_name']
$my_device->capabilities['markup']['xhtml_support_level']
$my_device->capabilities['product_info']['device_os']
$my_device->capabilities['streaming']['streaming_video']
................


Wurfl API :
$requestingDevice->getCapability('max_image_width')
$requestingDevice->getCapability('resolution_width')
$requestingDevice->getCapability('brand_name')
$requestingDevice->getCapability('model_name')
$requestingDevice->getCapability('xhtml_support_level')
$requestingDevice->getCapability('device_os')
$requestingDevice->getCapability('streaming_video')


Example : I tested on user-agent = SonyEricssonJ105i/R1GA Profile/MIDP-2.1 Configuration/CLDC-1.1 UNTRUSTED/1.0
Tera-wurfl :
$my_device->capabilities['display']['max_image_width'] return 228
$my_device->capabilities['display']['resolution_width'] return 240
$my_device->capabilities['product_info']['brand_name'] return null
$my_device->capabilities['product_info']['model_name'] return null
$my_device->capabilities['markup']['xhtml_support_level'] return 4
$my_device->capabilities['streaming']['streaming_video'] return 1

Wurfl API :
$requestingDevice->getCapability('max_image_width') return 176
$requestingDevice->getCapability('resolution_width') return 176
$requestingDevice->getCapability('brand_name') return 'Generic'
$requestingDevice->getCapability('model_name') return 'J2ME Midlet'
$requestingDevice->getCapability('xhtml_support_level') return 1
$requestingDevice->getCapability('streaming_video') return false

Could you please explain why they are so different? and which result is correct?

There are some differences in the detection, but they should be minimal with the latest version of the API, and very minimal with the upcoming version.

In your specific example of the SonyEricsson J105i, the Database API has matched the actual device, and the PHP API has noticed the "UNTRUSTED/1.0" string in the user agent, which indicates that this is not a mobile browser, but rather, it is a Java Midlet. Our take is that the Java Midlet match is more appropriate since any content that is adapted on your end will need to be served to the Java Midlet, not the browser, and we can make very few assumptions about the rendering ability of an arbitrary Java Midlet.

In the latest release of the Database API (1.4.0 [note the new version scheme, which matches the PHP API] http://sourceforge.net/projects/wurfl/f ... abase/1.4/), that the stated user agent matches the Java Midlet as intended.