Rubifruit may have to close.

Apr 06, 2009 22:37

Edit (or, before you use the word "bandwidth")
I've said this before, but the bandwidth is not a problem. It's the RAM usage and resources that cost money. Every time we display a banner hosted via Rubifruit, our server has to make a calculation. That calculation takes up processing power, usually in the form of RAM ( Read more... )

Leave a comment

grimepoch April 7 2009, 04:35:37 UTC
What kind of calculations are you doing? In fact, every file, image, text, etc goes through the processor on its way from the hard drive to the network connection. This is why many websites, like eBay and the like, put a lot of the information into memory (cache) so the images stay persistent and don't require access to the hard drive which DOES block CPU performance and degrade the operation of a machine (IO blocking).

So I say, what exactly are you doing at rubifruit that is so calculation intensive? Are you keeping a record of how many times a banner is hit? dereferencing a banner click to a re-direct to another website? Are you taking a hit on database access? What kind of CGI infrastructure are you using? Perl, Python, and are you getting bottlenecks for the performance of the CGI? For instance, we switched from Perl to modPerl on a site and had a MASSIVE improvement in performance. Even database access when your database gets bigger or you are getting lots of hits can really degrade performance.

The other thing is this, if your CGI code loads for one user and required 200k to process an images, or load a database, if 10 people are doing this simultaneously, thats 2Meg. It's a function of how long your code has to run for, and what the peak is of people using the code. First thing I would look at is figuring out if there is any way to speed up or enhance the CGI portion of your site first. Simple things like a lint checker or profiler can really find bottlenecks in your code. And worse, for databases, when they need to be locked, when you have lots of users this can be HORRIBLE.

Reply

crowhen April 7 2009, 14:22:55 UTC
We're PHP-based, not CGI-based. The code keeps track of every impression and click on every banner. Beyond that, it's beyond me. I'm not a programmer. I use Easy Banner Pro, though, I can tell you that.

I've spoken several time with the host and the person who made the script, and we've modified it a few times to improve performance. But then there are 20 people reading through the Penny and Aggie archives and another 40 over at Yume, indeed it does add up fast!

Reply

grimepoch April 7 2009, 16:23:33 UTC
My understanding of PHP is that it depends if the interpreter is compiled into the web server (I am assuming Apache) or not. CGI just indicates when the webserver calls a program to generate output, and you can in fact call PHP, Perl, native code, anything you want! (provided the webserver allows it to run). So you may or may not be running all inside of apache. I am also not aware which one has better performance or even if there is an option to run either with DreamHost, but I am sure there is a lot of discussion about this on the web.

But that aside, another huge problem is if each time the php script is called, it has to lock and open a file to store statistics about the operation. If 40 people need to access that file, each one is going to have to wait while the others are waiting, and each of those has to open the file, read the contents, change the contents, write out the file. While that is expensive enough as it is, again, the whole process blocks.

One thing you could try doing, if it is free (your site), and you are not wanting to get rid of it, you could try and not keep statistics of impressions for awhile and see how the performance is.

Unfortunately, since you are probably selecting a random banner all the time, you can NEVER get the advantage of caching on the server OR the client web browser.

The other thing I would look into, and I don't know the code, but to make sure the image doesn't actually process through your script itself, but instead, the randomness generates HTML code that points to the image with a unique name so that if the same banner gets called on a computer more than once, it will be cached locally and you wont take additional hits. That of course is probably a question for the code maintainer :)

Reply

crowhen April 7 2009, 16:36:58 UTC
Yes, we're using Apache, I'm pretty sure that's what Dreamhost uses.

Well, we kind of have to keep the statistics of the impressions. That's how we know how many impressions to hand out. See, users only get impressions if the banners on their sites generate clicks. 1 click gives them 200 impressions. This encourages people to put banners where they will be seen as well as make their banners look interesting. So we have to keep track of every impression AND every click.

Reply

grimepoch April 7 2009, 17:10:26 UTC
That certainly makes sense with the need then to have that ability. Unfortunately, only the programmer is going to be able to tell you were the bottle necks are, and, trying to set-up a test environment to reproduce the problem might be a pain.

You're just too popular of a site! :)

Reply


Leave a comment

Up