Hello everyone,
I've just had a debate on the issue queue for core about Fast 404s and how to route around the issue of having Drupal be the 404 handler by default. The debate was enlightening for everyone involved I think. But the consequence should be a documentation page addressing the issue and the multiples available strategies for solving it.
Right now, it seems that the documentation is very thin on server and performance stuff. I use Nginx as the web server. There's no handbook page for it I believe. Well there's a group but it's more for someone already having the server up and running and wishing to proceed further.
I think that a set of pages related to servers, performance and security issues around each one is of great interest. AFAIK no other CMS project has documentation regarding those issues and it will function not only as a Drupal guide, bit also as a sort of general guide for someone trying to deploy a site with a specific server. There are generic things that relate to being a PHP app and others more specific to Drupal.
As an example of a generic thing that's server related, I could not find a page that advised a particular setting for PHP runtime parameters in production servers. If we had one, perhaps we can avoid someone publishing crappy advisories and including Drupal in it.
What's your take on the proposal? Mind you that I can write the fast 404s page regardless of this proposal being accepted, I just think that we can all benefit if there's more server and performance info in the handbook, hence my proposal.
Thanks,
Comments
Server docs sub-group/team?
Thanks for posting this Antonio - I hope that there are a few others interested in server docs who will speak up here. (Just for reference, here are all issues tagged with "server stuff" for an idea of how much needed work is documented so far: http://drupal.org/project/issues/documentation?text=server+stuff&status=... )
Would be great if a few people want to focus on server docs, give input, or watch this tag in the queue to help out!
damien_vancouver has been working on some of the ones in the queue, I'll be sure to flag this for him too.
Some server performance stuff here
You can find some information on server performance here: http://drupal.org/node/627252 including some PHP tuning info (it's buried a few levels down).
It would be great if this section got more love.
Security information should go in this section: http://drupal.org/security/secure-configuration
More Love By Who For Whom? ;-)
Thank You Lee.
There is already enormous confusion in world at large
about Drupal Themer and Dev prereq and requisite skills.
Expert Themers: "Take Data From PHP Memory And Put It On The Screen."
Expert Devs: "Alter or Add Data To PHP Memory Using Advanced PHP and MySQL."
These clarified distinctions (or something similar) could prevent many noobs from wasted doc time.
While I contemplate possible structure and contents of D7 performance docs...
an additional distinction strikes me as highly relevant:
Standard Wacky ?TeamCMS Dev Workflows ( Harried Rapid App Prototyping ) ** I think most Drupal Folks Are Here!! **
Network Operations NetSys Engineer Practices (Deploying, Testing, Tuning, Stability, Scale)
Again, VERY different AND
these clarified distinctions (or something similar) could yet again prevent many noobs from wasted doc time.
I welcome all requests for clarification and apologize for any sub-optimal choices of terms.
Thanks!
Resume: http://urbanspectra.com/resume
Jeremy Donson
Database and Systems Engineer
New York City
Yes I agree
a cursory look at the pages Lee pointed to shows that they're a big mess. But that's natural since they've grown organically. Each person that had something to share chimed in. Retrofitting a layout on it is extremely difficult. What I'm thinking about is creating pages that are specific to each part.
interaction between the server and drupal
security
performance
extensions (imagecache, anonymous users handling, &c)
web servers
I'm not competent to write all of this. I have zero experience of both Lighty and IIS. And caching is a vast topic. There are many strategies, e.g., reverse proxy at the protocol level, boost, memcache and authcache at the application level, APC at the language runtime level.
But definitely it needs a revamp since it seems quite confusing to me. Of course the current pages would be migrated to the proposed layout and a bunch of new ones would be added.
L - A - M - P ?
How about just speak to LAMP stack and throw in Alternative Layers...
4 DEV LAYER: SERVER = PHP, CLIENT = JQUERY
3 DATABASE: eg, MYSQL, ALT postgres, mongodb
2 WEB SERVER: eg, APACHE, ALT nginx, lighttpd
1 OPERATING SYSTEM: eg, LINUX,
------------------------------------- Please review above twice and comment before reading ahead, thx!
THEN WE CAN DISCUSS ABOVE IN TERMS OF:
a. UI THEMER (RAPID PROTOTYPING)
b. AGILE TEAM DEV WORKFLOWS: local, Dev_Collab, Approval, Staging, Production
c. CAUTIOUS TEAM ENGINEERING TESTING & SCALING: Staging, Production, Data Warehouse
Jeremy Donson
Database and Systems Engineer
New York City
Well
I'm only focused on the server part. And I disagree on putting Apache on a such a pedestal. I think all servers should be treated on the merits of their performance and load. Not on the basis of the historical artifact that the LAMP stack has been the "standard".
I don't see what jQuery is doing in a server related discussion. That's client side. Version control systems are also completely unrelated to servers and security. That's a development/deployment workflow thing.
The same goes for the databases. Yes they have huge performance implications. But my proposal was only about web servers and their interaction with drupal. My outlline above shows it.
I'm not even mentioning OSes. Both Apache and Nginx run on the major 4 platforms:
I can only talk about Linux and I suppose most stuff applies also do *BSD and OS X. About Windows I have no experience. But AFAIK with MingW you can get a similar environment to UNIX on Windows.
I think Lee's note about
I think Lee's note about making sure any specific security related info is mostly in the security section is an important one (and then you can link over there from the server pages).
I am able to rearrange pages through a drag-and-drop admin interface, if you want a whole bunch moved around, pls post the proposed structure into an issue that we can get a couple reviews on, and then I'll be happy to do the moving around (so you don't have to waste time on moving each page one at a time!)
The trade-offs
K, but performance issues regard the LAMP stack...
JQuery is client-side processing, unlike php. Client performance is another issue to consider.
TeamDev/SCM has a lot to do with Project Velocity,
which is CRUCIAL TEAM PERFORMANCE metric.
The default layers are Linux, Apache, MySQL.
(That is not a vote. Just a fact.)
The rest is as needed and should not confuse noobs.
Specifically, there are VARIED trade-offs with
Operating Systems,
Web Servers,
Network Data Sources,
etc.
The questions that most might have is what trade-offs there are
and why alternatives to default installs MAY be desirable.
Most simply do not know
how the LAMP stack works, nor how Drupal works, nor much php at all.
How would you suggest helping others to choose
tuning options or consider alternative layers without any expertise?
Jeremy Donson
Database and Systems Engineer
New York City
the unpleasant stuff first....
I really like the idea of a server docs sub-team.
Personally I am apalled by the shoddy state of the documentation covering day-to-day administration of Drupal sites on a server. I've attempted to clean up a few pages in the 'server stuff' queue, most recently: http://drupal.org/node/1016828 (multi-site install with WAMP).
the biggest issue, as always in Drupal IMO is that there is no one available/willing to review changes and get them anywhere. I applaud the enthusiasm of this thread, but let us not lose sight of the problem affecting 99% of users here... which is that the base state of server documentation that exists alread. (ranging from completely out of date and wildly inaccurate to woefully incomplete in almost every case)..
What the project really needs for the good of the community as a whole is a bunch of people to band together and commit to improving the basic stuff, and more importantly >>reviewing<< one another's submissions in a timely fashion so we can get somewhere. I think once the glaringly horrible stuff is done (and it will be a world of suck of course) then we should collectively reward ourselves with everyone getting to write about their specialty (404 handlers, high performance, differences between webservers etc), and by then we will be handier at reviewing one another's work and it will be easier to handle the more advanced stuff.
But when we are missing even accurate docs on the basics (the old revisions of the multi site apache install are a perfect example, I'm sure most doc pages in the server stuff queue are similar), then worrying about specialty edge cases is not time well spent.
therefore, comrades, what do you say about us fixing this problem, reviewing one another's doc enhancements, and cleaning up the apalling state of "the basics" before we move on to the more complicated advanced scenarios. drupal is sadly lacking a core group to do what I'm proposing. maybe this is it?
Are any of you with me!?!? Those interested could prove their mettle by reading over my changes here: http://drupal.org/node/547860, which have been sitting with tumbleweeds blowing by and no activity for a month now.
So.. if someone could help me review that change, I would happily reciprocate in kind, and perhaps together we can clean up the appalling mess before us. In my mind I'd like to see ALL the docs up to the level of quality and completeness on that page I reviewed. Rewriting that page was no fun... it took about 8-10 hours to do the page, in case anyone is wondering, do check the previous revisions to see what it used to look like)... and as a PS, I hate windows and don't even use WAMP. But this enabled me to do a clean-room style install step by step, so probably worked out for the best.
then we can show off and write all sorts of nifty edge case stuff too. i believe that documentation changes (allowing for individual styles etc) should be able to get approved orders of magnitude faster than code changes... but so far I have been wrong :( Anyway I'm pretty much ready to give up already unless i find other people willing to help review this stuff... in which case I'm willing to put the time in. Including helping with the advanced/unusual stuff discussed so far, and refactoring the organization of the pages etc etc. (all once the basics are fixed from the state they are currently in).
exactly on track
Hey Damien - was hoping you'd be enthused about this ;)
I think you are EXACTLY on the right track as far as what needs to be done, the need for a small group to band together and clean this stuff up, and then improve/add to it.
(And this actually needs to be applied to all of the topic areas - I should post a wiki page up or something now that a lot of issues are tagged.)
Really hope that you and Antonio and any other interested parties can start working together on this!
Indeed
there are some pages with are very bad indeed and others much better.
It's not by chance that I've chosen a security example. That's IMHO the most critical part of the server related documentation. One that should be clear, concise and dogmatic in a good way. This must be the building block that other pages and guides should reference.
Here's the deal:
Agreed?
PS: Your WAMP page is very good. You can't hold their hand much more than that :)
@perusio: sounds great to me.
@perusio: sounds great to me. I agree with you that security should be priority #1, let's tackle those first before basics... it's much more important we aren't telling people to do insecure things, or letting them assume they are secure when they are not!
When you get that 404 page ready i can review for you.
This sounds like the start of a productive friendship :) Looking forward to coming up with an action plan!
Topic sub-groups wiki page
Behold: http://groups.drupal.org/node/125669 sign up!
Hello everyone
Damien, Ariane et al,
I know I'm lagging in the debate. But hélas I have a deadline that is already behind schedule and I'm in a coding marathon. I'll reply to the above raised issues later. In the meantime I've signed in at the wiki page created by Ariane. Where it says server docs team.