We’ve already done that for Zeus and, as I’ve explained, I don’t
think I would be able to secure more funding when we can just use
Apache instead. Although I personally believe it would be worth the
investment - and that we should always try to provide a better
service than our competitors rather than just copy them – it’s very
difficult to promote an unproven solution over one that is being used
by 70% of all sites on the web.
Then as a commercial venture, employ someone to create that
functionality for you if you can't or won't yourself. Or
experiment with the already available redirection handler which
seems to do a fine job of replacing the mod_rewrite functionality.
On Oct 22, 2010, at 11:11, Marcus Don <[email protected]
<mailto:[email protected]>> wrote:
What it does is allow non-developers to install thousands of
applications into a shared hosting account without the need
for them to employ a developer. It’s not a question of
functionality, it’s a matter of commercial necessity.
Marcus
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]
<mailto:[email protected]> <mailto:[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] <mailto:[email protected]>
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[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>
<http://register.it> <http://register.it
<http://register.it> > <http://register.it
<http://register.it> <http://register.it
<http://register.it> > > , names.co.uk
<http://names.co.uk> <http://names.co.uk>
<http://names.co.uk <http://names.co.uk> >
<http://names.co.uk <http://names.co.uk>
<http://names.co.uk <http://names.co.uk> > >
, nominalia.es <http://nominalia.es>
<http://nominalia.es> <http://nominalia.es
<http://nominalia.es> > <http://nominalia.es
<http://nominalia.es> <http://nominalia.es
<http://nominalia.es> > > , amen.fr
<http://amen.fr> <http://amen.fr>
<http://amen.fr <http://amen.fr> >
<http://amen.fr <http://amen.fr>
<http://amen.fr <http://amen.fr> > > ,
register365.com <http://register365.com>
<http://register365.com>
<http://register365.com
<http://register365.com> >
<http://register365.com
<http://register365.com>
<http://register365.com
<http://register365.com> > > , and
> simplyhosting.com <http://simplyhosting.com>
<http://simplyhosting.com>
<http://simplyhosting.com
<http://simplyhosting.com> >
<http://simplyhosting.com
<http://simplyhosting.com>
<http://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
<http://example.com> <http://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 <http://example.com>
<http://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]
<mailto:[email protected]>
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]> >
> Website: http://www.names.co.uk
<http://www.names.co.uk>
<http://www.names.co.uk
<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]
<mailto:[email protected]>
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]> >
http://lists.octality.com/listinfo/cherokee
<http://lists.octality.com/listinfo/cherokee>
<http://lists.octality.com/listinfo/cherokee
<http://lists.octality.com/listinfo/cherokee> >
_______________________________________________
Cherokee mailing list
[email protected]
<mailto:[email protected]>
<mailto:[email protected]>
http://lists.octality.com/listinfo/cherokee
<http://lists.octality.com/listinfo/cherokee>
------------------------------------------------------------------------
_______________________________________________
Cherokee mailing list
[email protected]
<mailto:[email protected]>
<mailto:[email protected]>
http://lists.octality.com/listinfo/cherokee
<http://lists.octality.com/listinfo/cherokee>
------------------------------------------------------------------------
_______________________________________________
Cherokee mailing list
[email protected] <mailto:[email protected]>
http://lists.octality.com/listinfo/cherokee
