Trade Script Recommendations
 

Hi all

Would like some trade script recommendations. I have a couple of sites that have outgrown their free trade scripts. What would you recommend.. non PHP / MYSQL ones preferred....

I currently use TM3 on a couple of sites.. but open to all that are out there!

thanks

Nurgle

I have UCJ and TM3, I'm partial to UCJ because I've used it for a lot longer, but TM3 seems to be pretty good as well. So, if you already have TM3.. go for UCJ

Is it usually a requirement of a trade script for the referring site to *not* be displayed in any trading links that the user sees? If anyone can fill me in on the theories behind modern day link trading I would love to hear it. But from what I have read so far, the only load bearing function of the script is in the logging of clicks. I rarely support php/asp for anything other than admin/management scripts - unless you have a site that gets some insignificant amount of traffic. In those cases I go hog wild with dynamic creation. The dynamic creation of anything takes a lot of juice. What in a link trade script needs to be dynamically created?

Thats why i dont want it... most free ones utilisa MYSQL.. probably as its easy to build with

Nurgle

this needs a bump!

best non-free one ive seen so far is tm3

the paid KCJ version ;) written in C++ and no MySQl required

whats this for then mate?

"MySQL" - common Linux database engine used by KCJ for hourly/dailiy statistics logs.

Nurgle

So far, you don't even have a blacklist feature yet?

And, ehm, v1.32: We have fixed the bug causing the script to gobble CPU resources at the hosting. :helpme

woops guys :eek7 Thats just we might have forgotten to mention this but in 1.32 MySQL is not USED and black list will be added in the new version we are releasing this week. any more remarks?

hm I've just checked the site again adn that's what it says about MySQL - KCJ stores all of its data internally and does not use MySQL at all (!). :)

From your comparison page:
17. Doesn't use MySQL for work + + will be added in 1.4 + + - ? - ? - - -

Btw, it seems a bit like the product isn't completely finished yet, so why release it before you have a full working beta-tested finished version with all essential features?

we don't consider black list such an important feature to delay the script's release and we hope the version we have now has enough features to start trade and keep traffic well :) and besides we are planning a few updates in the very next future where all the missing features will be added. And thanks for pointing at our bug concerning information in the comparison table :) we'll correct it

I think it is quite ok to use mysql to store and perform statistical analysis...as well as account info in "moderately-critical" (is that an oximoron?) applications. Future versions of MySQL will certainly change my views on this. You have to look at each application and how it uses MySQL to really judge if it has what you need. Writing a web admin for 10 users in c is a bit of an overkill if you ask me. On the other hand, something like logging is a great reason to use a compiled c application...as the overhead without having to compile at runtime (as well as connect to a db/parse an sql statement) is minimal. I think it is safe to say that connecting to mysql to perform logging, even with persistent connections, should be reserved for sites that won't experience heavy traffic loads. MySQL connections are expensive - there is no way to fix that. The connection alone to MySQL takes up half of the total time of one insert (give or take based on data size, which should be a handful of bytes in this case). But still, from a developer standpoint, MySQL's load data infile is 3 times as fast as an equal number of inserts in the import file. What is *so* wrong with a 10 minute interval between stat builds? For the latency benefits alone - it is a small price to pay. So why can't compiled c/c++ logging to flat file and periodic import to mysql be some sort of standard? Moreso, if you've got a site fielding a million unique visitors a day...you need not waste time toying with this thread. Certainly you have a few billion lei to drop on some romanian c wiz that can write you a serious apache module...or whatever.

Can I also mention that, after looking at tm3, I considered giving up on writing scripts for this industry segment entirely. Those guys have a completely sweet product with some serious development time. It is positively spectacular. I only hope to have a competitive edge with slick user-friendly admin screens, competitive functionality, and reasonable pricing. I certainly hope it pays off because I have been on ap|tgp like crazy for months. It would be nice to have *some* feedback regarding feature requests. I can code anything in perl/php/asp over MySQL or SQL Server/t-sql.

AP