Am I missing something? What does mod_rewrite do that the redirection handler doesn't do?
I think your approach may be a little off: no one is here to develop software for you regardless of how many perspective servers you want to use it with. That should be irrelevant to the discussion. On Oct 22, 2010, at 10:32, Marcus Don <[email protected]> wrote: > Hi Tony > > Thanks for your feedback. > > We’ve already invested a considerable amount in developing this software, so > I doubt I could secure more funding to adapt it to another platform. Even if > I could, there is no commercial case for us to continue funding the ongoing > development and maintenance when we can use Apache for free. So, by providing > such as significant head-start, I was hoping I could drum up enough support > among the existing Cherokee developers. > > Regards > > Marcus > > > > I am sure everyone wants to see Cherokee use grow. However, volunteer > developers can only do so much. They still have to earn a living. If you > are going to use it on that scale, which is great, why not put some money on > the table as an investment for you and the community. Even if it is not what > you would pay a contractor, volunteers might be much more motivated. You > would still be benefiting from the incredible amount of work that has already > gone into Cherokee. Also, if use grows worldwide, you would benefit in the > long run if other commercial companies decided to begin to deploy it and > contribute back code. > > Just my two cents. > > Tony Zakula > > > > On Fri, Oct 22, 2010 at 3:54 AM, Marcus Don <[email protected]> wrote: > Since I've had virtually no response to my email below, I'll try again in > far fewer words. > > I'm interested in using Cherokee to host around 50,000 sites and 600,000 > domains, with the potential to extend this to 600,000 sites and 1.6 million > domains. > > Unfortunately, our customers want mod_rewrite, which Cherokee doesn't > currently support. However, we own the source code for a mod_rewrite > equivalent, which we are willing to donate to Cherokee if enough people are > interested. > > If you are interested in the possibility of Cherokee becoming a serious > alternative to Apache for commercial, mass hosting, please let me know. > > Thanks > > Marcus > > > > Hi > > > > Apologies in advance for the length of this email, please bear with me :) > > > > First an introduction: I'm senior manager of R&D for a group of ISPs > > including > > register.it <http://register.it> , names.co.uk <http://names.co.uk> , > > nominalia.es <http://nominalia.es> , amen.fr <http://amen.fr> , > > register365.com <http://register365.com> , and > > simplyhosting.com <http://simplyhosting.com> . As a group, we host over 1.6 > > million domains and 600,000 > > web sites. > > > > Currently, we have 3 shared hosting clusters in Italy, the UK and Ireland. > > The > > Italian platform is based on Apache and the UK and Irish platforms are based > > on Zeus Web Server. We also have a legacy platform, inherited from a recent > > acquisition, based on Apache and H-Sphere, which we are currently migrating > > to > > Zeus. > > > > Until recently, we have been very happy with our choice of Zeus Web Server. > > We > > have gained a solid reputation in the UK for having a very high-performing > > and > > reliable platform, and we have won the UK ISP Award (ISPA) for Best Shared > > Hosting for the last 3 years running. However, we are now considering > > migrating away from ZWS for the following reasons: > > > > 1) It hasn't been updated since 2007, and Zeus will not commit to any future > > updates other than security patches. > > 2) It makes commercial sense for us to use the same technology everywhere in > > the group. > > 3) Zeus does not support mod_rewrite. > > > > Given these requirements, and the fact we are already using it in Italy, the > > obvious solution would be to use Apache on all platforms. However, I am > > seriously concerned that the performance would suffer as a result, so I'm > > currently studying the feasibility of other options. > > > > The need for mod_rewrite is a practical, commercial requirement based on the > > fact that many 3rd-party applications require rewrite rules, and the vast > > majority only work with mod_rewrite without the intervention of a developer. > > This has always been something of issue for us, and the growing popularity > > of > > open source software among non-developers is greatly exacerbating the > > problem. > > Also, we now provide Softaculous for our customers, but we've had to disable > > many of the 150+ applications because of their reliance on mod_rewrite. > > > > Furthermore, when we started migrating the H-Sphere platform, we found an > > unusually high proportion of domains are using mod_rewrite. During previous > > migrations, we have replaced them with Zeus rewrite scripts, but this time > > the > > numbers are just too high. > > > > So, we recently employed an experienced C developer to write an ISAPI filter > > to replicate exactly the behaviour of mod_rewrite under Zeus. However, > > although this works perfectly in our development environment (even under > > extremely heavy loads), after a few days on the live platform, something > > goes > > very wrong. After several weeks of debugging, testing and reading memory > > dumps, we're convinced the problem is with Zeus's ISAPI implementation - but > > so far we are unable to prove it, and I'm not sure they would fix it even if > > we could! > > > > If you are interested, I am confident I could arrange for the source code of > > our ISAPI Rewrite module to be released to the Cherokee project for use as > > an > > optional module. Obviously, the ISAPI layer would need to be replaced, but > > this is a minor part of the code. All we ask in return is that someone adds > > support for the other, mostly very simple, htaccess directives. I can ask > > the > > original developer if he would be willing to contribute to this, but he > > doesn't work for me so I can't guarantee it. > > > > Without this functionality, the only other option available to us is > > LiteSpeed > > - but I'm not keen on adopting another closed-source solution that isn't > > gaining significant market share. Also, I am convinced this is the only > > major > > hurdle preventing other mass hosting providers from moving away from Apache > > to > > something that scales more efficiently, such as Cherokee. > > > > Lastly, I have another feature suggestion to address the needs of mass > > hosting > > - support for custom document root mapping functions. > > > > Currently, we use the same method as shown in the documentation - ie > > /sites/e/x/example.com <http://example.com> . This is fine for a few 10s of > > thousands of sites, but > > not very efficient once you get beyond 100,000. A better solution is what we > > use on our email clusters, which have many more users (around 1,000,000 in > > Italy). This uses the last 3 characters of the MD5 checksum of the username, > > like this: /email/5ab/example.com <http://example.com> . This produces a > > more even distribution and, > > by being wide and shallow, allows for a much more efficient stat cache. > > > > Regards > > > > Marcus > > -- > > Marcus Don > > Senior Manager > > Research and Development > > DadaPro > > > > Main Line: +44 (0)845 363 3630 > > Main Fax: +44 (0)845 363 3631 > > Tech Support: +44 (0)845 363 3634 > > Email: [email protected] > > Website: http://www.names.co.uk > > Address: Acton House, Perdiswell Park, Worcester WR3 7GD > > > > This email and any files transmitted with it are confidential and intended > > solely for the use of the individual or entity to whom they are addressed. > > > > If you have received this email in error please notify the sender > > immediately. If you are not the intended recipient you are notified that > > disclosing, copying, distributing or taking any action in reliance on the > > contents of this information is strictly prohibited. Please note that any > > views or opinions presented in this email are solely those of the author and > > do not necessarily represent those of the company. > > > > Finally, the recipient should check this email and any attachments for the > > presence of viruses. The company accepts no liability for any damage caused > > by any virus transmitted by this email. > > > _______________________________________________ > Cherokee mailing list > [email protected] > http://lists.octality.com/listinfo/cherokee > > > _______________________________________________ > Cherokee mailing list > [email protected] > http://lists.octality.com/listinfo/cherokee
_______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
