microphp manifesto…

i just read funkatrons blog post,
and was a bit sad that there was no option to comment on it..

While the author is right an a few points about the complexity of modern PHP frameworks,
his comparisations are a bit off.

First, his cloc comparistation of Epiphany or slim vs symfonys http kernel totally ignores that symfonys kernel can do more out of the box, and has to do a bit more cause it integrates in a larger framework – obviously something simple needs less code, but it can achieve less aswell.

I can remember Rasmus Lerdorf speaking against PHP Framworks, and giving a hello world example for it – and he was kinda right, if you write a hello world script, you don’t need a framework. The same can be said about those microframeworks – they allow to do small tools, websites or jobs quite quick, but they lack when its about larger applications, and they get pain in the ass when working in a team. Also while the code can be quite readable and organized you often end up with a more throw-away-and-rewrite approach over reuse of code.

he writes he wants to do less code? slim framework, wrong approach. (he is right about the maintaining part though.

Kingboard: now more incremental

The way that pilot/alliance/corporation/general stats where generated wasn’t exactly what i would call optimum. MongoDB does not allow to split up map/reduces over several processes (yet) (except with several server instances), so a map/reduce can take quite long.
So far Kingboard was caching map/reduce results to avoid it to have the high runtimes with large amounts of killmails (i tested with up to 6mio killmails).
This would have caused everyone who actually had a cache miss (expired / not in cache yet) to have unacceptable high wait times.
Now the refresh of the cache could be asynchronous to the request (deliver expired cache while triggering refresh) – but the initial miss would still be there.

Another solution to the problem would have been to autogenerate the stats regulary, however to do that for all sorts of stats by allways map/reducing the full data.. well that gets quite slow too.. so stats would have been generated every two hours or so (well maybe one)).
Thank god MongoDB 1.8+ allows for ‘reduce output’, which basically means the result of a reduce saved in a collection will be auto reduced with the result of an reduce. That makes it quite easy to do incremental map/reduces, you only map the new data, reduce it, mongo takes the old stats reduces the old stats + the new stats, and tada you have the result. With this the run times of the map/reduce get quite manageable, so in my test install im generating all stats every 3 minutes atm (could go as small as every 5 seconds if i wanted to).

EVE: Supers Do Die – Update

released new version after fixing the bug that was reported.
(in a new month without any kills eve-kill would send a string saying ‘null’
rather than the empty json array it was supposed to).
So work arround was implemented, update is on android market,
enjoy!

LG,
PP

EVE: Supers Do Die

well, this is a first blog post about EVE: Supers Do Die.
i recently got an android phone (because i like toys) and
started playing arround (Toys!) with android a bit.

Since playing arround is most fun (for me) if it leads somewhere,
i wrote a small app that shows super capital kills in eve online.

The app can be found in the Android Market, and is kinda free (kinda because i added admob ads – i paid for publishing to the market, so i think its fair to put in an ad .

Screenshot:

Pheal 0.1.0 released

Ok, after pheal dev version hat customizeable keys in for a while,
but people kept bugging me, i’ve created a new release.

Pheal-0.1.0 has
- custom keys enabled by default
- ssl enabled by default

update if you want to use custom keys (you should want that)
dont update if you only have legacy keys and dont want to switch.

listed at 3rdpartyeve.net

I havent been blogging much lately, neither about Pheal nor about anything else. There has been alot happening arround Pheal since my last post, several other developers have added work to it, and nowadays i believe its the best solution for PHP driven 3rd part eve apps.

I recently started a new project, 3rdpartyeve.net which is basically a site listing 3rdparty work arround EVE Online – and ofcourse Pheal is one of the first porjects that i added there

SithTemplate is dead, long live SithTemplate

Piotr Legnica recently announced that he is abandoning SithTemplate due to not using PHP anymore. As you might know i have been a long-time user of SithTemplate, and am a bit sad though.

Now what does this mean for King23? King23 is comming bundled with SithTemplate atm, using it for its templates. Now while all of this might sound “bad” at the moment, it actually isn’t. Piotr has relicensed SithTemplate under the ‘unlicense’ which basically says ‘you can do whatever the fuck you want with this’.

So whats going to happen is:
a) the current King23 Version 0.0.3 still comes with SithTemplate bundled.
b) for 0.0.4 i will fork SithTemplate, rename it to King23_Template, and make a few changes to better integrate it with King23.

Basically this means in not-so-far future you will see the templating system of King23 a bit more integrated (mostly classloading, how it is configured etc.), and support for it will be continued by the King23 project (so Piotr won’t have anyone bugging him about it anymore).

Whats not going to happen: King23_Template will not work outside a King23 environment, if you need that, you have to fork SithTemplate yourself.

King23 Benchmark – playing a numbers game

Several People have been asking me why i actually started writing King23,
with that many OpenSource Frameworks arround.

Well, first of all, because i enjoy doing that. Second is my dislike for some of the
things other frameworks do. When i started with ECOTRA/Northern Crusade
(the first website running on this framework), i looked at several PHP Frameworks
and decided to do King23, basically because i did not need most functionality of
other Frameworks, because i wanted to use SithTemplates as a templating system,
and because of the resource/performance waste that comes with the large frameworks.

Today i had a bit of free time and decided, for the fun of it, to do a bit of
speed testing on a few Frameworks.
The Setup for this is quite simple, the machine i tested on is a cloud level 1
jiffybox
running a basic 64bit Debian 5.0 with Apache + PHP 5.2 + suhosin.
The test itself is a simple apache bench with 500 requests
and a concurrency of 20. (please note that i run ab on the same machine as the webserver).

Please note that i’ve chosen to use PHP 5.2 here, since php 5.3 is still a bit
of an underdog at most hosters, and since none of the frameworks that i tested required
5.3 functionality.

For each framework that i tested i set up a virtual host, and run pretty
much with the default install, with the exception of King23, i used the http://king23.net
websites source for this (since the default starting page barely uses the template system).

Now the values that where of interest from me where Requests per second
and time per request.

cakephp:

Requests per second:    23.02 [#/sec] (mean)
Time per request:       868.960 [ms] (mean)

Cakephp was the slowest of all that i tested, however i want to add that
cake did some checks on the filesystem if the caches are readable and such,
so it did a bit more then just showing a welcome page.

symfony:

Requests per second:    29.75 [#/sec] (mean)
Time per request:       672.324 [ms] (mean)

Symfony didnt really have many suprises for me, we are using it at work,
so i was aware of its performance.

zend:

Requests per second:    54.09 [#/sec] (mean)
Time per request:       369.784 [ms] (mean)

Zend actually did suprise me, i expected it to be at arround
the same speed as symfony if not even slower, but it seems
that Zend doesnt load as much unneeded stuff as cake and symfony
do (symfony included several doctrine related classes that where not needed for the example, cake included some form-handling classes that where not needed either)

king23:

Requests per second:    209.76 [#/sec] (mean)
Time per request:       95.345 [ms] (mean)

Not really a suprise here either, king23′s smaller callstacks, less includes, and more simple structure make a difference. Even with using a more complex template system than symfony for example.

Now before people start crucifying me, let me admit it first: Yes this Benchmark is unfair!!!
As mentioned before, King23 does do alot less, also you can get alot of performance out of all frameworks
if you specifically tune the system for that. Also this benchmarks doesnt say much about the quality,
or about the performance under real conditions. If you add Database stuff to it, if you add a bit more logic
the results will be much closer to eachother then they are in this simple case.

However, before people claim that i tuned the setup for King23,
or tuned the King23 website for the benchmark – i didn’t. Its not using any additional caches,
besides the template cache, meaning for example that it is building the maps for the Autoloader
each time etc. Just to show how a small change in the setup can influence the outcome:
king23+m

Requests per second:    2222.91 [#/sec] (mean)
Time per request:       8.997 [ms] (mean)

This is the same sourcecode, the same application configuration etc. than used before, all i did was
kick apache2 out of the equation, in favour of a php extension called “mistral”, more on mistral in another post soon..

King23: extracting parameters from the hostname…

I just added a small feature to King23s routing that allows you to use parts of the domain as parameters.

An example use for this would be a multi user photoalbum, where the users name is part of the subdomain, for deeplink to his photos… or a multiuser blog etc. pretty much everything where a hostname is preferred.

This is not in the current release yet, but allready available in the git repository on github.

A very simple usage example:

<?php
// get instace of the mainrouter
$router = King23_Router::getInstance();
$router->addRoute("/", "My_View", "index", array('param1'), array('hparam1'));

This adds a route which will match a regular parameter aswell as a hostbased one. Now to explain a bit further, lets look at a full url:
http://example.king23.net/foo
the route in the example would cause the method “index” to be called in My_View, handing one parameter, which is an array, looking like: array(‘param1′ => “foo”, ‘hparam1′ => ‘net’).. “net” you wonder? well, the parts of the host are matched in reverse order, so example.king23.net first parameter would be net, second king23 and third example.
This is mostly to ensure that if you have more parameters than host segments this gets filled in a logical way.

Now this is nice, but actually you did not want the actual domain name as paramters, just subdomains of it? if you have http://username.users.king23.net then you’d be interested in username, not in users.king23.net, right? Well, there is a simple solution for that:

<?php
$router->setBaseHost('users.king23.net');

this simple line will cause the unwanted part to be removed. The route from the first example would cause “http://myusername.users.king23.net/foo” to be translated to a call to My_View::index with one array parameter containing array(‘param1′ => “foo”, ‘hparam1′ => “myusername”).

random update… oh, and a new page

yeah i know i know, i haven’t posted in a while,
thats mostly because i haven’t done much stuff thats worth writing about.

however i’ve put a bit of time into a webpage for the king23 framework, and if you want to you can check out a first (very small) version at http://king23.net.
if i manage to find a bit more time i should probably start in writing a bit more docs then the inline docs and the tutorial posts on this blog.

I’ve been toying arround a bit with the idea of adding a bit of tools to integrate with hookbox, but i haven’t had a good idea on what i want to try it out, so that will have to wait a bit.