|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools |
Rating:
|
Display Modes |
|
|
|
#1
|
|||
|
|||
|
Re: I think we found our limit ..
I know that a lot of other people on my team search ChiefDelphi for information (especially the picture galleries), but I'm the only member with an active account. Although I would kind of like them to register, it's nice to be able to just quickly check ChiefDelphi from a school or otherwise shared computer without having to log in.
That being said, I wouldn't object to temporary restrictions on guest browsing, or something similar to Amanda Morrison's idea. I'd rather have the site only available to registered users than to no users at all. |
|
#2
|
|||||
|
|||||
|
Re: I think we found our limit ..
I'll elaborate a little more, I suppose.
Right now we have one Intel(R) Celeron(R) CPU 2.40GHz. In a "perfect world"TM adding one more, along with another 1/2 to 1GB of RAM would make the site load much faster. Unfortunately, as it was mentioned above in a reply, we really only need that about a dozen times spread around a 3 month period. So, it's not really worth the monthly upgrade cost (yeah, we rent the server, so monthly upgrade fees are ridiculous) in the long run. So. I'm looking at vBulletin code right now, to see if Registered members get priority over guests. All it does is count the sessions in the session table (ones that may be expired too) and if its over 300 (or whatever I set it to) then it denies you. So, right now there are 85 active people on .. but there are 302 rows in the session table, so it (incorrectly) denies people. You all made some very good assumptions and had good ideas. It is possible to prioritize who it denies, based on registered vs. guests, or reputation, or by who has a longer username, or by whose team has won more matches in 2002. Anything is possible. .. well, almost anything. I took off the limitation .. there's probably a better way to handle this. I'll have to think about it tomorrow, when I'm looking over the apache configuration. Hopefully some configuration optimization will help fix this. If we do go with a limitation, though, it really would only happen about 1/2 dozen times a year. Kickoff. Ship date. First regional weekend. Championship Event. Pre-Kickoff. So, it's not like we'd be constantly blocking guests. As for donations and ChiefDelphi merchandise to help with the funding .. we know that there are some of you who are willing to help out, and if that time ever comes we know who to turn to. Thank you. ![]() Last edited by Brandon Martus : 23-02-2005 at 00:58. |
|
#3
|
|||||
|
|||||
|
Re: I think we found our limit ..
Quote:
![]() Woah, 1:28am. Work @ 8. Whoops. |
|
#4
|
|||
|
|||
|
Re: I think we found our limit ..
Quote:
The Zend Optimizer is very good at increasing the load that PHP can handle. It is one of those rare products which performs nearly as well as advertized. That said, Eaccelerator is even faster. It is a fork of the Turck mmcache project, which is used by Wikipedia. I have a large amount of data here from some comparisons of Zend Optimizer and Eaccelerator 0.9.2, if you are interested in looking at it. A quick summary of the data - Eaccelerator is statistically significantly faster than the Zend Optimizer 2.5.7 in database operations with MySQL under PHP 4 and 5, "improved" MySQL operations in PHP5, and file I/O under PHP4. The differences between the two are statistically insignificant when the php scripts are forking processes, text processing, and php control statements (eg phpinfo). You might want to look into it. There is something else you might want to try. If you are using Apache 2, try mod_cache and mod_mem_cache together. You can set up Apache to cache all content coming from Chiefdelphi. This is not difficult to set up at all and can help quite a bit. If you are still running Apache 1.3.x, you would have to use mod_mmap_static. You can convert all archived/closed threads to static pages (just run the php CLI executable on those threads and save the output) and then use mmap_static to cache it. That would increase the speed of access to closed/old threads tremendously, while taking load off php. Whatever you plan on using to increase capacity, good luck. Chiefdelphi.com is a tremendous resource to the FIRST community and we thank you for you great work. And I would buy a CD t-shirt too. =) |
|
#5
|
|||||
|
|||||
|
Re: I think we found our limit ..
Quote:
Thanks! ![]() |
|
#6
|
|||||
|
|||||
|
Re: I think we found our limit ..
I was thinking about the Tshirt idea, and I though it would be cool to make thee Tshirts with some of the choiciest Spotlight posts. For example:
This looks like a job for duct tape! In Martus we trust. Programmers fuel: pure, unadulterated caffeinated beverages. Blame it on the programmer. ...etc.... I think that would be cool. Then you could do promos like "Collect all 30" or whatever ![]() Yeah, tell me where to Paypal money. Dave |
|
#7
|
|||
|
|||
|
even though ChiefDelphi is a good community, I would like to invite others to join It's Technical!, found at http://technical.aceshigh176.com
It's Technical! is a support site for the FIRST robotics community that covers everything including pneumatics, electrical, programming, etc.. It also includes information for vEx, FLL, EDU/Robovation, etc.. It's Technical! is a subsidary of Aces High 176. Stop by and open an account today! |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Robot Weight Limit: Rule Conflict | Specialagentjim | Rules/Strategy | 10 | 06-08-2005 17:52 |
| 32k controller limit | flounder22001 | Programming | 9 | 07-02-2005 00:01 |
| Robot Controller File Size Limit ?? | RoboGeek | Programming | 1 | 17-01-2005 19:59 |
| material cost limit | haverfordfords | Fundraising | 3 | 06-12-2004 19:21 |
| Limit Switches help. | Xufer | Programming | 9 | 21-04-2004 21:21 |