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... )
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
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
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
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
You're just too popular of a site! :)
Reply
Leave a comment