The reason why Search is down is because of the Board Leech sites. - Page 4 - GoFuckYourself.com

azguy · 05-20-2005, 08:33 PM

Quote:

Originally Posted by notjoe

Why dont you go take a walk beyond the israel border while screaming "I'm a jew I'm a jew"

AlienQ is from Israel?

notjoe · 05-20-2005, 08:33 PM

And before you go yelling to lensman what a racist i am and how i should be banned keep in mind i'm a jew myself

SureFire · 05-20-2005, 08:35 PM

Quote:

Originally Posted by azguy

AlienQ is just trying to secure a guaranteed unban from Lensman in case the situation presents itself again.

I guess he didn't watch Steven Segal's movie...Above The Law

gecko · 05-20-2005, 09:25 PM

Quote:

Originally Posted by holograph

I dont think he has a problem with STB being banned by GFY

He would have not started the other thread now would he?

AlienQ - BANNED FOR LIFE · 05-20-2005, 09:28 PM

Quote:

Originally Posted by notjoe

Why dont you go take a walk beyond the israel border while screaming "I'm a jew I'm a jew"

Sounds like fun.

goBigtime · 05-20-2005, 10:04 PM

Quote:

Originally Posted by josian

Contact me Lens, I have a way to avoid that quick and easy.

You're going to tell him to do something with .htaccess aren't you?

will76 · 05-20-2005, 10:21 PM

Quote:

Originally Posted by AlienQ

When I type and express my words and thoughts they are my words and thoughts. Mine.

if you want to keep them then you should keep them to yourself

when you post them here on a public forum you are giving them away. Consult with an attorney before you reply back please, before you choke on that foot.

Juicy D. Links · 05-21-2005, 11:29 AM

Manowar · 05-21-2005, 11:32 AM

Quote:

Originally Posted by Juicy D. Links

azguy · 05-21-2005, 01:07 PM

One thing I must add. You're looking at this issue from the wrong perspective, IMHO. I'm not referring specifically to the problems you are having with the search due to various service abuses, but to the overall mentality I'm sensing here.

GFY has become a major resource in this industry, and while it attracts many users on a daily (read: hourly) basis, it's also an opportunity for others with some entrepreneurial spirit to further enhance the board for the benefit of everyone else.

Those who seek to do so for legitimate purposes do not try to steal your traffic or content. It is simply an opportunity to make a buck while introducing useful utilities that are not currently available directly from GFY. STBoards with their tracking capabilities and the GFYStats project BlueWire is working on are only two examples.

Do you think eBay was crying when people developed various APIs and stand-alone services to remotely search items, image uploads/storage, or more advanced auction monitoring features? Nope. Because they were looking at the big picture. The same goes for Amazon. That's why those companies are still here.

Varius · 05-21-2005, 01:42 PM

I'm just curious if GFY's tech have tried yet to convert the board tables into InnoDB. It's quick and painless to do, and is built exactly for millions of rows of data and providing speed.

I would assume they are already using row-level locking even with INNODB (if not, there's 99% of your problem right there), but InnoDB can still provide immediate advantages without touching the vb code at all.

They should atleast try a benchmark: copy their largest table and make it InnoDB, then run a few searches on the current version versus the InnoDB version and see what your results look like.

Small tables have been proven faster in INNODB from my experience, but once you get past 500,000 rows or so, InnoDB outperforms it. With 5-10 million rows or more, it outperforms it drastically.

Anyhow, if they want to try, "ALTER TABLE tbl_name TYPE=InnoDB" is all you need

goBigtime · 05-21-2005, 05:38 PM

Quote:

Originally Posted by Varius

I'm just curious if GFY's tech have tried yet to convert the board tables into InnoDB. It's quick and painless to do, and is built exactly for millions of rows of data and providing speed.

Last time I checked...

INNODB = faster reads (use for read-heavy tables)

InnoDB = faster writes (use for write-heavy tables)

Maybe it's different now?... I initially got this information from a guy running one of the largest forums on the net. That was basically his nutshell response. He does use InnoDB, but only for write-heavy tables. The guy has a cluster of like... 40 servers or something.

Varius · 05-21-2005, 06:44 PM

Quote:

Originally Posted by goBigtime

Last time I checked...

INNODB = faster reads (use for read-heavy tables)

InnoDB = faster writes (use for write-heavy tables)

Maybe it's different now?... I initially got this information from a guy running one of the largest forums on the net. That was basically his nutshell response. He does use InnoDB, but only for write-heavy tables. The guy has a cluster of like... 40 servers or something.

From my experience with it, I've found that for selects, InnoDB is faster when the table in question is larger and is written to often. When the table is smaller or not frequently modified, then myisam is faster. Ofcourse InnoDB has other advantages like recovery features, transaction support, etc...

Right now though we're checking out NDB type for use with MySQL Cluster.....hopefully it outperforms all the other types by leaps and bounds

notjoe · 05-21-2005, 06:50 PM

I believe the (main) difference between innodb and myisam is that there is row locking support with innodb and not with myisam. Multiple rows can be updated concurrently where as with myisam a thread needs exclusive access to the table.

goBigtime · 05-21-2005, 07:18 PM

Quote:

Originally Posted by Varius

Right now though we're checking out NDB type for use with MySQL Cluster.....hopefully it outperforms all the other types by leaps and bounds

mysql clusters can be awesome if you feed them lots of money for ram

fireorange · 05-21-2005, 07:36 PM

Quote:

Originally Posted by Varius

I'm just curious if GFY's tech have tried yet to convert the board tables into InnoDB. It's quick and painless to do, and is built exactly for millions of rows of data and providing speed.

I would assume they are already using row-level locking even with INNODB (if not, there's 99% of your problem right there), but InnoDB can still provide immediate advantages without touching the vb code at all.

They should atleast try a benchmark: copy their largest table and make it InnoDB, then run a few searches on the current version versus the InnoDB version and see what your results look like.

Small tables have been proven faster in INNODB from my experience, but once you get past 500,000 rows or so, InnoDB outperforms it. With 5-10 million rows or more, it outperforms it drastically.

Anyhow, if they want to try, "ALTER TABLE tbl_name TYPE=InnoDB" is all you need

Don't be a monkey, you think you can teach the admins something? As if they 're newbs?

azguy · 05-21-2005, 07:41 PM

Quote:

Originally Posted by fireorange

Don't be a monkey, you think you can teach the admins something? As if they 're newbs?

Take it easy man. GFY admins are still merely human beings.. Everyone could use some advices now and then.

tony286 · 05-21-2005, 07:41 PM

thanks lens it explains alot, get those fuckers lol

goBigtime · 05-21-2005, 08:26 PM

Quote:

Originally Posted by azguy

Take it easy man. GFY admins are still merely human beings.. Everyone could use some advices now and then.

.....

Inde · 05-21-2005, 09:33 PM

Quote:

Originally Posted by azguy

Take it easy man. GFY admins are still merely human beings.. Everyone could use some advices now and then.

xclusive · 05-22-2005, 12:00 AM

Good to know what is going down I look forward to a faster stronger GFY soon as you take care of the issues.

BlueWire · 05-22-2005, 12:05 AM

I'd like to know if our upcoming GFY stats project applies to this...

We are trying to provide this as a service to be something 'fun' for board members and we thought it would be useful for the sig market...

Our script doesnt provide search function or anything like that. Just gives stats on posters and only spiders once per week at an obscure time...

Here's the prototype..any thoughts?

http://www.bluewiredevelopment.com/w...=weekly&week=3

Lensman · 05-22-2005, 12:22 AM

Quote:

Originally Posted by BlueWire

I'd like to know if our upcoming GFY stats project applies to this...

We are trying to provide this as a service to be something 'fun' for board members and we thought it would be useful for the sig market...

Our script doesnt provide search function or anything like that. Just gives stats on posters and only spiders once per week at an obscure time...

Here's the prototype..any thoughts?

http://www.bluewiredevelopment.com/w...=weekly&week=3

Of course it applies, but it's an interesting idea, and maybe we can do something officially together.

BlueWire · 05-22-2005, 01:28 AM

Quote:

Originally Posted by Lensman

Of course it applies, but it's an interesting idea, and maybe we can do something officially together.

I would like to speak with you sometime Lensman. You're a hard time to get a hold of

I had mentioned the idea to Eric because we're doing some design work for you guys right now....He said i'd need to talk to you.

Hopefully we can talk sometime on icq or phone. Thanks

xclusive · 05-22-2005, 01:32 AM

BlueWire I hope you guys can get this up and going, I love the concept of your little side project. I've been a stats guy for years and get enjoyment from them. Keep up the great work.

BlueWire · 05-22-2005, 01:35 AM

Quote:

Originally Posted by xclusive

BlueWire I hope you guys can get this up and going, I love the concept of your little side project. I've been a stats guy for years and get enjoyment from them. Keep up the great work.

Thanks

I hope so too. I really thought it would be cool ....AND i have even more ideas for stats we can track based off having the info that our spider currently collects....They would be able to show the cross between # of posts and quality of each post...

...of course...it'd be that much more effective if it was plugged right into the database *cough*

Varius · 05-22-2005, 01:35 AM

Quote:

Originally Posted by notjoe

I believe the (main) difference between innodb and myisam is that there is row locking support with innodb and not with myisam. Multiple rows can be updated concurrently where as with myisam a thread needs exclusive access to the table.

I believe the last few versions of mysql, myisam does support row-level locking now though....

Varius · 05-22-2005, 01:38 AM

Quote:

Originally Posted by fireorange

Don't be a monkey, you think you can teach the admins something? As if they 're newbs?

Doesn't require them being newbs...I just know I've had a ton of experience now with MySQL and large tables/database-intensive search queries, have already consulted with top developers and people who helped develop MySQL, etc...

Anyhow was just something I already offered to them to try awhile ago, was wondering if they ever got around to trying it out...

notjoe · 05-22-2005, 05:11 AM

Quote:

Originally Posted by Varius

I believe the last few versions of mysql, myisam does support row-level locking now though....

I dont think so, atleast not in the production code they release...Googling for it seems to show noting which says myisam supports row locking.

"Currently, MySQL supports table-level locking for ISAM, INNODB, and MEMORY (HEAP) tables, page-level locking for BDB tables, and row-level locking for InnoDB tables. "

http://dev.mysql.com/doc/mysql/en/internal-locking.html

Varius · 05-22-2005, 01:36 PM

Quote:

Originally Posted by notjoe

I dont think so, atleast not in the production code they release...Googling for it seems to show noting which says myisam supports row locking.

"Currently, MySQL supports table-level locking for ISAM, INNODB, and MEMORY (HEAP) tables, page-level locking for BDB tables, and row-level locking for InnoDB tables. "

http://dev.mysql.com/doc/mysql/en/internal-locking.html

Hrmm, I may have seen it in beta versions then perhaps of MySQL 5.....or maybe not. In any case, we prefer using InnoDB ourselves for the row-locking, transactions and performance on large tables. I only use myisam still on very small, static tables (like say a table with categories, statuses, etc...that have < 100 rows and barely ever change). I've also found myisam tables have a much greater chance for corruption than InnoDB tables do.

Violetta · 05-22-2005, 01:44 PM

anyway... nice job Lens!

Manowar · 05-22-2005, 01:48 PM

gfy stats looks cool

pxxx · 05-22-2005, 02:00 PM

Thanks for the update Lens.

Rui · 05-22-2005, 02:06 PM

Quote:

Originally Posted by BlueWire

I'd like to know if our upcoming GFY stats project applies to this...

We are trying to provide this as a service to be something 'fun' for board members and we thought it would be useful for the sig market...

Our script doesnt provide search function or anything like that. Just gives stats on posters and only spiders once per week at an obscure time...

Here's the prototype..any thoughts?

http://www.bluewiredevelopment.com/w...=weekly&week=3

Nice project you have there, all the best regarding its development

BlueWire · 05-22-2005, 02:56 PM

Quote:

Originally Posted by Rui

Nice project you have there, all the best regarding its development

Thanks...I hope we get to release it

..also, if i might have a blatent plug right now. One of the Bluewire programming teams is opening up and we're accepting custom projects for them right now....PHP, PERL/CGI, MYSQL, FlashCom Server, Flash Remoting

05-21-2005, 01:42 PM	#161
Varius Confirmed User Industry Role: Join Date: Jun 2004 Location: New York, NY Posts: 6,890	I'm just curious if GFY's tech have tried yet to convert the board tables into InnoDB. It's quick and painless to do, and is built exactly for millions of rows of data and providing speed. I would assume they are already using row-level locking even with INNODB (if not, there's 99% of your problem right there), but InnoDB can still provide immediate advantages without touching the vb code at all. They should atleast try a benchmark: copy their largest table and make it InnoDB, then run a few searches on the current version versus the InnoDB version and see what your results look like. Small tables have been proven faster in INNODB from my experience, but once you get past 500,000 rows or so, InnoDB outperforms it. With 5-10 million rows or more, it outperforms it drastically. Anyhow, if they want to try, "ALTER TABLE tbl_name TYPE=InnoDB" is all you need __________________ Skype variuscr - Email varius AT gmail

05-22-2005, 12:00 AM	#171
xclusive Too lazy to set a custom title Join Date: Apr 2004 Location: Buffalo, NY Posts: 35,218	Good to know what is going down I look forward to a faster stronger GFY soon as you take care of the issues. __________________ I support MediumPimpin.com / Shemp's Outlawtgp.com /

05-22-2005, 01:32 AM	#175
xclusive Too lazy to set a custom title Join Date: Apr 2004 Location: Buffalo, NY Posts: 35,218	BlueWire I hope you guys can get this up and going, I love the concept of your little side project. I've been a stats guy for years and get enjoyment from them. Keep up the great work. __________________ I support MediumPimpin.com / Shemp's Outlawtgp.com /

05-22-2005, 01:44 PM	#181
Violetta Affiliate Join Date: Jul 2004 Posts: 28,735	anyway... nice job Lens! __________________ M&A Queen

05-20-2005, 08:33 PM	#152
notjoe Confirmed User Industry Role: Join Date: May 2002 Location: Toronto, Canada Posts: 5,599	And before you go yelling to lensman what a racist i am and how i should be banned keep in mind i'm a jew myself

05-21-2005, 11:29 AM	#158
Juicy D. Links So Fucking Banned Industry Role: Join Date: Apr 2001 Location: N.Y. -Long Island -- Posts: 122,992

05-21-2005, 01:07 PM	#160
azguy Confirmed User Join Date: Nov 2004 Location: Scottsdale, AZ Posts: 5,167	One thing I must add. You're looking at this issue from the wrong perspective, IMHO. I'm not referring specifically to the problems you are having with the search due to various service abuses, but to the overall mentality I'm sensing here. GFY has become a major resource in this industry, and while it attracts many users on a daily (read: hourly) basis, it's also an opportunity for others with some entrepreneurial spirit to further enhance the board for the benefit of everyone else. Those who seek to do so for legitimate purposes do not try to steal your traffic or content. It is simply an opportunity to make a buck while introducing useful utilities that are not currently available directly from GFY. STBoards with their tracking capabilities and the GFYStats project BlueWire is working on are only two examples. Do you think eBay was crying when people developed various APIs and stand-alone services to remotely search items, image uploads/storage, or more advanced auction monitoring features? Nope. Because they were looking at the big picture. The same goes for Amazon. That's why those companies are still here.

05-21-2005, 06:50 PM	#164
notjoe Confirmed User Industry Role: Join Date: May 2002 Location: Toronto, Canada Posts: 5,599	I believe the (main) difference between innodb and myisam is that there is row locking support with innodb and not with myisam. Multiple rows can be updated concurrently where as with myisam a thread needs exclusive access to the table.

05-21-2005, 07:41 PM	#168
tony286 lurker Industry Role: Join Date: Aug 2002 Location: atlanta Posts: 57,021	thanks lens it explains alot, get those fuckers lol

05-22-2005, 12:05 AM	#172
BlueWire Confirmed User Join Date: Nov 2004 Posts: 4,628	I'd like to know if our upcoming GFY stats project applies to this... We are trying to provide this as a service to be something 'fun' for board members and we thought it would be useful for the sig market... Our script doesnt provide search function or anything like that. Just gives stats on posters and only spiders once per week at an obscure time... Here's the prototype..any thoughts? http://www.bluewiredevelopment.com/w...=weekly&week=3

05-22-2005, 01:48 PM	#182
Manowar jellyfish Join Date: Dec 2003 Posts: 71,528	gfy stats looks cool

05-22-2005, 02:00 PM	#183
pxxx First African GFY Member Join Date: Mar 2004 Location: New Jersey Posts: 12,114	Thanks for the update Lens.