Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

SI - Site Forums : Silicon Investor - Legacy Interface Discussion (2004-2011) -- Ignore unavailable to you. Want to Upgrade?

To: SI Dave who wrote (256)	4/8/2004 10:36:22 AM
From: SI Bob	Read Replies (1) \| Respond to of 6035

Nah. An hour later I came up with a different different approach and it's working beautifully. Folder_Links is updating on the Dev site hourly now and takes barely under a minute to complete. If you hit the site right on the hour, you could very well have your Inbox there go to zero, then a minute later it's fully populated. But keep in mind that there's still the disconnect between the number reported and the number of public messages available to you on the Dev site. I'm still having it lag by 500 messages. Later, I'll look into making it lag by 20 minutes rather than 500 messages. I think it'll be more expensive, but because of the other import tweaks I made last night, we can probably afford it. The regular update (bringing in new deleted messages, private messages, updating stats_messages_date (a table that eventually won't be used), and new public messages (minus the most recent 500), and updating the message counts and last post date/time of each subject now takes 1 1/2 minutes. You won't believe it when I tell you why some public messages were appearing in inboxes incorrectly. Folder_links points to a message number and identifies a message type using a single character. I've finally figured out what the message type characters stand for. They weren't obvious. So what was happening was your inbox was showing public messages having the same message number as private messages in your inbox. Unrelated private and public messages can have the same numbers because they're in separate tables of similar structure. The reason it was happened with public messages but not private is that I'm extra paranoid where private messages were concerned and was already double-checking to make sure each private message really did belong to you. Last night I fixed the problem by including a join to the public message table to ensure the receipient really was the Inbox reader. This morning I'll change it to use the Type field in folder_links since I understand it now, which'll make the Inbox queries much less expensive. That's my first task of the day. Next will be finishing Next 10 ("batch reading") and Previous 10. I know from experience that Previous 10 is a real pain. The way I do it on iHub is to make the recordset a different cursortype so I can start at the end and move backwards through it to retain the newer-messages-first order of things. I'll see if I can come up with another way for SI. If any of you SQL types out there think it through, you'll realize the challenge Previous 10 can cause since you use top 10 and order by the messageid. The new webserver (Dell 650 with 1 gig memory, 120-gig IDE hard drive, and a 3.06Ghz P4 processor) should arrive today or Monday. It was shipped the day before yesterday. About 60% of the cost of iHub's webserver and probably 80% of the performance. My reading over the past week has led me to a new policy for webservers. Rather than buying the most powerful and expensive (within reason) boxes I can, I'm going to spend less and be prepared to deploy multiple webservers as needed. iHub has quite a powerful webserver. A pair of 3.06Ghz processors, 2 gig of fast memory (only 400-meg of which seems to actually be getting used -- validating the suggestion that more than 1 gig of memory is wasted money) and 3 36.7k-gig 15k-rpm SCSI drives configured as RAID5. Not so much overkill as wasted money. We bought about $2500 more server than we needed. According to my recent reading, the second processor only adds about 28% horsepower, we've got 1 gig of memory going unused, and what's stored on the hard drives (source code and log files, both of which are easily backed up onto the db server or another webserver when/if we get one) sure didn't require the speed and expense of the RAID5 solution we went with. And it easily handles iHub's traffic load (over 11k posts on 4/6 and just a few dozen shy of 11k yesterday) while running at about 20% utilization during peak periods, despite having lots more (and lots more expensive) features on it. Oh, and iHub's webserver draws so much juice, UPS's have been an ongoing problem. We've got a pair of very expensive ones for both sites and they're running at maximum load. This will be alleviated in the near future because as soon as Dev goes into production, two of SI's existing webservers will get yanked, with the remaining one used only for what the new SI won't immediately cover (portfolios, the old charts system, etc). It doesn't look like I'll meet my goal, though, of having Dev fully operational as a message board (posting ability is the primary thing it lacks, but will be the next project after Next10/Previous10) and the webserver will arrive soon and will be ready to go to the ISP in about a week. After posting is functional, then it'll be time to tackle having the system tell the difference between different types of users and making features available/unavailable accordingly.