traffic manager 3, anyone use it?

[nemesis]

I am planning to buy it this week. Is it as good as rb4 or cju?

anybody using it?

btw, the url is tgpsoftware.com

[whoreans]

No SQL, which would only slow down the performance

PHP? Nice and simple language, but slow

i agree with those.. looks like that scripts all about proformance. go get it and let us know ;)

[Alvaro Jr]

100% recommended

[ServerGenius]

No SQL, which would only slow down the performance

- If you don't know how to use it if your Mysql gets out
performed by your apache webserver you're doing something
very wrong

PHP? Nice and simple language, but slow

- if you
don't know how to build up programs like with any other program languages


DynaMite

[]gw[]

hello,

traffic manager 3 doesnt use SQL nor PHP. It is coded in C and uses its own DB handling routines.

]gw[

[capribex]

also look at xxxmanager. he is posting here from time to time.

[DarkJedi]

they say HiOctane uses their script - but doesnt. He uses UCJ

http://submit.tgpsoftware.com/

[Tyrex]

submit.tgpsoftware.com is a list, with who we're sharig our galleries. Hi-octane was one of the first, he has special credits.

Kind regards,
Tyrex

[maui]

The only reason to do stuff like that in C is to prevent people from copying it accross the net.

Just because it is C does not make it fast... (probably they use a CGI interface)

PHP, Perl,Java are very well suited for a job like this, it just depends how you use it.

Some features of this product are quite interesting:

CHEAT PROTECTION

Written in pure C language (all other scripts still use perl coded cheat protection)
- does that make other cheat protection bad?
The most detailed and useful cheat logs on the market
- Proove?
Nightmare for every cheater.
-Why?

PROFESSIONALLY CODED IN C LANGUAGE
Coded in pure C language, the fastest programming language
- That depends how you use it. Maybe they should use assembler

No SQL, which would only slow down the performance, (we use
our own databases)
- That's right. That is why nobody is using SQL databases. ;-)
BTW, writing your own database is a piece of cake, right?

All other scripts are still coded 1/2 in perl. They use perl for cheat logs etc.
- So what? That just prooves that perl does the job.


Honestly, there must be like dozens of scripts floating around doing the job. Probably not with the same nice GUI, but $300
is quite some money, especially as it is "off-the-shelf" and not "custom made"

[Dammy]

Originally posted by maui

Honestly, there must be like dozens of scripts floating around doing the job. Probably not with the same nice GUI, but $300
is quite some money, especially as it is "off-the-shelf" and not "custom made"

Dude.. UCJ costs twice as much and doesn't do anything this script can't do. And it ain't custom made either...

[gotys]

Originally posted by maui
The only reason to do stuff like that in C is to prevent people from copying it accross the net.

Just because it is C does not make it fast... (probably they use a CGI interface)

PHP, Perl,Java are very well suited for a job like this, it just depends how you use it.

Some features of this product are quite interesting:

CHEAT PROTECTION

Written in pure C language (all other scripts still use perl coded cheat protection)
- does that make other cheat protection bad?
The most detailed and useful cheat logs on the market
- Proove?
Nightmare for every cheater.
-Why?

PROFESSIONALLY CODED IN C LANGUAGE
Coded in pure C language, the fastest programming language
- That depends how you use it. Maybe they should use assembler

No SQL, which would only slow down the performance, (we use
our own databases)
- That's right. That is why nobody is using SQL databases. ;-)
BTW, writing your own database is a piece of cake, right?

All other scripts are still coded 1/2 in perl. They use perl for cheat logs etc.
- So what? That just prooves that perl does the job.


Honestly, there must be like dozens of scripts floating around doing the job. Probably not with the same nice GUI, but $300
is quite some money, especially as it is "off-the-shelf" and not "custom made"

Yes, Assembler would be even faster than C, but that's about as fast as you could get. I odn't know any of you guys, nor I know Traffic Manager, but MAUI, I just wanted to tell you that C is indeed 5000% faster than Perl, PHP or other scripting language out there, because it's compiled and does not need to be translated upon running. Even when you compile Perl , it still needs to be translated and makes it slower. Assembler is cool C is second fastest, especially on Linux based system.

As far as MySQL goes, yes, it's a great database system, however for traffic trading scripts it's a nightmare. There is always something wrong with MySQL, it always goes down and it's a bitch to maintain. Tables get corrupted, and when it goes down indeed, your whole site is fucked until MySQL is restarted again. Flat text files will never go down, and if used properly can be faster than SQL. Traffic trade scripts don't need the powers of MySQL, therefore using SQL is a waste of resources.

Anyhow, I just hate it when people say that Perl or PHP is just as fast, cause it's not and never will be, no matter how you use it. You can write Hello World in Perl, and Hello World in C, and compare the speeds, and see yourself.

C ya

[Lane]

CGI scripts in C open a shell space everytime it is run, that slows it down a bit. But while it executes, its really fast.

A hello world program in PHP would consume less resources than the one in C. But if it does more complicated jobs and also if system operations are involved, C can beat PHP i believe.

[]gw[]

gotys:
However, I do have something to add here We are avoiding the use of variable lenght records (text files). Most of the database in TM3 is stored in fixed length binary structures (therefore no fgets() or such are needed)

Lane: Yes. That is true. But no parsing is required as opposed to PHP. That is certainly a gain.

DynaSpain: MySQL is great. But in my opinion it is a bit too complex for a only few bytes of data to be stored/loaded on every hit/click.

However, I've seen many great products using PHP/SQL db.
Keep up the good work!

]gw[

[KC]

Anyhow, I just hate it when people say that Perl or PHP is just as fast, cause it's not and never will be, no matter how you use it. You can write Hello World in Perl, and Hello World in C, and compare the speeds, and see yourself.

It totally depends on how the C code is written and on what level it's implemented. I'd be willing to bet that a PHP program with the Zend Optimizer could easily out perform a C CGI Program. I'm talking speed of hits and number of concurrent hits on a given set of hardware.

C (written properly) is fast... but CGI is SLOOOW.

Our counting engines are 100% C as a matter of fact. 100% C means, no apache and no cgi. Our counting engines listen for HTTP Connections and handles them accordingly. We're currently handling over 80,000,000 hits per day and could easily quadruple that on our current hardware.

If it were written any other way it would be less efficient, require more hardware and handle fewer hits.

There's my 2 cents.

-KC

[Lane]

its because you have it implemented as a module i guess.. then its as light as plain html.

[KC]

implemented as a module

Close... Most of it is located in a module in the FBSD OS..

[FATPad]

Perl and php as fast as C?

*snort* That's funny.

[Lane]

Originally posted by FATPad
Perl and php as fast as C?

*snort* That's funny.

no they are not..

C + CGI execution time sometimes takes longer than Perl or PHP + language parsing time

[Milton]

seams to be good

[FATPad]

Originally posted by Lane


no they are not..

C + CGI execution time sometimes takes longer than Perl or PHP + language parsing time

How many Perl scripts are executed as non CGI scripts? The same scripts could be rewritten in C and execute way faster. You can't compare CGI C scripts to non CGI Perl scripts.

What is the functionality level of a PHP script before the C speed overtakes it with the CGI execution time? I'm assuming it's not very much. So in theory, a "hello world" script written in PHP may in fact take less time and less server resources to run than an equivalent C script. But in the real world, that's meaningless.

In any real world, equal comparison, C will blow away PHP and Perl based on pure speed and server resources.

Having said that... I love PHP and think Perl has it's place. Writing them and maintaining them is a lot easier, and they don't need to be recompiled from server to server. That's their real advantage and that's why they're so widespread in use. Not performance. Performancewise C will crush anything except Assembler.

[dodo]

how much faster is getting text from a file rather than getting the same data from a mysql database.

and if it's really that fast... why are we using databases that gets corrupt ?

[]gw[]

dodo:
IMHO grabbing a few bytes of binary data from a file can be quite a bit faster than connecting to DB, initializing connection, executing query, returning the data, closing connection. Ofcourse SQL objects need to be linked into the executable which takes additional time when loading it (for each hit/click)

[FATPad]

Originally posted by dodo
how much faster is getting text from a file rather than getting the same data from a mysql database.

and if it's really that fast... why are we using databases that gets corrupt ?

Depends on a lot of factors.

A one line text file containing something simple like a hit count would be much faster to do as a simple text file.

A huge IP log of 300,000 IP's, plus associated browser info, referral URL's, date and time accessed and other info is a much different scenario.

[Lane]

Originally posted by FATPad


How many Perl scripts are executed as non CGI scripts? The same scripts could be rewritten in C and execute way faster. You can't compare CGI C scripts to non CGI Perl scripts.

What is the functionality level of a PHP script before the C speed overtakes it with the CGI execution time? I'm assuming it's not very much. So in theory, a "hello world" script written in PHP may in fact take less time and less server resources to run than an equivalent C script. But in the real world, that's meaningless.

In any real world, equal comparison, C will blow away PHP and Perl based on pure speed and server resources.

Having said that... I love PHP and think Perl has it's place. Writing them and maintaining them is a lot easier, and they don't need to be recompiled from server to server. That's their real advantage and that's why they're so widespread in use. Not performance. Performancewise C will crush anything except Assembler.

correct..

i said "sometimes" they are faster (and i assumed mod_perl, not CGI perl)

..and Assembler.. its not the only language that can beat C, but all those are a pain to code..

[XXXManager]

PPL.

I thought of writing the conclusion at the end -but most of you wont read through to that so.. the conclusions are:
I am quite sure TM3 will do the job as promised and (untill I am told otherwise) it is probably a great script. So are the other knowed senior scripts.

you are talking about that in a too conceptual level.
Perl/PHP/C/Asm - In the reality there is no such thing as a faster language (technically). all languages end up as machine-code.
The CPU dont know if a code is perl/c/asm. The only difference is how "efficient" is the translation to the machine-code.
With interperted languages - like PHP/perl/Python/... the code is compiled everytime the script is called (or interpeeted during execution in case of some languages). So to avoid that - some smart people cam with the (not so new) idea of compiling the script once and using that compiled code. for perl its called mod_perl. So the question remains - how much more efficient the compilation of C is over perl. the answer is - NOT MUCH MORE. Just a little. Maybe for "hello world" you will see a major difference but for more complicated/DB-based projects the difference will be small. "Hello world" like program would turn to 5000 bytes of machine code with Perl - and maybe 2000-4000 with C (depending on the compiler). Asm compiler will make such program even smaller - 1000 bytes maybe. The BIG question is - is it worth the hassle. Programming in Asm is VERY complicated compared to Perl. Show me someone who does a complicated (trading for example) script totally in Asm and Ill show you a dude with way too much spare time
Its more about good/efficient programming that it is about the complier and a good written script in mod_Perl will be much faster than a badly written one in C or even Asm. Writing in Asm is very laborious - even if you know real good what you are doing (trus me on that one). In most cases - its not worth it.
Im not telling anyone what to code with - but take into account that performance may not be that different between mod_perl and C - and may sometimes even be surprisingly NOT what you thought.

MySQL VS. Text/Binary file: Almost anyone using Text/Binary file of his own format over a DB dont know much about complicated projects programming/design. (I said Almost - so dont hang me).
As a matter of fact - It will VERY muchsurprise some of you - but ALL!! DataBases store the data in a Binary file
Claiming that self concieved binary/text-file is faster than a DB is not really an educated remark. The difference is not the data storing - BUT the data manipulation/retrieval/....
What matters is the DBE - DataBase Engine. That is the part who searches through the data, who deletes it, update and add to it.
If someone claims he dont use a DB - but use his own Text-file - he is actually saying he is using his own DBE. Are "you" saying you created a better DBE than MySQL? well if so - you are probably the guy who created MsSQL or Oracle
Unless you are dealing very low ammount of data you stand no change besting DBs like MySQL.
Not only you wont be faster - but most likely your script will be more likely to crash and corrupt the file AND you will never be scalable or robust AND will never be able to easily change your script to add more fields or features to it.
DBs werent created for the fun of it - they are an essential part of complicated data-centered projects and have no possible replacement.

Just clearing out some of people remarks...

whoreans: No SQL, which would only slow down the performance

What are you saying? that you hold all data in Memory? What about the log file? what if I want to search it? Are you gonna hold my 20GB log file in memory? You know how expensive 20GB Memory is? hehe. Ho - you store in in file? What algorithm do you use to search for a specific traffic event? Linear search - right? (with millions of I/O operations do the HardDrive)
DBs like MySQL not only boost performance, but it starts by making it possible in the first place.
If you are saying you hold the/some data in memory - you can still do that with MySQL backing you up for storing the data. Not only this - but mySQL allows you to use an ALL-IN-Memory tables and even for the regular tables it holds indexses and table cache in memory.
There is an overhead of connecting to the DB handler - but that is nothing compared to the overhead of using ones own inefficient DB handling routines.
I dont know of any major system in the world who uses its own file-based DB. ask yourself why.

Gotys:
As far as MySQL goes, yes, it's a great database system, however for traffic trading scripts it's a nightmare. There is always something wrong with MySQL, it always goes down and it's a bitch to maintain. Tables get corrupted, and when it goes down indeed, your whole site is fucked until MySQL is restarted again. Flat text files will never go down, and if used properly can be faster than SQL. Traffic trade scripts don't need the powers of MySQL, therefore using SQL is a waste of resources.

Anyhow, I just hate it when people say that Perl or PHP is just as fast, cause it's not and never will be, no matter how you use it. You can write Hello World in Perl, and Hello World in C, and compare the speeds, and see yourself.

1. treated right and programmed with correctly - mySQL is a VERY stable database. That is a fact beinged examined MANY times in MANY occasions. Oracle/MSSQL are even more stable (but slower and need more maintnance). Nothing ever is wrong with MySQL - and its uptime cant be matched by any binary-file self created DB. If MySQL table gets corrupted or DB server crashes - indeed you have to wait until it up again. But that is the same and even worse for Text/binary-files! Not only that - but with BDE you can have a cluster or a parallel server asuring you that even if one crashes - the other/s still work. You can NEVER do that wil simple file.
Also - How do you insure that several processes trying to increase a counter wont mess eachother's job? What method do you use? What locking? Do you use little-endian? How can you make sure two processes dont try to access the file for write at the same time? - Are you telling me you write better handlers than well-written DBs like MySQL (with InnoDB handlers). I know thats lots of thechnical words - but trust me - any text/bibary file DB is slower and less stable than the knowen DBs - any of them.
Try to manage 5 million records DB with your own writter Text-file DB and tell me which is more resource clogging.
About C Vs. perl. Try writing mod_perl apache module writing Hello world versus C CGI script and tell me which is faster. Its all a question of what you compare.

]gw[
DynaSpain: MySQL is great. But in my opinion it is a bit too complex for a only few bytes of data to be stored/loaded on every hit/click.

Correct - for a single counter script you are right. But if you want to count 100,000,000 clicks a day for 50,000 sites PLUS save each event to be able to analyze things like coutry of origin, hourly distribution,... would you still use text files? ;)

dodo
how much faster is getting text from a file rather than getting the same data from a mysql database.
and if it's really that fast... why are we using databases that gets corrupt ?

Readind single-byte file will be faster than a byte from a DB.
Reading 1 record out of a 2 billion records - from a file will take you several hours as opposed to 0.1 seconds from a DB (if indexed right).
Text-files are more corruptable than DBs. most likely they have no recovery mechanisms like DBs have and are not ACID as some DBs are (which means "a motherfuckin reliable-stable-noncorruptable DB [oracle, MSSql...])
Its all a question of design and programming consideration.

In conclusion - just to add up the two points - anyone who tries to program his script EVEN with binary-file DB of his own and EVEN with Asm - when comes to complicated script (not a simple counter or 100-trades-max trading script) - does not stand a chance beating MySQL/mod_Perl well written script.
Trust me (and many others) on that.

[Due]

bla bla bla PHP bla bla combiled bla bla Perl bla bla MySQL bla bla persistant bla bla C++ bla bla fast.
Anyway.
This is the load average for a server pushing 300K with TrafficManager3 having all clickable links going through the outgoing script and it uses the internal gallery redirector:
load averages: 0.34, 0.49, 0.54 and 88.1% idle CPU.
So I think it does the job even though bla bla PHP bla bla Mod_perl uppercase apache and whatever

[swedguy]

Your script written in PHP sucks. NO, Your script written in C sucks even more.



(Sorry, couldn't find a smily with 2 smilies fighting in the sandbox)