[ATTACH=CONFIG]195108.vB5-legacyid=2982[/ATTACH]Hello SFNers,
I am writing this post to explain about what we changed here at SFN to provide the speedy new forum performance. This is all in plain language with minimal computer jargon, as we want all users to clearly understand what their donations are doing. For those of you who do computer stuff on a regular basis, feel free to PM about the gory technical details.
[B]Here’s how the new soundforums.net gets you the community’s content:[/B]
[B]1. Your Browser Asks for SFN[/B][INDENT][I]Old Way[/I][/INDENT]
[INDENT=2]Before, your browser and half the spam bots on the internet were asking soundforums.net for various information. The server has to respond to all the requests, good and bad, so responding to spam slows down the forum for legitimate members.[/INDENT]
[INDENT][I]New Way[/I][/INDENT]
[INDENT=2]We use a service called [URL=”http://www.cloudflare.com/”]Cloudflare[/URL] that intelligently finds spam and stops their requests from ever making it to the soundforums.net hardware. Legitimate traffic is allowed through and is served as usual. Stopping spam requests before they can ever get to the server speeds up legitimate replies for content.
[/INDENT]
[B]
2. Your Request Hits the SFN Server[/B][INDENT][I]Old Way[/I][/INDENT]
[INDENT=2]The old SFN server was a virtual private server (VPS) of unknown pedigree and middling performance. It had limitations on easy configuration of the software that served up web pages and how that software was configured. It was connected to another, separate server that held the database (i.e. all the posts, user info, etc.). The database server was not accessible for performance configuration, and we did not know how many other sites it also had to support. The database server had lots of problems.[/INDENT]
[INDENT][I]New Way[/I][/INDENT]
[INDENT=2]The new SFN server is also a VPS, but from a high end VPS provider. The underlying machine is built around recent, top-shelf Intel hardware. Currently we have one processor core, and one block of memory (i.e. RAM) on this machine. Down the road if we need more memory blocks and/or CPU, it is literally some clicks and five minutes to expand the server’s hardware capabilities as needed.[/INDENT]
[B]
3. SFN’s Web Server Takes Your Request[/B][INDENT][I]Old Way[/I][/INDENT]
[INDENT=2]SFNs old web server technology ([URL=”http://www.apache.org/”]Apache[/URL]) is like going to a restaurant where your waitress takes the order and then has to run to the kitchen to cook the food and bring it back to you, all before talking to anyone else. The waitress can only serve one table at a time, and the only way to serve more tables is to have more waitresses. You can hire more waitresses, but eventually you run out of room (i.e. memory/RAM) in the restaurant.[/INDENT]
[INDENT][I]New Way[/I][/INDENT]
[INDENT=2]SFNs new web server technology ([URL=”http://nginx.com/”]nginx[/URL] and [URL=”http://php-fpm.org/”]php-fpm[/URL]) is like the waitress taking your order and putting it up on the cook’s line for the kitchen staff. The waitress can then go talk to another table, so one waitress can serve many tables. The kitchen staff can prepare the food and return it to the waitress when it is finished. The waitress is solely focused on tables (i.e. requests) and the kitchen staff soley on cooking (i.e. processing VBulletin). Just as a restaurant can change the size of the kitchen staff depending on how busy they are, the server can intelligently change the number of workers that are processing VBulletin based on how many users are online.[/INDENT]
[B]
4. “Workers” Process VBulletin Code[/B][INDENT][I]Old Way[/I][/INDENT]
[INDENT=2]On the old server, not only did the waitress take your order and do the cooking, she had to re-read the recipe every time she cooked an order! VBulletin is written in php, which must be translated into operations the processors can understand before being executed. These operations are called opcode. The old server created new opcode with every call to Vbulletin.[/INDENT]
[INDENT][I]New Way[/I][/INDENT]
[INDENT=2]With the new server, the kitchen staff already knows the recipes as they use them all the time and have committed them to memory. In computer terms, the opcode for all of Vbulletin was processed once and stored in RAM, so the workers don’t have to spend time reading php from the hard drive and converting it into opcode.[/INDENT]
[B]
5. Vbulletin Requests Your Content from Storage[/B][INDENT][I]Old Way[/I][/INDENT]
[INDENT=2]With the old SFN server, everything was stored in the database. Posts, attachments, everything. As mentioned above, this database was running from a place where we could not configure its performance. Also, we couldn’t store commonly used things (e.g. login status) in a speedy RAM location for fast retrieval. Finally, we were using an older database “engine” that does not handle simultaneous users as quickly as newer engines.[/INDENT]
[INDENT][I]New Way[/I][/INDENT]
[INDENT=2]The new server has the database on the same machine and hard drive as the web serving and code processing bits. To improve performance we implemented several things. First, we are using a new database engine, and can optimize the database for performance directly. Then, we moved attachments out of the database and on to the hard disk. Recalling attachments out of the database is resource intensive. Finally, we set up a RAM cache that acts like a virtual Post-it note for things VBulletin uses all the time. This cache will grow automatically as our user base grows, keeping the common activities running quickly as more users join.[/INDENT]
[B]
6. SFN Web Server Returns Your Content[/B][INDENT][I]Old Way[/I][/INDENT]
[INDENT=2]Returning to our waitress analogy, the old server used big heavy plates and spread out the food in grand fashion. The waitress also kept providing you with new forks, knives, and spoons, even though the first set you received was completely fine.[/INDENT]
[INDENT][I]New Way[/I][/INDENT]
[INDENT=2]The new server is like the waitress stuffing your food into a little bag and then relying on you (i.e. your web browser) to unpack it. This means less data transmission, which leads to faster data transmission. The new server zips every file it can before sending it to your web browser, and the web browser unzips the files at the end. The new server also tells your web browser to keep around copies of files that do not change. This keeps you from re-downloading common content over and over, and further reduces the total amount of data the server has to send.[/INDENT]
[B]7. Enjoy SFN![/B][INDENT][I]Old Way[/I][/INDENT]
[INDENT=2]The old server had lots of down time, the database would often not update correctly, performance was sluggish, and error reporting back to SFN was minimal. Backups were functional, but not very advanced, and tied to a second server of unknown location.[/INDENT]
[INDENT][I]New Way[/I][/INDENT]
[INDENT=2]The new SFN server infrastructure is faster and scalable to more users. The server notifies the administrators within 1 minute if there is downtime. Every single corner of performance and security is available, known, and configurable by SFN. Error logging is more thorough, substantial, and easier to access. Backups are performed both to the SFN hardware, and to another separate server in the same data center. If finances permit, we will create a mirrored server at another, remote data center outside the US. The two servers will then share the traffic load.[/INDENT]
Hopefully this gives a clearer picture of what has changed at SFN, and how a series of behind the scenes steps builds up to increased performance and the ability to expand to the community’s needs. The new hardware does increase the cost basis for SFN, but we think the increased costs are very much worth the benefits.
Between the generous donations of the communities members, and the eventual inclusion of targeted, useful advertising, soundforums.net is here for the long haul as a premiere resource to the professional audio, lighting, staging, and overall production world.
Sincerely,
[I]-The Moderator Volunteers: Bennett and David
-The Computer Volunteers: David, Jeff, and Phil[/I]
