Sorry to say but there is no progress since my last post. I tried to make the admin interface (just basics) working in IE but it’s kinda hard to get it working in ie6. And to get that working i spend roughly a full day of trying to get ie6 running under linux (wine) or in a virtual machine (kvm) both failed and worked but never worked long before crashing to never be able to start again thus resulting me in re-installing that shit again.

What i’m going to do now is completely ignore IE (all versions) and make it work in FF. Once it’s all done i will take another look at IE. The user side interface of MageDB works just fine under IE. the admin is just a problematic one.

That’s it for now,
Mark

Last post was about making tough decisions between a SplStack vs Array + array_reverse and now i think i’m just going for a stack when php 5.3 is used. This is just for the title buildup which is hardly ever bigger then 5 entries, but a stack is just where these kind of things are good for (LIFO, Last In First Out).

Now for the admin panel.
I haven’t been extremely busy with magedb but did made up a first mockup of the admin panel (sadly can’t show the image because wordpress is having a: “no i don’t want to upload images” moment.. but the start is here. The way i’m going to make the admin panel is with a horizontal tabbed navigation and as soon as you click and of the category’s you will, right below it, see the sub ctegory’s you can access. For example:

File Management
| Add file | Delete file | List file |

Kinda like that. Only then with nice icons and probably some more options. Probably also a “Rebuild file cache” and some others. I hope to have the majority of the admin panel done by tomorrow.

That’s it for now,
Mark.

Oke, now i’m kinda getting crazy by my own benchmarks:

What you see above is very interesting. Lets first look at the Array VS SplFixedArray one. If you look at the execution time you see that the SplFixedArray is roughly 1 third faster then a normal array. Now look at the memory part. SplFixedArray is more then twice as efficient as a normal array in terms of memory and it’s even 1/3 faster then a normal array! So i will use it when available like said in my previous post. And i think i will use it in every place where possible. the performance numbers speak for themself.

Now that SplFixedArray one was already on my list to use because i roughly knew the performance boosts it gives but the real decision part that’s breaking my head is the stack benchmarks. The first stack one is the most memory efficient and, after further benching it, becomes faster then the array_reverse one if you add in 100.000 elements (those 3 stack ones have 1.000 elements). The second stack one (array_unshift) is the one that i was using till just 30 minutes ago. I knew it was slow but i didn’t know how i could fix it. Turns out making a normal array then using array_reverse is exactly what i needed to fix it. Now the issue here is the SplStack (first stack one) is a nice object and doing exactly what i want, but is slower then a normal array followed by array_reverse when filled. So what do i need to choose here? lower memory, not the fastest way and nice object (SplStack) or fastest option, little more memory and no nice object (array followed by array_reverse).. I tend to choose the array + array_reverse option and that’s mainly because the data in this array will probably be never more then 10 elements. In case you want to know. I use this in the category class where i calculate the title array and that is the link part that allows you to go back to the parent category (up until the root category).

Now for the updates
Category class is updated to be a lot faster with bigger arrays (removed the use of array_unshift). The cache abstraction is nearly done. All that’s left to be done in there is the file based caching.

That’s it for todays progress,
Mark.

I just made the MySQLi use of MageDB a little more effective. Previously it was duplicating some code to make arrays out of database requests. Now one function is making all the array decisions and the rest makes use of that one function resulting in cleaner and more easy to understand code.

That was the most minor thing. Another thing i added in is array profiling! quite handy when you’re developing but for the avarage user of MageDB not of much use thus it’s off by default.

The last thing i added in is quite complex. In PHP 5.3 you have a new MySQL backend called MySQLND (nd == native driver) which is, when enabled, used for mysqli, mysql and pdo_mysql. If it’s not enabled the ‘old’ default of libmysql is used. That’s one of the changes in PHP 5.3 one which i can use in MageDB. When MySQLND is enabled i have the function: fetch_all() in mysqli which is putting a query response in a array. Now this is probably not turned on on every php 5.3 server so if that’s the case i’m going to use SplFixedArray which is just a bit faster then a normal array but twice as memory efficient! So, that’s a big win win situation for you as a user and your host as a sever owner. So there you have it. 2 php 5.3 features are already in MageDB and will be used as soon as your server has it. Buth features that i user are (still) backwards compatible with at least php 5.2.

And an idea for some future version. Right now MageDB is MySQLi only and just MySQL will never be supported anymore since that is just ugly stuff. But i do think of supporting PostgreSQL but that will be quite hard since queries are not exactly the same on both database vendors.. most are the same though.

And last but not least. MageDB updates will from now on be here a lot more or faster since the next week is going to be a MageDB scripting week.

Till next post,
Mark

There actually is no progress to report but there is some news.

The delay in MageDB is actually good. When i posted the delay i didn’t knew PHP 5.3 was going to be released today and i’ve never tested MageDB with php 5.3 before so i smell a nice opportunity here.

So what does this mean? Well first of all i have a hard week right now (school stuff) and am done with that coming friday. So just because of that there will be no progress until friday. Another major factor is the php 5.3 release that is scheduled for today (as of this writing it’s not released yet and has just been released) and i am going to wait with big magedb progress until php 5.3 is released. As soon as that happens i will install it, run magedb on it and see how it works and if it needs fixing somewhere. I will (right now) update the MageDB progress on www.mageprojects.com because it’s a lot more finished then described there.

So, more news after php 5.3 is released and after (or on) next friday.

Thanks,
Mark

Updated one minute after initial post with php 5.3 release link

I’ve been on a domain registering spree the last few days. I’ve registered MageDB.net and MageDB.com where the .com domain redirects you to the .net one. The purpose of that .net domain is going to be to just host MageDB and possible services (like MageDB hosting solutions) all centralised on that one domain. A added banifit is ofcourse that a full domain name with the same name as the script looks a lot more professional then a simple subdomain on my projects domain. For now this blog remains on mageprojects and magedb news will be posted on this blog, but in time i might create a new seperate blog on magedb.net for magedb only news.. who knows.

And, yes, i’ve added google adsence advertisements on MageDB.net just to see if it works out well and ofcourse to make some money once that domain is actively hosting MageDB.

Now for the new hosting. I found a new “home” at BoostVisual. They are cheap and from what i’ve seen so far offer nice hosting solutions. The speed is great with them as well which isn’t always the case for me when downloading stuff from servers in usa. The only think i’m waiting for before i can migrate this blog to there host is the php MySQLi and APC extensions to be installed. As soon as that’s been fixed i will start migrating my all of this to that host.

Now for some tine MageDB news.
I had quite a lot of trouble getting my category class working for menu navigation and also some annoying cache issues which is now all fixed. Now here is a start of the features that are not going to make beta 1 but will likely be in beta 2:

• Search engine friendly urls
• Comments in file view
• ajax based file rating in file view

Features that are not implemented yet but should be in the first beta release later this week or early next week

• Full admin panel
• search (sql based not highly optimised one)
• statistics (basic ones)
• [ done ] working category’s (template is here.. code is here partly)
• [ W.I.P. ] ability to: download, rate, report and mail a file
• upload a file (also part of the admin panel)
• apc abstraction because right now magedb is not working without apc (needed because with APC is the only way it’s working now)
• settings for various magedb things (needed for the header mostly)
• writing a logger to for example log mails being send (needed for mail a file aka mail link to friend)
• “intelligent” spam detection for mails send and also for comments when they are here (needed for mail a file aka mail link to friend)
• Tagcloud (yea, i will go go with the hype around this.. i don’t really see a benifit but well, you’re going to get it)

I will update those last 6 features here with a [ done ] tag once i’ve made them.
// note to self :: am i ever going to make that big list in just a few days?

That’s it for now,
Mark

Quite a lot is going on in and around MageDB. Lets start with the Tables.

Tables are back
At first when i started with magedb (late 2006 early 2007) i was under the impression that tables where just bad period. That opinion got changed roughly a year ago when i read something like this somewhere: “Tables are not intended for defining how a page looks. Tables are here for lists of data so use it for lists and use divs for page layout stuff.” so when i made the category and file view in MageDB i remembered that. The result of that is that tables are back in MageDB (if you search the internet on MageDB and tables you will find me posting on some blog that i removed tables) and are kicking asses there. As a result of tables being back the MageDB browser support could be from Internet Explorer 6 and up. I usually don’t support IE6 but in this case where i wide range of people could use this script at some point in time it seemed wite to me to support as much browsers as possible with as little javascript and css tricks as possible. Right now i use NO javascript tricks and NO css tricks and it works fairly well on IE6. Some parts do not work on IE6 but that will have to be fixed by using the famous IE7 javascript file which makes ie6 act mostly like ie7. this is done through conditional comments in html so that other browsers see it as.. comments and do nothing with it. Only IE knows it and does something with it. Microsofts way of telling they screwed up big time in ie and a possible way of making it all a bit better.

MageDB hosting
This is right now just an idea but something i’ve been thinking about a lot lately and something i really want to provide with magedb. Perhaps some of you remember paFileDB? they had an option to buy “paFileDB hosting” which was optimised (right?) for use with paFileDB thus giving you the ability to have hosting that was sure to work with paFileDB and had support from the creators. I tend to do roughly the same thing. I don’t plan on buying a dedicated server and put hosting on it becasue that’s not just one server if you do it good. That’s going to be atleast 2. 1 for backup one for the accounts. My idea now is to allow you to register for a simple free account on mageprojects on which you can host your files, screenshots and have your database on. It’s NOT meant as hosting where you host your site on.. only your database with the graphical interface (MageDB). That idea would be the free plan. The paid plan (yes that’s going to be there if i do this at all) will allow you to run your site from that account, will allow you to buy a domain along with it, will get you access to probably cpanel and will give you support for MageDB. That’s going to cost you some euros per month. Right now i’m thinking of something around 15 euros per month.

Mageprojects server move
A few days ago i received a message from my host that they where attacked and are going to stop providing hosting packages and giving all there customers 2 weeks to move there sites to another host or everything will be lost (they didn’t said the last part but i can guess that) so i’m right now hunting for a new hosting provider. Finding one in the netherlands (my home country) or some in europe that’s equal or better then the package i currently have seems extremely hard to find (6 gb space, 60 gb bandwidth for just 4 pound in uk) so i’m right now looking at hosting in USA to see if that’s going to work out. Whatever the results are. Mageprojects will have to move to another server within now and 12 days.

As for MageDB progress. None happened yesterday but last sunday the file view was nearly finished (only thumbnails left to do). And in the very near future i’m going to make a blog post here with the features that are in MageDB right now, those that will get in there before i release a release candidate and how the features are in the end MageDB 1.0.0 release. For now i do intend to release a beta later this week (depends on the admin panel) and during that beta new features will still be added. During the release candidate cycle there will only be bug and feature fixes but no new features at all. The release planning so far:
MageDB Beta 1 (0.8.0) — later this week or early next week
MageDB Bera 2 (0.9.0) — unknown (and only if needed)
MageDB Release Candidate 1 (0.9.5) — unknown
MageDB Release Candidate 2 (0.9.6) — unknown (and only if needed and as you can see in the release numbers i can go till rc 5 ^_^)
MageDB Final (1.0.0) — somewhere in July i hope

So a lot of stuff is going to happen with MageDB and Mageprojects.

Till next post (on perhaps another server),
Mark

I started theming MageDB with the following goals in mind:

• clearly vissible where you hold your mouse regarding file/category lists
• easy and intuitive interface
• easy to use
• easy for the eyes
• color variation but not to much
• Works in all major browsers + ie 6 and 7

NOTE: the “There are no…” text is there just for me to see how that looks. In this case both those lines should be gone.

And the result of that is this:

Things i still have to do in the layout:

• Improve the login/password/go fields
• minor css fixes
• Make a file view, download view… and everything else i can think of.

The rough lines are done now. Right now it’s all just a mather of fine tuning before i can start on the administration panel. And then, once that’s done, MageDB is finally ready to get an release candidate release! And i hope i’m at that point by the end of next week.

Btw. sorry for the ugly downscale of the image above. WordPress seems to be a bit broken on my site. If i can’t get it fixed fast i will probably reinstall it.

That’s it for now,
Mark.

first a list of the current requests per second all benchmarked on my personal pc:
PHPBB : 100 requests per second
paFileDB : 1200 requests per second
MageDB : 2000 requests per second
MageDB without MySQL : 2600 requests per second

Clean php file with only ‘hello world!’ : 3800 requests per second
Clean html file with only hello world : 6000 requests per second

Oke, now what is all of this? First look at the clean php and html ones. Clean html file means just 1 line of text and that’s able to get 6000 requests per second on my pc. That benchmark is quite useless for comparision. The interesting one is a clean php file with 3800 requests per second. That means that my pc can have 3800 requests per second MAX with php.  The lighter MageDB is the more requests per second it can handle.  What i’m doing right now in MageDB is caching every object i make in APC and retreive that one from the APC cache next time a visitor looks at MageDB. With this technique the requests per second shoot up from roughly 1400 to 1600 which is already quite impressive. now to get more requests per second i took a close look at one of the biggest request sucking piece: Dwoo. That one took 600 request with my last blogpost.  In Dwoo i noticed  i added a Compiler class while it wasn’t even needed. That one class sucked up ~150 requests per second. Disabling that one meand my 1600 went up to roughly 1750 requests per second. Then i had found a bug in Dwoo that caused a lot of stat calls and most of them with “no such file or directory’ so i fixed that one up which improved the requests per second by another rough 100 resulting in 1850 requests per seond. Add to that a cached category lookup system that fetches his category data from APC and doesn’t need to recalculate everything all the time which added yet another requests per second boost of 150 resulting in 2000 requests per second! that’s really fast!. Then i want to investigate a little to see the next big request sucker. That one was surprisingly MySQLi. It takes up 600 requests per second! So by now so much was cached that a query wasn’t even needed anymore so i disabled MySQLi in MageDB for a minute to see how fast it would be. And that was a major boost of 600 requests per second resulting in 2600 requests per second for MageDB. The big issue i have right now is that MySQLi doesn’t have to be included always when the requested data is in the cache but in other cases a few queries will have to be done. So i need to find a way to include MySQL when there is a need for MySQL. If that’s implemented and working then those 600 requests that MySQL takes will be wasted a lot less. Now i ofcourse can’t cache every single thing since a database in MageDB could contain thousands of files thus looking at a file will probably still be a query call but the very main page of MageDB is going to be extremely fast for PHP to parse and that will probably keep your host happy ^_^.

Please note that 2600 requests per second like at this moment for MageDB is extremely fast and is only possible in the most optimal condition. In reality it’s more likely that you get between 1500 and 2000 requests per second which is still 15 – 20 times faster then phpbb.

I also still have to make a caching abstraction to allow you to choose how you want to cache:

1. MySQL
2. File
3. APC
4. Memcached

where File based caching will probably be the default one. And in that case i will probably put as much information in one cache file as possible. Another possibility is File caching by default but as soon as the file is loaded in the memory it will be memcached for as long as possible and then just reloaded from the file once the memcached session has expired.

That’s it for now. More stuff will come probably later this week,
Mark.

MageDB with Zend
MageDB without Zend
Zend

The results are yet again surprising to me.
MageDB with Zend  is a freaking 20.0 MB
MageDB without Zend just is: 681.7 KB (note: this is WITH Dwoo! which takes up 495.4 KB of that 681.7 KB and that means MageDB itself (the core) is: 186.3 KB)
Zend alone is: 19.4 MB

Add to this the performance (in requests per second) loss i would have had if Zend was included and the size of the complete MageDB package.
That gives me enough reasons o just drop Zend.

So how am i going to replace Zend’s modules that i WAS using?
I where just 3 modules (that sucked up over 50 includes)..

• Db [ - Done - ]
  Going to skip this all together, make a few functions to have nicely formed database arrays but that’s it.
• Translate [ - Done - ]
  Going to recreate it based on INI files or just a big PHP array. This is probably the hardest module to recreate out of the ones that i used
• Registry [ - Done - ]
  Going to recreate it
• Autoload [ Not going to do before 1.0.0 ]
  For now i won’t do anything with it. Dwoo is using it and that will stay but i won (yet) play with outoload for version 1.0.0 of MageDB

So now your all up to data again with the progress on MageDB. And i have some more work to do.

Cya,
Mark

Db update:
I’m not sure yet but i think i’m going to use the SplFixedArray for the Db. Banchmarks on the internet show that it’s a little faster then a normal array but twice as memory efficient. This does however make MageDB a PHP 5.3 or higher script! Stay tuned for more information about this Db part later this week as soon as i’ve done some tests with it.

Updates regarding “Done ” components + a bit more
For the Db component, i extended the MySQLi class (internal php class) and named it MageMySQLi. In there i implemented the fetchAssoc and fetchAll methods that you can also find in Zend_Db. Other then that nothing Db related (like query logs) is implemented. For now MageDB works again without any Zend components but with Zend LIKE components.

For the Translate component. I’m actually surprised of myself that i made that component in just roughly one hour. I made it static which means that “MageTranslate” (name of the static class) can be used anywhere throughout the code without any issues to make it global because static classes are per definition global. One thing i added that wasn’t even in the Zend_Translate module is a fallback language. For example. The default fully implemented language is going to be english for MageDB but if you add another language and use that language but one translation line is missing then it will use the fallback language which is set (by default but you can change that) to english.

Now for the registry component. That’s actually a lot like the Translate component. both are static thus global classes. The purpose of the MageRegistry is to make local variables accessible globally by putting them in a static class. You can see this as one big container where you put your stuff in. Your stuff alone without the container is hard to transport. When it’s in the container another route can be choosen and in this case it’s a open route to everywhere.

So that was one day of kicking Zend out of MageDB and replacing Zend’s components by self made small ones. This still leaves a few other components to be made:

• ACL component (for later MageDB version)
• Feed module for rss and atom feeds
• Log module for logging stuff in a database table
• Cache module for caching compiled templates
• Mail module for sending mails
• Compression module for compressing database backups
• And in time probably my own template engine

Btw. MageDB is right now faster then paFileDB  with rougly 200 requests per second more for MageDB resulting in a total of 1400 requests per second! That is FAST!! compared to a lot of other scripts.

that was it for the edit,
Mark

I did some major work on MageDB again. This time to make the code that i currently have more structured. And the results look nice.
For example the inclusion of sub pages on a page used to roughly take 40 or 50 lines of code (with all the if elseif elseif … else + checks + include lines) but right now that part is down to 16 lines with enters and handles 4 pages (view, download, post_comment and rate) this can be done in less lines but will become ugly or look strange.

Other things i did in MageDB was rechecking the input values if they where really safe. They where not thus i needed to fix that up. It’s now way shorter and a lot more strict.

For the rest i did performance testing of the current MageDB codebase. That is without the template engine (Dwoo) since i didn’t include that one yet. I came to very surprising results compared to the latest paFileDB (not downloadable because there site is offline and seems just dead). I had expected MageDB to run faster then paFileDB but sadly that’s not the case. In terms of requests per second (ab — Apache Banch) MageDB gets roughly 900 requests per second (lighttpd + php + APC module) and paFileDB gets roughly 1200 requests per second on the same setup! that’s roughly 33% FASTER then my MageDB script. But i do think that the current MageDB code-base is way more suited to heavy load then paFileDB was.

Anyway. that unpleasant surprise made me wonder what was taking up the resources so i installed XDebug and did some traces on MageDB and paFileDB. It turns out that MageDB had roughly 2x more function calls then paFileDB and is roughly 1.8x slower then paFileDB. Now what caused that?
Zend sadly is the source of the problems. I already found out that it’s including a shitload of classes (thus also files in zend’s case) and that alone makes everything run a bit slower. Then the parts of Zend that i use right now: Db (for mysql), Translate (to support multiple languages), Registry (nice way to have global variables in a clean way) and the Autoload for zend itself. Now my guess is that it’s including roughly 40 or even 50 files because 1 simple test with only 1 zend module being used resulted in 30!!!! classes (thus files) being included.

So what am i going to do about this? Well at some point in time i will just (again) drop Zend for being a time ans resource hog. I will only have to recreate the classes Registry and Locale and use just php’s mysqli without a wrapper. It’s not like i was planning to support anything other then mysql anyway although in the long run i would have liked sqlite and postgresql support as well. For right now i probably just continue where i left and keep zend in it for now.

The things i have to do now before i can start working on the admin panel:

• Making a very strict and fast category caching system since category calculations are heavy on php(recursive checks and thus a lot of loops) and on mysql(i’m grabbing all category data at once…).
• Including Dwoo as the template engine

And btw. My goal in requests per second on my hardware and the above named setup is to have 1000 requests/second on every page that MageDB has. Just for comparison, phpbb has just a pathetic 44.97 requests/second and that is with the above mentions setup! Note: just having APC installed is a rough x2 or even x3 speed improvement.

That’s it for the MageDB news,
Mark

Right now i’m about done with the details of a file in MageDB and how complex it’s going to be in the coding. It’s becomming quite heavy because i’ve decided to do all file related stuff in file.php or include files that do it.
For example. If you rate a file that is done by rate.php but done through file.php. Same for file downloads. they are done with download.php but done through file.php thus file.php gets extensive.

You can see this like sub pages of the file  page like this:
file
- rate
- view (this is just the file and all it’s details and is what you see when you click on a file)
- download
- rating
- comments

By now you might wonder what the milestone is. Well, the file part, though not done yet, was the biggest issue till this moment. That part is roughly done in raw coding which mkes all the user parts roughly done in coding. And that means that i can start by making the admin part. Now don’t think that there is anything to show because there isn’t besided printed arrays. I’m not even including the template engine in magedb yet!

So again some nice progress in MageDB.

Till next post,
Mark.

In the last few days, specially the last few hours, i’ve testes out some “new” technologies from the Zend Framework. I was already planning on using Zend for the DB an Cache and perhaps a few others but now i’ve discovered the features of: Zend_Regitry and Zend_Translate.

The Registry object is a smart way of accessing variables globally in a nice way (through the use of a static class). I was always wondering how i could get rig of global variables in php in some cases or adding extra getters/setters to classes in order to give them the data they need. Zend_Registry seems to be providing a nice new clean way for global variables.

The Translate object is really nice as well. That object allows me to make MageDB a multi-language script. I did a few tests with it and it seems to be working very nice. The language files where going to be gettext files but that seemed a bit annoying to make so i picked a ini based style.

Now for some other MageDB progress. I am currently working on building up the file view page. And just to give you an idea of how this was going under paFileDB:

They fetched the raw sql data in php and practicly dumped that to smarty where a loop was done to display it all where they manually looked up for every possible setting. That is all fine but the issue there was that it required if/else statements in the templates! and that’s something you want to avoid as much as possible just so that making a new theme is as easy as possible.

Now MageDB is doing it a bit different. In php all data is fetched, like in paFileDB, but i loop through all the data in PHP, filter/modify it all i want, make a nice array with all the new data and that array will be pushed in the template engine (Dwoo). Sadly this won’t prevent all if/else statements but it will prevent a lot from being needed in the templates because they are all already done in the php code. Things where if/else statements are needed are with the screenshots. I can’t give a array of marked up screenshots because that would be html inside php and that’s exactly the thing i try to prevent in MageDB by using a template engine.

All in all the progress isn’t going fast, but coming along quite nicely in this rate.

I will post some more progress sometime later this week.

Cya,
Mark

Since paFileDB seems to be dead (see for youself) i got more interested in putting more attention to MageDB.
It’s not the first time that i spend a few hours on making MageDB possible but up until now it never was much more then some work on it before giving up again. So i’m doing things a bit different this time.

For starters i’m going to drop all promisses i made about previous MageDB versions. The one i’m making now is going to have an entirely new structure and this also means that (for now) the plugin based MageDB is off. that would take way to much time and is way to hard to “just” do. What i’m doing now is first getting the most importand parts to work. The pages and the categories. Both are working fine at this time. Next up are the:

• files
• download possibility
• login
• admin

keep in mind that admin is HUGE. that consists of:

• add/edit/delete files
• add/edit/delete categories
• add/edit/delete users
• settings for MageDB
• database backup and restore tool
• and probably some more

And once that’s done it’s time for user priviledges and making them work. That part is huge on it’s own. After that it’s:

• theming a default MageDB
• make a install script
• make a conversion script from paFileDB to MageDB
• make language files for multiple languages or the possibility to have it

Update: if you want to see the progress so far click here it will bring you to the MageDB todo list on O-Todo. I didn’t fill in everything because i will have my hands full with the parts that are in it now.

And a little bit more technical. With paFileDB a lot of checks (for example to show or hide the viewall link) was done in the template files. Back then when i saw it i didn’t know how things like that where supposed to go. Now i’m still not sure but i’m going to prepare all the data for html in the PHP scripts and send them to HTML to do as much in HTML in as little code as possible to keep it readable. if statements in HTML (and other template specific settings in HTML) make it needlesly hard to understand for persons that want to make there own theme.

About the default MageDB theme.. don’t expect it to be extremely pritty with a lot of AJAX in it. That stuff will come as well but probably not in the first stable release.

And once that’s done it’s time for a 0.1 or 0.5 release (beta or release candidate). This is all just to let you know how the progress is at this moment. Let me be clear about it that i do want to release MageDB (under GPLv2 or GPLv3) because of the simple reason that there is no decent file download script around now because the biggest and best one (paFileDB) died.

So stay tuned this time. The progress will go rapidly and something will be visual in the comming days.

Till next post,
Mark.

After yesterday when i installed WordPress 2.7 i was interested by how the performance was going to be. So i ran a small benchmark tool called: AB (Apache Benchmark) and tested it locally.

I tested it on my notebook (Acer Aspire 5630, Core 2 duo T5200 1.6 Ghz and 1 gig memory.
The OS i tested it on was Fedora 10.

Changes i made:

• Enabled url rewriting in apache
• Turned on permalinks in WordPress

I did not install any other modules in WordPress. All just the default stuff.
Everything else is just the default fedora install for:

• Apache
• MySQL
• PHP

with no settings changed.

Now for the results:

Server Software:        Apache/2.2.10
Server Hostname:        localhost
Server Port:            80

Document Path:          /
Document Length:        5081 bytes

Concurrency Level:      5
Time taken for tests:   86.132 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      5319000 bytes
HTML transferred:       5081000 bytes
Requests per second:    11.61 [#/sec] (mean)
Time per request:       430.658 [ms] (mean)
Time per request:       86.132 [ms] (mean, across all concurrent requests)
Transfer rate:          60.31 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    0   3.5      0      67
Processing:   194  430  69.2    432     688
Waiting:      181  418  69.3    419     688
Total:        194  430  69.5    432     689

Percentage of the requests served within a certain time (ms)
50%    432
66%    459
75%    477
80%    490
90%    517
95%    543
98%    569
99%    586
100%    689 (longest request)

Those results are.. kinda slow! With this new WordPress you can have (on my notebook hardware) just 11 requests per second. If you have a site that has 11 requests per second you have a populair site and your probably on your own dedi/colo server but if you are on a shared host this can be to heavy to run! In the old days when i had lame shared hosting a simple topsite script an a forum (Invision Power board) where banned to use because it took to much resources… this wordpress is surely heavier then those 2 scripts about 6 or 7 years ago!

I also looked at the CPU usage when running the benchmark. it was at 100% !!

WordPress is a nice user friendly script but they need to do something about there resource usage and for the next version get rid of the php 4 support.

I might run some more benchmarks later this month along with some profiling and how the WP-Super-Cache module can change things.

For now the conclusion is that WordPress 2.7 is resource hungry and probably not a good idea to run on a shared host I must admit that i’m running it on a shared host on mageprojects (where you read this now) and i haven’t got an angry mail yet from my host.. but then again.. i get just a few visits in here.

That’s it for now,
Mark

You probably won’t guess what’s it gonna be right?
Stay tuned because it will come online later today!

And it’s all gonna be FREE!