Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By Dries on
The Drupal community has been growing steadily over time, and recently started to outgrow our shared, single server system (Pentium Xeon 3Ghz with 1 GB of RAM). The server hosts a variety of Drupal websites, including http://www.drupal.org/, http://cvs.drupal.org/, http://www.drupaldocs.org/ and a number of other sites.
As mentioned earlier, we have been talking to the Open Source Lab (OSL) at Oregon State University and they generously offered to provide free rack space, bandwidth, power, backup facilities and on-site support. OSL is responsible for taking care of some of the largest projects in the Open Source community, including the Apache Foundation and the Mozilla Foundation. In order to take advantage of this generous offer, we need to supply our own equipment. Our initial plan was to purchase a modest dedicated server to replace our current shared system. However, thanks to the success of last week's donations, we will be able to roll out a more sophisticated server architecture to support the growth of our community. Read on for the details, and an extra "sun-prise" ...
A surprise from Sun Microsystems
Tim Bray (Sun Microsystems employee, W3C member, co-inventor of XML, and Drupal fan) noticed we were in trouble, and asked around if Sun Microsystems could donate a server. On Sunday Sun Microsystems' Software CTO, Hal Stern mailed me saying they wanted to ship us a free Sun Fire V20z server. Monday morning Scott Kveton, Associate Director of the Open Source Lab, got in touch with Sun and completed some paperwork on our behalf. Much to our surprise, the Sun server arrived at OSL the morning after! Don't believe me? Check the shipping details (see below, picture on the left) or have a look at the pictures snapped by OSL personnel (or see below, picture on the right). Sun managed to stun all of us, that's for sure!
The Sun Fire V20z server has the following specifications:
- 2 x AMD Opteron
- 4 x 1 GB DDR-2 400 RAM
- 2 x 73 GB U230 SCSI drives (RAID1)
Props to Tim Bray (Software CTO office), John Fowler (Executive Vice President of the Network Systems Group) and Hal Stern (Software CTO) for making this possible. Thanks!
Proposed server infrastructure
On Monday, we had a meeting with OSL. We decided all the donated money (just over $10,000 USD) would be transferred to OSL, and OSL and Firebright would work together to spec out a good infrastructure for our money. Later this week, they followed up with a proposal and quotes for the infrastructure. In short, the OSL will order us 3 Dell 1850s. Each Dell 1850 has the following specifications:
- 2 x Intel Xeon
- 2 x 1 GB DDR-2 400 RAM
- 2 x 73 GB U230 SCSI drives (RAID1)
- Dual power supplies
- Remote access card
Scott Kveton of OSL explains:
With 4 total servers, we will not only be more scalable but also much more reliable. The Sun Fire V20z will act as a database server, and we will have 2 Dell 1850 application servers, each handling half of the load. We'll start with a DNS round-robin and then move to using Linux Virtual Server (LVS) for full redundancy of the drupal.org websites. The great part about using LVS is it will enable us to scale even further should the need arise without a massive rearchitecture of the existing gear.
We will be using the third Dell 1850 to handle the CVS/SVN and mail services for Drupal. This is technically a single-point of failure but we did make sure to order redundant power supplies and will be doing RAID1 with the 2 - 73G disks.
In the short term, we'll backup the database every day and off-load to the OSL backup server. In the long term, we can look at doing replication with another box if the need arises and as we grow.
The Dell 1850s will be ordered as soon the donated money is transferred to OSL. The transfer is in process but it takes Paypal and the local banks a number of business days to get the money from A to B.
Once the hardware arrived, we'll probably be installing Gentoo on them as it gets us the most bang for our buck. Also, OSL has a lot of Gentoo experience: two people of Gentoo's board of trustees work for the OSL, and the OSL provides hosting for Gentoo.
Community services
In the next few weeks we'll try to setup a system administrators team. We'll grow our team of system administrators (currently Kjartan, Steven and myself), we'll create a chart of who administers what, and who to contact when something is out of whack. In other words, we'll get ourselves organized. Tune in on the Drupal infrastructure mailing list if you want to get involved.
In addition, we have offered to sponsor a student intern at the OSL for 8 weeks. We all have day jobs and in order to get this up and running in a timely matter, the intern will help with the intensive work on the servers, help with the transition from the existing site to the new one, as well as focus on some new functionality the Drupal community has been clamoring for. OSL interns work directly for OSL's system engineers from whom they will get guidance. Furthermore, several of OSL's students are doing - or have done - internships at NASA, Intel, Gentoo and Mozilla.
Note also that quite a few of us will be attending O'Reilly's Open Source Convention and the Drupal conference in Portland (1-7 august). We'll visit the OSL and meet with the OSL folks face-to-face. Feel free to join us!
Once the existing services have been migrated to the new infrastructure, we'll look into extending the services we offer the Drupal community. With the help from our intern and OSL personnel, we'll setup the infrastructure so we can give people levelled access. For example, we'll make it so Ber Kessels can move the Drupal theme garden from his personal server to the new Drupal server infrastructure, and he has the permissions it takes to maintain the Drupal theme garden. Similarly, we intend to provide a Subversion mirror of our CVS repositories. (Possibly, a first step in moving from CVS to Subversion?) We might also be able to provide hosting for other Drupal-related communities, like language-specific communities.
That is it for now. We'll follow up with more information as soon one or more servers are in place. Thanks go out to Sun, OSL and the Drupal community for their/your fantastic support!
Updates
July 19, 2005 (Dries): I had to wait for some donations to be cleared so I couldn't transfer the money until today. As of two hours ago, the donated money is on its way to OSL.
Comments
From a goal of $3000, Drupal
From a goal of $3000, Drupal raises $10k plus a $4k server. I think the drupal community just realized what kind of friends it has.
That is all I have to say...
Drupal is amazingly useful software...
...and people are willing to pay for that.
Comments on the infrastructure architecture
Given that all of the current Drupal services are run on a single machine which is actually shared by other, non-Drupal services, it's clear that all Drupal services could run on a single dedicated box of equal or better capability. The proposed Dell machines and the Sun machine all seem to be in the "better" class.
While the proposed architecture (2 app servers, 1 database server, and 1 CVS/mail server) provides lots of headroom for growth, and does provide some improved reliability and availability, it still has some major single points of failure and relies on traditional backups for recovery from such failures.
In my experience[1], traditional backups are time and manpower intensive for recovery. With the amount of hardware potential (4 machines), I highly recommend some sort of configuration which includes database replication. You may possibly wish to also include replication/hot backup of other services.
There appears to be plenty of hardware capability to do this and handle a lot of growth, although admittedly the headroom for growth will be somewhat less than the proposed scheme. I believe it is wiser to have a more reliable, easier to manage system architecture now, and address growth beyond capabitilities if and when it occurs.
I'd be happy to discuss this further with anyone so interested.
Sincerely,
Chris Johnson
[1] My 25+ years experience as a programmer and system administrator includes running datacenters for private corporations and an ISP (Visi.com from 1995-1996), and currently running a configuration very similar to Drupal's for a private corporation minus the mail server, (i.e. MySQL database, Apache app server, CVS repository, auxilliary web sites and servers).
Please don't take this the
Please don't take this the wrong way, because I think what Drupal has gotten is amazing, but I was really hoping that not all $10,000 of that would be used on servers...
Was really hoping that could be used to start the Drupal Foundation.
I'm really not in the know, so that's probably a stupid thing for me to care about, but is just straight up hardware the most effective way for Drupal to spend that money?
Some Thoughts on This
In talking with the Drupal folks about this, there was definitely some hesitation to spend all of the money on server equipment. The original intent I believe was to save some of it for the creation of the Foundation.
However, as we talked more, it was stated that the people who donated did donate specifically for the server hardware and increased reliability in the infrastructure. At the risk of alienating people who did donate for one specific purpose, the decision was made by the Drupal folks to focus all of the money on gear and support of that gear.
That said, I believe there is still some significant movement on getting the non-profit created. I'll leave that to Dries and company to address that ... :-)
Donations properly used
I concur (as a minor donator) that the use of the donations on hardware were properly used as they were intended that way by the donors. While I would not have minded any excess portion of my contribution to go to the foundation start-up, I can imagine that some folks would have.
When the hat goes around for a foundation start-up donation I'll be happy to contribute to that also. However, that organization needs to be very carefully thought out as it has many ramifications over a long period of time.
Kudos to everyone on the great work!
- gil -
Donations for the Drupal Foundation
It turns out we'll have the money it takes to setup a Drupal Foundation. Civicspace, for example, has a fair amount of money they promised to donate. Packt Publishing also offered to donate $1,000 USD. They agreed to transfer it once we are ready for it. Also, at the end of the summer, we'll get some money from Google too (Summer of Code). All this money can be used to setup a Drupal Foundation.
I didn't mention the Drupal Foundation in my post because it was already quite long, and because we are still actively investigating our options. I'll see if we can summarize what we found and how want to approach this it in the next few weeks. We'll certainly open this up to the community.
In the mean time; rest assured that we'll be able to create a foundation. :)
Foundation or other NGO
Hi,
The folks of Typo3 created something similar. If you wan't you can talk with them and check it out at http://association.typo3.org/index.php?id=22
Best and good luck
Lopo
Humaneasy Consulting
www.humaneasy.com
Humaneasy Consulting
iPublicis!COM
www.humaneasy.com
www.ipublicis.com
CSM & CSPO
Re: Comments on the infrastructure architecture
Bear in mind that this is just the start of this infrastructure and it will be constantly evolving as Drupal's success grows. However, with the way that we are lining it out, we will be able to incrementally grow/scale as needs arise. This makes capacity planning very easy over time which is a good thing.
I agree that there are single points of failures in this architecture. However, with services such as mail, CVS and SVN they are not very easily spread across multiple servers, etc without significant investment. That said, it will be trivial to keep "hot backups" of this data on any of the gear and shift services (with administrator intervention) as needed with minimal impact on uptime.
Getting to 99.99% of uptime is easy IMHO - its those 9's that come after that that get exponentially difficult to address ... :-)
Ideas for the hopper
Scott,
I understand the infrastructure will evolve. As I mentioned to Dries, these sorts of topics are forefront on my mind because I'm responsible for my employer's infrastructure and we are currently working to improve it to ensure very high uptime numbers. We're a 24x7 shop with mission critical data, so it's kind of important to us. We're all Open Source-based software on commodity Intel machines at 2 geograhically separated data centers. Because when all things go right, recovering from backups takes "15 minutes" but typically with computers, something else goes wrong, we are moving to replication and hot-spares to minimize downtime.
So I wanted to at least get the idea of making recovery from a failure quick and easy into the hopper of things being considered for the Drupal infrastructure. Database replication is just one such tool. I have no intention of trying to tell you how to do your job, so to speak.
I'm excited about this move and new page in Drupal's book of progress. Regardless of the details, I'm sure it will be a great improvement for the whole community.
Respectfully,
Chris Johnson
hardware overkill?
Chris Johnson writes:
> Given that all of the current Drupal services are run on a single
> machine which is actually shared by other, non-Drupal services,
> it's clear that all Drupal services could run on a single dedicated
> box of equal or better capability. The proposed Dell machines and
> the Sun machine all seem to be in the "better" class.
While the proposed architecture would make a lot of sense if Drupal was planning to scale 10x-plus in the next few months (a la typical dot-com business plan), if one is anticipating only modest growth (say, doubling in a few months) it seems like there would be a lot of better ways to achieve this. I'm with Chris here.
> There appears to be plenty of hardware capability to do this and
> handle a lot of growth, although admittedly the headroom for growth
> will be somewhat less than the proposed scheme. I believe it is
> wiser to have a more reliable, easier to manage system architecture
> now, and address growth beyond capabitilities if and when it
> occurs.
I'd certainly second this. Keep it simple: mirror two machines running everything in parallel. Sure, the room for growth is less, but until one has need for that room the excess capacity is wasted. You realize you are proposing to buy a Dual Xeon to handle mail and CVS? This seems like it might be overkill.
Why not put these services on one of the other machines, and hold off on buying one. Keep the $3000 you save in the bank, and then if/when you need more capacity spend it where it is needed? The longer you hold off on buying that machine, the more bang you are going to get. If you wait a year, you'll almost certainly be able to get twice the computing power for the same price.
I realize there are other pressures, and that until you have non-profit status keeping money around may be awkward. But as a (very small) donor, I'd rather see you spend the money wisely rather than in a hurry. My .1% of a vote would certainly say that you should get things running on the Sunfire first, then buy one machine to mirror it, and then and only then buy the remaining hardware on an as needed basis.
wisely
Please understand, the money is being spent wisely and not in a hurry. This is a solid proven architecture design across a wide variety of OS and application platforms. There are a lot of solutions that do this. The concern about backup recover time, etc is not really a serious issue. Does it need to be accounted for? Yes. Drupal.org would have been up much faster had their been no communications difficulty.
Other significant advantages to this is that the database server itself won't necessarily be the first entry point for access. The front end application servers will be. This means to get to the database server, you need to start with the front end applications server. This would slow down any attacks or hacking attempts in the future, hopefully enough . :)
Also, this will allow drupal.org itself to gather a lot of performance data on this type of setup that can then be rolled into the handbook at some point. Another benefit.
The points of failure are all single point no matter what. With solid hardware (hw RAID) downtime due to drive failure is minamal. The biggest risk is in database corruption and no matter how you sync, mirror, copy there is one active master database. Recovery is just not that difficult or slow unless the entire system goes down. Don't forget we will have OSL datacenter personal who have a lot of experiance in this sort of situation and in designing these solutions for Open Source projects.
Also, this is a solution that is not inventing new ways to do things and a lot more people have a lot of experiance with it. Database backend, app server front ends with plans to move those to virualized servers over time. We get a solid time tested architecture quickly with the road map to move forward on.
Solid real world database clustering experiance is not something that is really common (yes I know it's been done, yadda yadda yadda) and there are just not that many people who have extensive enterprise experiance with it. We can still do this, but lets get THIS round of infrastructure built and in place first. Then folks can look at the performance numbers and see where it makes sense to go next. Once a direction is agreed on, then testing and build out can proceed in that direction.
If database clustering is the step after virtualizing the front end (see already a next step planned) then testing before implementation needs to go first. RIght now there are enough significant changes from the current setup to make this a lot of fun. Enterprise class hardware generally is solid enough not to worry about it once you're past the burn in time beyond monitoring.
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
thanks
Thanks for your response. I agree that the proposed architecture is solid, tested, and offers a _lot_ of room for growth. And if one views it as an opportunity to gain practical experience in building a very large Drupal powered site, then it's probably money well spent. I still feel that buying hardware in advance of actual need is a bit unwise (I think everyone agrees that one _could_ grow Drupal significantly on even a single server), but I'm glad to see this issues have been considered.
Foundation, and some suggestions
Well, the money is now in the hands of OSL, but if it was not, I would have loved this money to start the Drupal Foundation as soon as possible.
If there was concern that "people donated for hardware, so we spend only on hardware", then why not put up a poll on Drupal.org about whether to spend some of the money on the foundation or not? Let the community decide.
Well, it is too late now, but keep that in mind for the future.
Also, don't forget drupaldocs.org, and while we are at it, why not make that docs.drupal.org to be consistent with lists.drupal.org and cvs.drupal.org.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
That's exactly what I was
That's exactly what I was trying to say kbahey.
Foundation initiative
I know that there has been a lot of talk about putting together a foundation, and the money that we (Advomatic) and CivicSpaceLabs have pledged in matching funds during this fundraiser is being held until we decide an appropriate use for it. This is what we decided with Dries' input, so there is already some significant money waiting in the wings when it is needed to start such an enterprise.
Could you confirm what you mean by "matching funds"?
Is there a published number on this amount?
- Robert Douglass
-----
If this helped you, please take the time to rate the value of this post: http://rate.affero.net/robertDouglass/
www.hornroller.com, www.robshouse.net
No
Other organizations we're offering some matching funds (with top limits) and they are waiting on transferring until things settled, see Dries post above for brief mention.
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Ask and you shall recieve...
Seems like most of us are waiting to be asked. By that I mean that I didn't donate anything to Drupal.org until the server was down and realized I could help. My donation was very small but I was what I could at that moment. Seems like others responded the same way, because there was a request.
So perhaps if someone outlined a plan for a Drupal Foundation and then set a target amount to raise funds for that specific purpose then the community would respond again.
I know I will donate what I can.
Michael Johnson
foundation
Discussion on a foundation is going on now. There are a lot of ways to do this and we are hoping to learn from other groups about issue's they had with the path they choose.
Another group ran into issue's with 'diverted' funds. As Dries personally does not currently have non-profit status personally it was thought that getting the hardware infrastructure in place now was the better path.
I understand that you (and many others) do not personally have an issue with diverting the funds, there were a few hundred doners and it only takes one with a lawyer to be upset :).
While getting a foundation setup is a priority, we are not in such a state of emergency that it has to be complete in the next week. At this point discussions are underway and things are moving forward. This is a good thing.
Multiple International timezones also make it fun. GMT+1 in relation to GMT-7/8 for instance. :)
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Donations for the Drupal Foundation
See http://drupal.org/node/26707#comment-46357.
In short: we're all good.
Regarding the Drupal Foundation
I wanted to shed some light on this discussion as it seems there are some concerns and confusion about it.
First, there are a number of us in the Drupal community who are already (and have been) actively pursuing this topic and will be reporting back as we make progress. Due to the server issue, we had to focus on that first and now that that's been resolved, our attention will be spent on the foundation question.
Already I have been in touch with Andrew Hoppin from CivicSpace since they (we) recently went through the trademark, foundation, and incorporation processes and can shed some light (and possibly some resources or pointers to resources) on how to handle this... i.e. do we set this up in the US or not?, do we need both a corporation and a foundation?, etc.
We're in the beginning stages of this discussion and trying to figure out exactly why we need and want and foundation, since that will determine the type that we pursue. We've also been scoping out various legal service providers and looking into the vast open source community for ideas, opinions and other helpful insights into how to do this right -- there's no sense in reinventing the wheel if we don't have to!
Additionally, there is a good possibility that I will personally be attending a FOSS Summit prior to OSCON to discuss just this issue with other established projects from the open source community. There's a significant need for answers to these kinds of questions and it's high time that the FOSS community pooled its resources in order to make it easier for community projects such as Drupal to move from indie projects to legally substantiated entities (like Mozilla or Linux).
If you're interested in this process or can contribute, feel free to drop me (factoryjoe AT factorycity DOT net), Dries or Boris a note.
Wonderful
Thank you, Sun, OSL, and the Drupal community. This is an incredible step forward for Drupal.
I can only concur. This will
I can only concur. This will hopefully keep our heads free from server problems for the months to come. Will be interesting to see how many. ;)
The only possible problem I am seeing is that the interest in optimizing Drupal's performance might drop due to a possible drupal.org-runs-very-snappy-get-yourself-a-few-servers-donated attitude. ;)
Anyway: Thanks to Sun, OSL, and our donors!
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
How about creating drupal benchmarks?
I hope optimization performance for people on shared hosting environments won't be left out. Right now I'm seeing the performance of my site decreased due to server load.
Don't know if it's possible but how about to create benchmarks for drupal core modules. I think it'll be interesting to test the current drupal version, the previous version and the head version. Tests will need to run on a few reference machines, with different configurations, to answer questions like: Which PHP version is better to run drupal? Is the development version performing better? etc...
Perhaps a new drupal site can be created to answer those very interesting questions like benchmarks.drupal.org as a guide for developers, users and web hosting companies.
Otherwise, in the long run, only a few sites with enough monetary resources will be able to run drupal decently, as a side effect of drupal.org moving to an enterprise level infrastructure.
--
Webmaster Resources for Business Websites
This is a very nice idea.
This is a very nice idea. However, there would be a lot of work involved. I've been running Drupal benchmarks quite often, but it always takes a lot of time and the results are not always unambiguous.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Thinking more about this
I think it can be achievable if a good program to benchmark drupal core modules could be created, perhaps a benchmarks module, and if one member could destinate a few low level equipments only to run the tests and post the results to the site. The goal would be to get this into an automated process.
The only time when tests will need to run will be when drupal core gets updated. And for developers a scheduled benchmark of head can be a good starting point.
If developers could have this kind of feedback I'm sure they will struggle to came up with very well thought optimized code solutions. Optimization will also become a concern in all drupal ambits benefiting all of us.
--
Webmaster Resources for Business Websites
I started a feature request
http://drupal.org/node/26765
Gerhard, capmex and everyone, please comment there.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Newb question
Basic question: It seems like having the database on a separate server would cause serious lag time. How does that work?
not always the case
Because you generally setup the db server on a dedicated internal network with 10/100/1000 ethernet, you can often get more throughput than the pci bus itself can handle. Also, since you have dedicated machines you dont have one machine handling all the processes, so the load decreases overall. Setting up a dedicated database server is a good first step in a migration towards a clustered setup from a single server.
Faster than a PCI???
Wow, would have never guessed. I would think there would be a big a bottleneck as data has to get converted to the packet level and then taken back out. Weird. And doesn't the data have to go through the PCI bus anyway. It's got to leave the hard drive, go over the bus, and out the ethernet connection.
Maybe my ignorance of pc architecture is showing. What's a good resource for learning more?
Faster than PCI? I don't
Faster than PCI?
I don't believe it. Fast for sure, but most network cards are PCI anyway so they can't possibly be faster.
The bus is not the limiter...
This is an interesting thread.
The PCI bus limitation is mostly a non-issue (IMHO) from a production standpoint, though limits theorhetically do exist. With some of the faster server network cards, you had a dedicated processor built right in, so much of TCP/IP overhead that is normally pushed onto the CPU(s) is actually handled on the card itself, and you can also bridge multiple cards together for faster speeds (essentially "load balancing" multiple cards in one system).
Consider the average line speed for GigE is 40-60% utilized (50-75MB per second), it is actually possible to tap out the line speed of GigE (especially with the 64-bit, 66 MHZ PCI buses) at something like 100-120MBPS. So, in reality, the system isn't the limitation, especially not when you're using good equipment.
But seriously, think about how many database transactions we're talking about to acheive those numbers? That's seriously insanely above current utilization levels for Drupal.org (and for the conceivable future).
The GigE is on it's own vlan, so we really could achieve very high line speed to the db box as there is little interference on the line. We'd definitely tap out the cpu with that kind of databases traffic long before you'd have to worry about what you guys are talking about..
This setup we discussed at length, and this is the best setup for Drupal in terms of bang for the buck, and really will help give the maximum amount of flexibility to the drupal project in the long term, without breaking the bank. We looked at hardware load balancing solutions, but they were far in excess of our budget (the primary adantage being able to load balance services "by the port" and not "by the box"), and aren't really necessary honestly for where Drupal is at (or set to go) in the medium term.
I have to hand it to OSL. I have a heck of a lot of confidence in this plan, and in OSL's ability to reliably execute. They run the Apache Foundation, as well as the LVS cluster for Mozilla, so they can certainly handle the relatively modest requirements that the Drupal community has.
I can't wait to see what these new server resources will let blossom in the community, and it should seriously speed up the site which is really great IMHO.
--------------------------------------------------
FireBright :: http://www.FireBright.com/
Different optimization strategies
Splitting them up also gives you the chance to optimize the machines for their individual tasks. As I understand it, a database server is pretty memory intensive, wheras a web server is CPU intensive in comparison.
- Robert Douglass
-----
If this helped you, please take the time to rate the value of this post: http://rate.affero.net/robertDouglass/
www.hornroller.com, www.robshouse.net
DB Bottlenecks
It depends on the application, but in many cases, database servers are IO (disk) bound. I'd guess that the Drupal site sees a read-mostly pattern of access though, on relatively small set of data, so memory might be critical.
Proven technique
Large sites use this technique a lot. Sites receiving millions of hits PER DAY do this.
They have their DNS round robin on a group of servers that run Apache and the application (be it PHP or Perl), and all of them access the database from a separate server.
Since each machine is not doing a lot of very different things (parse PHP and execute it, handle HTTP connections, and read/write to/from database), it is a better to separate the load, and get better performance.
Sites like Slashdot use this method.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
And...
Exactly...
And it's a very easy transition to an Linux Virtual Server setup which would provide relatively limitless horizonal scalability.
--------------------------------------------------
FireBright :: http://www.FireBright.com/
Hopefully
Hopefully this configuration will have more success than hosts like Dreamhost have had trying to run Drupal-powered sites using separate database servers.
===
Laura
pingV
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
Doesn't seem to be an issue
Hi Laura
I helped a client who hosts on DreamHost to get rid of the pesky PHPSESSID in the URL.
I noticed that they do host MySQL on separate servers.
As far as performance goes, the database does not seem to be the issue. I am more concerned that the switch from PHP as Apache module to PHP as CGI does not scale as much.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Optimization
Drupal is heavily database dependent. Even the caching scheme relies on the database (unless I am much mistaken).
As a result, the performance is going to depend heavily on the performance of the datbase server.
I'd guess that the DB servers at dreamhost are shared among multiple users and rather overtaxed, causing a big hit for any drupal sites that depend on them.
I hope that another outcome of this crisis are some broadly applicable performance optimizations that will benefit a range of deployment options ranging from those with shared hosting environments (perhaps disk based caching, rather than DB based) to those with multiple server configurations (perhaps memcacheD and finer grained caching of page parts).
memcached
I currently investigate that further.
if you want to join this approach message me.
darix
Dreamhost
I'm hosting several Drupal sites at Dreamhost. The busiest one, macmegasite, gets about 30,000 hits a day. I got a warning from DH that I'm using too much CPU time.
An average page view in Drupal (using PHP as a CGI) uses about .25 CPU seconds.
About 1/3 of my hits are for /node/feed (which I've hacked to use Feedburner). It still had to go through the Drupal code before it got redirected, however. I changed it to use a REDIRECT PERMANENT in my .htaccess and I find the usage went down drastically.
--
Mike Cohen, http://www.mcdevzone.com/
depends on the setup
Drupal will not run full speed out-of-the-box with a seperate DB host. The biggest, most noticable tweak is to use pconnect over connect. Don't start a flame war over this, nobody wants to hear it. mysql_pconnect works awesome in high-overhead connections such as tcp/ip or SSL connections to mysql. Using pconnect maintains a connection per child thread in apache. If you set apache to kill off after 10000 hits or so, it will re-connect eliminating any possible memory leaks or just bloated cronjobs. (I'm sure they aren't know this, but I'm saying it anyway).
I've been running a DB server seperate from my webservers for well over a year now and pconnect works great over tcp/ip connects.
And like anothers have said, you also get to tune each machine for their tasks instead of trying to mix things. For example, for the DB server (with 4GB of raM!!!!) you can greatly increase the key_cache, table_sort_size, and a few other mysql optimations taking the load off of table scans and moving more of the indexes into memory. So disk I/o isn't a problem anymore. You can create more specific indexes for specific (and large) query statements. I personally run my main DB server on a raid0 setup with a replication server as a hot spare (on raid1). I have a few tables that using tablescan is better than dedicating the memory to indexes.
Not 100%...
pconnect has performance limits as well.
If you're really worried about handling your apache session handling, rather than just killing it off check out:
http://www.iagora.com/about/software/lingerd/
The problem is that you receive a new httpd daemon with ever new page or query. pconnect makes a persistent connection on a process basis (through the httpd process in this case). It is re-used with the next page served by the process.
If you have 1000 simultaneous processes, that's 1000 connections to the database. pconnect starts to be a liability when you're working with pages that do not render quickly or big queries, as 1000 open connections all doing things can quickly bog down a database box.
When the process dies, the pconnect also drops.
I don't know how busy your site is, but its usually not long until you see the fabulous "too many client connections" error message being returned when pconnect is used in production sites. As the site gets busier and busier, more apache processes are spawned, and therefore more database connections are also spawned. Imagine if you're serving a video on the site - the database connection handle will stay open the entire time that video is being served up, whether or not it's being used. That means you can lose an entire connection to the db for 20-30 minutes or more. The same goes for larger pages, multimedia, pdf rendered files, and a lot of other dynamic content.
It's often better to just live with the overhead of the connect method, and keep your number of unused connections on the db close to 0, and it will save you a lot of ram.
If you have a very busy httpd server, and you're on beefy dedicated equipment, it might work to use it, but for the vast majority of drupal installations (on $8/mo hosting accounts most of the time), it really does nothing more than tax the database hardware unnecessarily.
Sorry to be a bit "preachy" on this one, but I really would hate it if all our clients suddently went out and started using pconnect, as it would have serious ramifications on system cpu and performance. ;-)
That's my 2c, but it sounds like it's working really well in your setup, and you do have the requisite 4 GB of ram, so have at. You may see a performance benefit.
--------------------------------------------------
FireBright :: http://www.FireBright.com/
https?
Are there plans to make drupal.org accessible via SSL, i.e. https://drupal.org? I find myself in hostile environments quite often, and a secure login for drupal.org would be nice...
Uwe.
--
hermann-uwe.de | crazy-hacks.org | unmaintained-free-software.org
verisign
my company distributes verisign certificates, however I am not in the position anymore to arange something for drupal.org (switched departments). but someone must be able to give a certificate to drupal.org. otherwise, i would say that a certificate would be infrastructure, so we could buy one. --
groets
bertb
--
groets
bert boerland
I need to read up on the
I need to read up on the regulations, but I think I could sign a CAcert certificate, if I am on a to be admin team and this is considered usefull.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
CACert
FWIW, I'm a CACert assurer and I have plenty of points. I'd love to see CACert at Drupal. I wish as many people knew of them that know of the thawte notary systems and such.
front ends
multiple front ends means multiple certs :).
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Not exactly
You can use the same private key and signed cert on all the front ends. SSL is unaware of IPs, and works by domain name only.
Copying the private key and cert to call the front ends does not invalidate a signed cert.
depends on
Depends on the method used to generate the certs.
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Thank you Sun!
This is the second time in a month (Google SoC being the first) where I've been blown away by the amount of support for OS coming from large corporations. This rocks!
- Robert Douglass
-----
If this helped you, please take the time to rate the value of this post: http://rate.affero.net/robertDouglass/
www.hornroller.com, www.robshouse.net
Thanks!
As I already pointed out in my blog, this has been an absolutely great week for Drupal. Thanks to Dries, the > 250 donators, the OSL, Sun, and all the other people who made this possible! You rock.
Uwe.
--
hermann-uwe.de | crazy-hacks.org | unmaintained-free-software.org
Wonderful!
Drupal has been growing up fast, in so many ways. Nice to see that the infrastructure hosting this amazing program can evolve as quickly as the program itself, when necessary.
Thanks to OSU's OSL, they're an amazing group of people. And thanks to Sun for the powerful database server! And thanks to all that have contributed to Drupal over the years!
This was about to happen
Well, I always called Druplicon the Blue Sun. Looks like someone in Santa Clara also noticed this :)
But, really what can one say? As Drupal is the most important community I belong to, my most loved hobby and it also provides me a living as a Drupal programmer -- how can I thank Sun and all of you? I am at loss of words.
--
Read my developer blog on Drupal4hu.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
Wow!!!!
Just when I thought the community response to donation needs and the help from OSL was fantastic, what an incredible donation to receive from Sun. The Drupal community can certainly be proud of it's own contributions to the new server configuration and hosting, but we should be especially appreciative of the respect for Drupal and generosity of both SUN and OSL demonstrated by their level of support in finding a better home and supplying a better hardware configuration to run drupal.org and all of the Drupal community web services.
One moment Druplicon is
One moment Druplicon is pedaling a bicycle, the next it's flying a rocket ship delivering packets at the speed of light!
Amazing work Team Drupal! And thanks to OSL and SUN for your support and generous donations.
Glorious Disaster
This has to be one of the best system crashes ever. Talk about silver linings...
This is fantastic!
Just when you see that the community is so strong, you get another gift, and realize that Drupal has a definite backing from some serious industry players. Just as I got to know I quickly shared the good news with the Hungarian Drupal community. A big thank you for all the donations, plus Sun and OSL for the support. Long live Drupal!
I got to say I am blown away
I got to say I am blown away. I think I know why we have seen such a great community and Corporate response over the last month. More and more people are learning to appreciate how intelligent the Drupal core is and how flexible a framework it is. I only found Drupal just 4-5 weeks ago and I am still surprised at how flexible it is.
I have never found a community that I am itching to login in to every day. Never found them very inviting and friendly. I just have to say thank you to Dries and the rest of the team for making Drupal.org one of the friendlies and most approachable communities I have ever joined. I got to say I am an addict. Logging in ever chance I get. The Donation poster was a nice touch. Sorry my name is not on it. Little short for rent this month. Next time.
Any ways thanks guys. It has been a big four weeks for you Dries. First she said yes, then the Server gets hacked, then the 10K Donations, then OSL, then SUN (Tim Bray). In a week or 2 when things slow down, I hope you going to sleep well knowing the servers are secure, stable and in good hands.
A question to all the Admins. Why cant we go straight to a Linux Virtual Server. All 4 machines in one cluster. Does a LVS not offer the most scalable solution for growth and best redundancy.
And the answer is...
Yes, it does.
Two points:
1) It's very easy to move from Load balanced to LVS
2) We would need 2 machines as directors, instead of the 2+1 1850s (2 production, 1 backup) that we currently have, which would be expensive. We may still be getting the equipment, and moving in that direction. The next couple of weeks we'll know.
Rest assured, it's definitely being very much considered.
--------------------------------------------------
FireBright :: http://www.FireBright.com/
Congrats
I am proud to be a part of this community and to have contributed some money to this cause. Of all things I extremely am impressed by the amount of communication around where our money is going to and for what reason. It is comforting to know that there is rational and honesty still in this world.
May the new servers bring Drupal more progress in productivity and stability.
Balanced architecture
My company is in the process of upgrading its servers to all Sun V20zs running Solaris. Those are mighty sweet machines, if a bit noisy.
Splitting web servers from the database machine incurs a significant performance penalty in the short term, even if it allows better long-term scalability. The V20zs have tremendous memory bandwidth and I/O power thanks to the superior AMD bus and the excellent Newisys system architecture on the V20z motherboard.
If your old server was not CPU-bound, I would concentrate everything on the V20z, upgrade the RAM and spend the balance of the funds on storage to get better I/O bandwidth, e.g. a Dell-EMC AX100 or an Apple XServe RAID. The SCSI drives on the V20z are fast, but disk I/O is the limiting factor in many applications, and the more spindles you have, the better.
Congratulations!
Congratulations to the Drupal team for these great news and thanks to OSL and Sun for their help.
The Drupal community has confirmed their loyalty to such a great project and I feel proud of being a little part of the group :)
Keep the great work!
Regards!
Alexis Bellido - Ventanazul web solutions
Tim Bray's blog entry
Tim Bray's blog entry about this:
http://www.tbray.org/ongoing/When/200x/2005/07/14/Drupal-Server
a big thank you ...
... To all the people who donated. Small donation or big donations and off course the sun server, they all show that the community loves Drupal! Thanks
---
if you dont like the choices being made for you, you should start making your own.
---
[Bèr Kessels | Drupal services www.webschuur.com]
Looks like a great cluster!
I've been very happy with my Dell 1425 - it's the non-redundant version of the 1850 - it's been very solid, and it really flies. The power supply died in the first week, but Dell's support was excellent, and the machine has been running continuously for months now (running Fedora Core 4, now)
Great to see Sun Microsystems stepping forward so quickly and positively! Thanks, Tim and all!
Clearly, Drupal has a lot of friends - it's great to see.
Djun
congrats! (and more)
..."but does it run linux" :-) (yes, I know)
as long as sun doesnt want anything back from this apart from goodwill, I would say, "thanks sun".
I took the liberty of creating some shots of a proposed way for the infrastructure, greatly reducing the number of SPOFs. Only trouble I have is with loadbalanced webservers, it is not the best way and you can run in trouble with users behind multiple transparant proxys using different DNS-es and you will have more trouble keeping static content (like images for themes) in sync. Maybe create a NFS share on the SUN for that?
I like the idea of a different VLAN / NIC for maintenance purposes, greatly reducing the risk of being hacked ...again.. since SSH will only be allowed from specific hosts to 1 (plus backup) host.
proposed generic
proposed ssh
proposed mail
proposed surf
(see also thumbs)
I know I greatly oversimplified it, but is a nine mile high flyover. Having control of own DNS-es and creating a second MTA would greatly help as will a server for incomming SSH with a backup.
BTW: I dont think there is another big implementation with drupal being loadbalanced and having a 2 tier infrastructure, is there?
--
groets
bertb
--
groets
bert boerland
How did you draw the schemas ?
Just wondering, what kind of tool did you use for drawing these schemas ?
Thanks, there nice ;)
MS Visio
Looks like it's almost definately Microsoft Visio.
visio
visio, a program msft bought
--
groets
bertb
--
groets
bert boerland
Thanks
In fact i add a pretty old version, so I didn't remember the nice schenmas ;)
Thanks
We heart you
I dont know about you guys, but for whatever its worth, Sun and the good folks who work there has scored serious brownie points in my book. One day, if all goes to plan, I will be in a position to make some tech investment choices, and I certainly won't forget this.
Much love and appreciation to all who spend time, money and effort into drupal, financial supporters and programmers alike.
What about helping Sun out some more
Since Sun was so generous with the server, why don't you use the 10k that is going towards 3 Dell servers and spend it on 3 Sun Servers? I'm sure that Sun would give you a good price. At least then you are helping Sun out a little too. It doesn't seem too nice after what Sun has done for you to then go out and buy a pile of Dells.
Buy SUNS ..
I second the motion, definitely. I would think that this would help in the support side of things as well.
Ditto
I personally think the Sun servers are a better product than the Dells anyway - they've got the support CPU built in, no add-on card to buy!
Best,
Matthew
Have a great day™
VIrtualization?
As long as we're talking about server infrastructures, any thoughts (yet) about virtualization?
This is an overloaded term these days; what I mean by this is something along the lines of XEN (http://xen.sourceforge.net (open source project), VMWARE (http://www.vmware.com/, commercial system), or ZONES (Solaris 10 implementation of "Virtual Machines").
The idea here is to build the servers FROM SCRATCH to be "Virtual Machines" running as guest OS's under the host OS (LINUX in the first two cases, Solaris 10 in the latter).
In the case of VMWARE, at least, there is a way to do a periodic snapshot of the entire running OS which can be restored in minutes.
If anyone is interested in the details & theory of this stuff, check out the links above. And no, I'm not associated with any of the above-named projects or companies (I work at a University).
Anyone else thinking in this direction?
I'll be joining the "infrastructure mailing list" as soon as I can find it :-)
Charlie L (aka cyberchucktx)
Linux Virtual Server
Charlie:
We are headed in that direction.
Check out:
http://www.linuxvirtualserver.org/
Also note it's an easy transition there when we need to go there with drupal.
Jonathan
--------------------------------------------------
FireBright :: http://www.FireBright.com/
Ah LVS. GREAT!
Jonathan et al:
Wonderful. Thanks for pointing me back to the LVN project ... I hadn't been following its progress recently.
If I can help with some strategic issues (decision stuff) or even implementation please let me know what list I can subscribe to. I'm interested ... like most folk I have a full-time job but am willing to put as much time as I can into projects like this (I'm fairly deep into Civicspace as well).
Charlie
Commentary on AMDZone post
This was posted with the AMDZone news update. Thoughts?
--
Drupal has gotten a Sun Fire V20z dual Opteron server donated to it. Unfortunately someone has the bright idea of taking $10,000 they had donated to them to buy 3 Dell Xeon servers that would be terribly underpowered compared to the Sun. Why or why would you want to waste that much cash? I'm thinking of all the servers I could build for that money as well. Plenty.
heh
Well, we're building servers for Drupal's environment and not for that anonymous person? What we are doing is a solid solution that gives us flexibility and room for rapid growth. Sheer computing power and the costs of that power is not always the way to go.
We are NOT wasting cash. Opteron is a great solution, but despite some peoples opinions, Intel chips are not garbage. The additional donations and Sun's generous contribution is allowing us flexibility beyond or original scope. Some nice folks with a lot of experiance doing this helped out in the design.
Random anonymous posts from elsewhere are, well, ummm.... hmmm..... Armchair quarterbacking after the game?
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Right on, sepeck.
Right on, sepeck.
It's amazing how people can get so religious and superstitious about technology, isn't it?
No doubt
Agreed. I'm a big AMD fan--my 3 machines at home are all Athlon and I haven't bought an Intel machine for myself in years. But my preference for Athlon doesn't stop me from seeing that Drupal's purchase of Dell servers is based on what's best for creating and maintaining the optimum hardware infrastructure at the best price.
Too bad Dell doesn't offer AMD machines. Not much we can do about that, though.
Plenty servers without...
... the warranty we will need. The stability. The remote control. Oh, and have you checked the price of 1U redundant supplies lately? I did go to HP's site and checked for a similar Opteron box. If we want three GOOD 1U servers we need someone who will go WAY down the list prices which Dell did for OSL.
To make a long story short: I am typing this on an AMD machine, and I had a webserver ticking off a Duron in an ordinary white box system. But Drupal on a cluster of those? Come on.
Please, please, folks, do your homework. We are not running a weblog read by Joe Sixpack and his friends. We are running a site which has 25K+ registered users and its growing exponentially.
--
Read my developer blog on Drupal4hu.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
Plenty might be too much.
While Tim Bray has a point, if indeed Dell offered a substantial discount then the point may not apply. Posting the configuration/price comparisons might help mute criticism (or at least redirect it) and is certainly more open.
The comment from Nathan Kurtz the you will get more bang for your buck by buying hardware only when you need makes a lot of sense.
On second thought the very liberal amount of hardware specified for the Drupal site - from a development perspective - may not be a good idea. Drupal needs to run well on sites with more limited resouces.
Does Drupal need this sort of hardware to run well? That is an amazing amount of hardware for what amounts to a fancy bulletin board. Does this mean Drupal is impractical for folks using web hosting accounts beyond a small number of users?
Personally I'd prefer you ramp up the hardware more slowly, and not use more hardware than needed for the main site. Better to be just a little hungry, and not lose sight of efficiency.
But plenty is a good test bed...
I think it is a valid point keeping the infrastructure slim in the name efficiency, but I think it is also a good public proof of concept that drupal can be scaled to very large sites. It also gives the Drupal community resources to improve drupal for large deployments.
The first question that comes to my mind in this setup,
is whether drupal should have a concept of different database servers for different things.
page cacheing may perform better on the application server instead of the shared database server or cluster. It will save a lot of work for replication in db clusters, save network bandwidth, reduce access latency, reduce disk i/o demands, allow you to better tune to database cacheing for queries.
storing session data on the app server may be good if you have a load balancing system that can keep an end user associated to the same app server like LVS, but wouldn't be good for DNS RR.
But that being said, It should work for everyone regardless of their environment, fancy stuff should be hidden or maybe patchable for big environments. So the distribution doesn't have to deal with erraneous code bloat.
yes well
Yes well, thank you for your comment from a four hour old account :). We're back to arm chair quarterbacking again and OSL did get a nice price from Dell.
We're building out the infrastructure for the expected growth. Currently 33% each release. Various tax regulations across various governments and the fact that we asked for money SPECIFICALLY for hardware. Dries rightfully does not want to hold the money and to run into any tax liabilities or other difficulties.
This allows us to seperate offload other services (cvs/mail lists) to a different server. This will probably cover growth for the next several years before we have to seriously look at it again. (ya ya ongoing evaluation etc)
I love the insinuation here. Drupal continues to run fine on smaller sites. Drupal.org however has been getting slower and more hammered over time. This recent outage caused some serious scheduling and rollout issues for people, so if you don't mind, while experimentation will continue to progress on drupal.org itself, let's NOT get ourself into a situation where it goes down hard.
4 hour old account who are you? Where was your involvement in the community a few weeks ago? Thank you for your inaccurate description of our CMS :). I paticularly enjoyed your insinuation. Shall we ship you one of the servers to hold for us?
Oh yes, thank you for pointing out that 26,000 users on one box using the same database for four years is a small site. Now that we know Drupal will scale that well for that criterea I can relax on my little 5 user corporate type sites. I wonder what Spreadfirefox's hardware setup is. I think they have more users.
There are a lot of people with a lot of opinions. There are multiple approaches. This is the approach we took. This is the approach we announced. It does not invalidate the other approaches, it is just the path we are going. We posted the information on that path knowing we were doomed no matter what.
In between our paying jobs and our unfunded involvement here, we tried to choose a path that will leave us room for growth and stability with the unexpected windfall. Stability and availability is very very important as many people found out.
In our next stage using LVS, we can build out test environments for people to continue to hammer on to optimize the databases. Just because we are building out the infrastructure does not mean we forgot Drupal's roots. Look at the php version requirements if you don't remember. There are people who would love for us to up the php and mysql requirements so they can leverage newer features.
Welcome to the community, stick around. Help out in the forums, get involved.
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
ROFL
Oh yes, thank you for pointing out that 26,000 users on one box using the same database for four years is a small site.
Dude, nice. ;-)
--------------------------------------------------
FireBright :: http://www.FireBright.com/
ditto, for what sepeck said
To add to what sepeck said:
Last fall, drupal.org was slogging along, performing very slowly just like in the last copule of months. Kjartan upgraded his server substantially. For a whlie, drupal.org ran very quickly. But with each new release, drupal.org has seen a significant increase in users and bandwidth. IMHO, the new hardware infrastructure is much needed to avoid that incovenient cycle of slow down, upgrade hardware, speed up, major growth, slow down again, etc.
And someone new to drupal.org obviously doesn't understand that for those of us who frequently work with the website, better hardware not only eliminates inconvenience, but significantly increases the productivity of the community. I've been slowed down in some work that I do on the site over the last couple of months and could have accomplished a good bit more with the time I have to invest with faster, more consistent response from drupal.org.
So why Dell?
I am a little confused as to the choice of Dell, given the donation from Sun and the fact that of all the hardware providers out there, Dell is not one I associate with Open Source projects.
I like Drupal and have been recommending it for community projects I run across. Isn't community what this is all about? Sun heard the call for help and acted on it. Not that I think Sun makes the best choice for hardware for Drupal but as Tim Bray points out, HP and IBM are also big investors in the Open Source ecosystem.
try as we will, try as we might
We can't win. No matter what we do, it'll be wrong to someone. Some people are long time members, others are creating new accounts just to chastise us.
http://staff.osuosl.org/~kveton/2005/07/20/on-the-drupal-donations/
We tried to do the 'right' thing and evidently we were wrong. Some of those who helped are now annoyed. Some people are now gloating and making snarky little comments on their blogs that they were right not to because in their opinions Dells are garbage because they are made by bad people and evidently we're all ungrateful and that in the old days things were better.
Folks, despite some peoples opinions, Dell servers are decent quality boxes. They serve in a lot of roles all over the world. I personally like HP servers (then again, I hold some HP certifications so I am biased).
We tried to build for the future with quality and quantity and well, we now seemed to have failed.
At this point I am concerned that mobs of people will be visiting with pitch forks and torches. I keep checking to make sure there are no bell towers nearby.
There is nothing that I do with Drupal that makes me money. It was fun and a neat CMS and a way to learn more about how to manage complex database backend websites.
-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
just want to say thank you
just want to say thank you, with a faster and reliable drupal site you help me a lot
for me its all ok with the way you used the donations
and .. well i dont understand, why some people tend to behave like they "own" drupal and can control things
-micha
work in progress with Drupal 4.6: langmi.de
When do we get to enjoy this new infrastructure?
How much longer before it gets implemented? Sorry for sounding like a kid in the back seat of a car. :)
I just want to say thank you
Frankly, if you guys had gotten a new sever to minimal specs, and spent the rest on what would be a modest holiday anyway, I would not mind. For all that you've given this community, you deserve so much more.
I'm delighted that you've invested all this in hardware and core services. I do not feel ill-used by my modest contribution, nor do I feel like I should have a say in what you do. I gave out of good faith that the money would be used for a new server solution for drupal.org, and you topped that many times over.
Good for you! And thank you!
===
Laura
pingVision
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
I agree.. Thank you guys and gals for a awesome project.
I agree with the way Laura has put her words. If you wanted a say/agrue with how the Drupal staff spent the money - you should not have donated. When one donates it's exactly that - A donation. You think people who donate to the red-cross or some other orginization call them up 10 times a day and give them pointers on how to spend the donations? Or chastize them on how they've spent it? I could understand if you where someone who donated say $10,000, but I would imigine that most of the people whining are people who donated like 10 bucks.
If you trusted the staff enough to give them your hard earned money - then trust them enough to spent it as they see fit to better the project or community. Remeber, it was a donation - not a investment aka silent partner. Though I get the feeling that the staff wish that some of these people where actually just silent!
Good job on your donation drive guys! Ignore the calls for a "Vote" or "Poll". All the whining and griping is starting to sound like the US congress. It'll take years to use that money if you let the donators get under your skin. Remeber, most of us trust you and have for a very long time. The few nay sayers/babies/sucks are not the bulk of the project supporters.
Like laura says, take a vacation. Or at very least, do a night of pizza and beer - You all deserve it!
EG
evilgenx.com
I go with laura's comments -
I go with laura's comments - well put!! & im sorry to say I wasn't able to donate at the "we need cash now" stage but have just made a donation - keep up the good work.
I spent a long time looking for CMS/BLOG/FORUM software after realising i'd reached the outer limits of my capabilities developing my own. The amount I've learnt in the past 15 weeks of being a Drupal member has been amazingly satisfying & my understanding of what web applications can achieve has completely altered.
Thank you for such an open environment.
Tomski
><>tomskii
><>www.mutinyarts.co.uk
language specific communities
It would be awesome to have the sites hosting the communities that translate drupal, hosted by drupal itself. Like http://francais.drupal.org/, http://italiano.drupal.org/, etc.
patechinois
http://drupalfrancais.zapto.org/
I would prefer two letter
I would prefer two letter codes for countries; makes things more standardized and usable.
Language vs country
It is a better idea to segregate by language as languages generally have more coverage than country. With open-source there is usually less need to go local.
--
If you have a problem, please search before posting a question.
being able to support other drupal projects
Being able to support other drupal projects, such as International projects, was one of the factors discussed in terms of choosing how much hardware to buy. What may have been ample to run drupal.org and directly related properties doesn't take into account growth and sponsorship of other worldwide drupal communities.
Who cares if the cat is black or white, as long as it catches mice?
--------------------------------------------------
FireBright :: http://www.FireBright.com/
updates
very interesting. I was wondering yesterday what runs this site since it wouldn't load for over 45 seconds. it'd be interesting to hear how our server infrastructure evolves over time.