Hi Robert,

I'm not ready to promise to maintain your project, but I'm interested. Currently I use IM for thumbnail generation via a shell script.

I'm really intrigued by your download comparisons for the thumbnails. I didn't see any difference because by inbound pipe was the limiting factor.

So your results say that thumbtest.taf is 3x slower than thumbtest.php? Wow! I guess I'll have to run my own tests on my download.taf vs. a download.php. But I notice that your php server has keep alive on, while the witango apache server doesn't. Does this make a difference?

But, it seems to me that for high performance, we should ditch php/ taf and instead use mod_rewrite with an external rewriting program. The program, which is only loaded once, takes the uid from the $ENV and performs the sql query directly against the db. Have you looked into this approach?

bill
On Apr 26, 2006, at 2:53 AM, Robert Garcia wrote:

I have some to contribute, but more cuz I am tired of dealing with it than anything. As you know, I have asked many times for documentation on the bean handler in witango. I have never got it, and have asked numerous times. We use external actions for some imagemagick stuff, which has been fine for us, cuz we don't use it that often. However, I found myself in a situation, where we may need to use it heavily. I realized the only way to do this right in witango was in a bean.

It is very frustrating, unless you are just passing some simple int or string parameters and coming back out. There are text encoding issues, some datatypes just blow up, even booleans. So I went through the trial and error, and got jmagick running on my g5, and built a bean with one method at first. The method takes 4 parameters straight from witango, it takes an inpath, outpath, and width and height. The method takes them, and reads the inpath in jmagick, and outputs to the outpath, as a thumbnail. JMagick is a java wrapper for the imagemagick C api. The C API is IMO more powerful than the command line, and handles blobs and does some other cool stuff. But the IM API can be quite funky, and if you don't have a lot of experience with it, yoiu may pull some hair. But I have been using for 2 years, and know its ins and outs, so building the methods is just like my C methods, for the most part. The method worked great. It took 800ms to thumb a 6megapixel jpeg to 150x150, and the external action about a second. This may seem like little difference, but the main difference, is the bean instantiates in a few ms, and then if you load the object in a global var, it loads in 1ms. The external action, always takes about 30-50ms to just load, and then you have to deal with the env vars and all that. I will rarely use 6megapixel images, there will usually be less than 1megapixel. So a 40ms method, that takes 1ms of overhead, vs 30-50ms of overhead is very nice.

So with that success, and testing on my mac with tiger, and testing on our windows test server, I moved on to what I really wanted to do. I wanted to read an image from a db blob, pass the blob to the bean, and then manipulate the image as a blob, and return the blob back to witango, to either serve direct to browser, for on the fly manipulation, or put back in db, without ever writing to disk, for maximum efficiency. So I wrote the method. First problem, you can escape binary data in a var in witango, and you can't bind more than 32k. So you have to base64 the blob, in and out, because there are also text encoding issues. This is ok, cuz I figured with the efficiency of ZERO diks IO, and the bean almost ZERO overhead, i would still be in good shape. Well the method worked, but it took about 3 times as long, as having witango write the blob to disk, and using the first method, and then read it back in from disk. It wasn't the base64, witango is fast at that, and java even faster, with the opensource base64 class I included in my code. After much trial and error, it is just that the witango bean handler takes forever to pass data from witango back and forth to the bean. All that work for nothing. I hate working with trial and error methods, due to lack of documentation and support.

Anyway, I have the Mac XCode 2.2 project for this bean, and if someone promises to keep it public, make a opensource project or something, they can have it. Just contact me. I was planning to write methods for rotate, flp, flop, shadow, and several other IM methods I have, but I am done. At least if someone else uses it, it won't feel like such a waste.

PHP vs Witango ( The Pepsi Challenge? )

Now, we are moving to php, and that is not a secret, but over this year. With this issue, I did some extra homework, and setup a few Fedora Core 5 Apache 2.2/php5 servers. I did some tests, and well, it screams. I can use the GD graphics library in php, to do whatever I need, and it is VERY fast, as fast or faster than IM. So I got Ben, and the two of us built some apples to apples tests. As apples to apples as we could. First, php beat witango on anything image manipulation wise, cuz witango just can't do it without external help, and external methods have huge limitations, or very buggy. But what about just serving data? We needed to setup pure image servers, with some on the fly image transformation. So we setup 1 server, AMD2800, 2G ram, intel gigabit, running windows 2003 web edition, IIS 6, and witango 5.5.009. And php server, running Fedora Core 5, apache2.2/php5 with the same hardware. Now, we have tweaked our witango configs to the nth degree over years of witango experience. The linux server is the default install. ZERO performance tweaks, zero INI tweaks. The database server is our production mysql 5 server, with millions of thumbnails and images. The mysql server is tweaked, but both test servers are hitting it, so thats fair. All 3 machines are connected to the same gigabit switch with intel MT 1000 cards. We have some tafs, in use for many moons that serve thumbnails and images. We duplicated the functionality in PHP.

Again, this test was not set to prove anything, it was done solely to make the right decision as to how we were going to build our new image servers in the short term.

To keep as fair as possible, we made a page, served from our witango production servers, that made a table of 100 thumbnails, each of the thumbnail is a blob in the mysql db, and served by one of the above test servers. So the main page is hosted by a bank of witnago servers, but the images come from the witango test server above, or the php test server above, depending on which test you run. Well we were shocked by the results, PHP will fill your pipe as fast as your connection will allow. It is up to 3x faster than witango. Thats right, 3x.

http://ws.bighead.net/test/serveimage.taf

(be nice, if it gets hammered, I will have to pull it down.)

on most broadband connections, you will see a 15-25% or so speed increase with php. But if you run from the same network as the servers, so your connection is not the bottleneck, witango takes about 3000ms to load all the thumbnails, and php about 1000ms. Ben and I and my other devs were floored. We did NOTHING to the php test server, I loaded FC5, and dis yum install php php-mysql php- gd, and started it with apache. I can't wait to see what it will do as we tweak.

For the record, I don't think IIS apache is the issue. I have bench tested them against each other many times, and IIS will fill your pipe, it is very fast. Also, I do think linux makes some of this difference, cuz I know php doesn't run as fast on windows. But I do know witango is highly optimized for windows, and I chose windows for witango, because it has been historically the best platform for witango.

One more thing, witango is taking full advantage of persistent connections for this test. However, php is not. We are using the mysqli API for php, which does not support persistant connections. So php is making a connection for each thumbnail and closing it. That blows me away.

Well, we are now making the move to php a huge priority. Still looking for at least one more witango developer with php experience.

Also, if someone wants to question the testing we did, I would be happy to supply the code we used for a legitimate testing.

Oh man, and don't get me or Ben started on how nice the Zend/PHP studio is.

--

Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/




--

Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/

______________________________________________________________________ __ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

Bill

William M. Conlon, P.E., Ph.D.
To the Point
345 California Avenue Suite 2
Palo Alto, CA 94306
   vox:  650.327.2175 (direct)
   fax:  650.329.8335
mobile:  650.906.9929
e-mail:  mailto:[EMAIL PROTECTED]
   web:  http://www.tothept.com

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

Reply via email to