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
