Home
Forums
New posts
Search forums
What's new
New posts
New profile posts
Latest activity
Members
Current visitors
New profile posts
Search profile posts
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Menu
Log in
Register
Install the app
Install
Important announcement regarding the future of this forum - PLEASE READ
Home
Forums
FreeOnes
Questions, Comments, and Suggestions
Busy Server.. WHAT?, Again?
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Member2019" data-source="post: 2253746" data-attributes="member: 28455"><p>Not in many cases. While you can load balance the front-end, as HTTP is rather simplistic, the SQL distribution is more complex.</p><p></p><p>I have to assume LAMP (Linux, Apache, MySQL, PHP) is in use here. The fastest performing deployment of MySQL in a multi-server **** is many read-only replicas, and one write-only master. In fact, that's the staple web approach that made MySQL very popular -- because it solves that common, web design (write one, full record to one instance, read many, many times from other instances), instead of full, traditional, ACID approaches where most implementations have legacy to Ingres/Postgres (e.g., MS SQL, Oracle, Sybase, etc...). Multi-master replication is far, far more difficult, and requires more complex software and administration.</p><p></p><p>I would assume the messages are due because of too many commits -- i.e., transactions that actually write to the master databaes. So adding more Apache with read-only MySQL replicas in a round-round option wouldn't solve that, because the commits/writes go to the single, master server. Records are created for vBB for many things, including searches.</p><p></p><p>If anything about the only tunable you could do is cap the number of posts, searches and other things that cause a commit, and favor dynamic content generation of pages/threads that are read-only. But people who still cause a commit would still see the message.</p><p></p><p>Another, general option is to throttle the number of requests from the same client with the same cookie/session (IP won't cut it). E.g., I use Firefox and can regularly found guilty of middle-clicking countless links -- 10, 20 even 30+ sometimes. I'm causing the server to dynamically generate content when I do.</p><p></p><p>There are other options that could be looked at. Just throwing more hardware is not the solution here. I regularly have to smack Java developers with a stick on Wall Street who keep pointing the finger at infrastructure when it's their implementation and open-ended attitude to capacity and performance.</p></blockquote><p></p>
[QUOTE="Member2019, post: 2253746, member: 28455"] Not in many cases. While you can load balance the front-end, as HTTP is rather simplistic, the SQL distribution is more complex. I have to assume LAMP (Linux, Apache, MySQL, PHP) is in use here. The fastest performing deployment of MySQL in a multi-server **** is many read-only replicas, and one write-only master. In fact, that's the staple web approach that made MySQL very popular -- because it solves that common, web design (write one, full record to one instance, read many, many times from other instances), instead of full, traditional, ACID approaches where most implementations have legacy to Ingres/Postgres (e.g., MS SQL, Oracle, Sybase, etc...). Multi-master replication is far, far more difficult, and requires more complex software and administration. I would assume the messages are due because of too many commits -- i.e., transactions that actually write to the master databaes. So adding more Apache with read-only MySQL replicas in a round-round option wouldn't solve that, because the commits/writes go to the single, master server. Records are created for vBB for many things, including searches. If anything about the only tunable you could do is cap the number of posts, searches and other things that cause a commit, and favor dynamic content generation of pages/threads that are read-only. But people who still cause a commit would still see the message. Another, general option is to throttle the number of requests from the same client with the same cookie/session (IP won't cut it). E.g., I use Firefox and can regularly found guilty of middle-clicking countless links -- 10, 20 even 30+ sometimes. I'm causing the server to dynamically generate content when I do. There are other options that could be looked at. Just throwing more hardware is not the solution here. I regularly have to smack Java developers with a stick on Wall Street who keep pointing the finger at infrastructure when it's their implementation and open-ended attitude to capacity and performance. [/QUOTE]
Insert quotes…
Name
Verification
If I live in california, what country do I live in?
Post reply
Home
Forums
FreeOnes
Questions, Comments, and Suggestions
Busy Server.. WHAT?, Again?
Top
